Freigeben über

Branching

  • Artikel

I know one of the areas people find lacking in Source Safe has been in its branching features. We've put a lot of thought and effort into Hatteras to be more capable and more flexible when it comes to branching and merging (remember, we're building Hatteras from the ground up, so we're not forcing new capabilties on an old engine or anything like that).

 

Of course, me saying that isn't exactly reassuring by itself. I know people have a variety of approaches and motivations when it comes to branching, and I believe we have the features most of you will need to manage your codebase the way you *want* to, instead of being constrained by limitations of the tool. To help us all ascertain this, I'd like to hear a bit about how folks out there currently deal with change management - do you use a main branch with release branches? Do you have private branches for groups or even individual developers? Do you try to keep the "tip" of your repository in a buildable state, or do you mandate periodic (e.g. daily) checkins? Various people would answer "yes" to one or more of those questions, usually with a good reason, even if there's other reasons they WISH they could answer "no". And, of course, vice versa.

 

I want to take some specific examples of how people work today, and how they WISH they could work, and show how Hatteras will let you do it. In some cases, we may even have more than one valid approach. For example, maybe you have a private branch you check in to daily, so your work always stays recent on the server (and, presumably, backed up as a result). We'll support this, naturally. But we'll *also* let you solve the same problem with shelving, if you'd rather *shelve* your changes each day, and skip the "staging" branch. Either will (almost always) solve the problem, but one may appeal more to you than another, based on your own particular situation.

Comments

  • Anonymous
    September 15, 2004
    Great to hear sourcesafe is being redeveloped from ground up. With regards to your branching question, the approach we take at my place of work is I guess pretty standard. We have a main release branch/trunk which is always in a buildable state, when we kick off a project, we create a branch. Every so often each branched project needs to reintegrate the changes from the trunk as it changes (ie. when a project gets released, code is reverse integrated into the trunk, before releasing). Our current SCM assists us alot in tracking code changes and automatically integrating those changes back onto trunk. Our SCM also provides us with private depots where we can branch code to and do personal testing/dev that may not fit into a project.
  • Anonymous
    September 15, 2004
    I'm also pleased to hear the sourcesafe is being rebuilt. For our project (our companies website) we have two trees. One is a development tree that all developers access on a daily basis to work on. Code is checked in either daily or later if it's not in a compilable form at the end of a day. Once the code has been approved in the test environment, we branch it over into the production tree. Compile against that tree, and re-test. If all is well, it's checked into the production tree and taken into full production.

    I haven't read the rest of your posts (I'm about to, so maybe this has already been ansered), but we have some in-house applications that interface with sourcesafe. Are you going to have an availible .NET API that can be accessed to use sourcesafe programmatically? Thanks for your time in posting this information!
  • Anonymous
    September 15, 2004
    Quick thing - I meant that Hatteras is a ground-up development. Source Safe, including the upcoming Source Safe 2005, is not a complete re-work. I'm sorry if I implied otherwise.

    Your scenario is definitely one we see a lot. In fact, "forward integration" and "reverse integration" are terms you'll hear in Microsoft quite often (and even here, not without a certain amount of trepidation).

    You'll be able to setup the exact same sort of topology in Hatteras. It will know who's been branched from who, and merge both "up" (reverse integrate) and "down" (forward integrate) the branch tree, with a pretty good degree of automatic merge processing. You can also (if you're either really brave or really REALLY careful) do "baseless" merges to go "across" the tree, skip a level, etc., but as you probably know, that's not something you find yourself either willing or eager to do except under special (and hopefully limited) circumstances.

    You'll also be able to create what amounts to private depots by creating branches and limiting Read and/or PendChange access to that branch to whatever subgroup you like -- an individual dev, a feature team, whatever works for you.
  • Anonymous
    September 15, 2004
    The comment has been removed
  • Anonymous
    September 16, 2004
    One thing that would make branching more accessable and more "oops' proof, would be a graphical view of the branching of the code, including pending shelved code (if possible).

    Often with complex branching.merge scenarios it has helped me to draw out what is happening. (Just go license Quick Graph from Jonathan de Halleux and get it over with)

    If a manager sees that all his leads have lots of shelved code, he might ask the reason why. Maybe it indicates some uncertainty of the impending changes. Many coders dont speak up about their true feelings about things, but the code does not lie.

    Thanks for all the great features, keep it up.
  • Anonymous
    September 16, 2004
    Adam:

    I don't know if we'll have any graphical visualization tools when we ship; however, we at least expose the necessary data to construct such views (you can view the branch and merge histories for a filespec as the source or the target, or for a specific source/target combination, and so on).
  • Anonymous
    September 18, 2004
    I'd second the suggestion of a graphical visualization. In the past I've seen branching (in several source control systems) avoided as people aren't quite sure what's going on behind the scenes and get worried that their code changes might end up in the 'wrong place'. So I believe this is a really significant feature. Perhaps if there really isn't any time for this, it could be done as a kind of powertoy on gotdotnet or some such place...
  • Anonymous
    September 20, 2004
    Chris_S:

    The "fear factor" is definitely something we're concerned about. It's at least partly justified - branching and merging are almost irreducibly complex, and you do have to trust that automatic merging will either do what you expect or tell you that it can't. And as we know, trust is earned, not given, even for software.

    There's now a feature request for a graphical branch/merge tool. I should be clear that it's not likely to make v1, but it's a possibility for a future version.

    Also, a powertoy-type solution should be possible. We'll have a managed object model that will expose all of the data and methods you'd need to visualize and modify the branch model graphically.
  • Anonymous
    September 25, 2004
    The comment has been removed
  • Anonymous
    September 26, 2004
    James,

    I read your article, very impressive (how'd you make the graphics?).

    If you like Perforce, I think you'll be very pleased with the way Team System is approaching Source Control. The branching and merging (we use "merge" where perforce uses "integrate") is very similar. The "big build" stuff that will come with Team System should also allow you to set up the same kind of scheduled merge, build, checkin on build success/undo on build failure. I say should because I'm not terribly familiar with the build system, but I know scheduling and extensibility are among its major goals.

    As you said, having changeset-based checkins is nice when you want that one branch to always be in a buildable state. Keeping the build unbroken is a priority with the Developer Division at Microsoft, as well. Team System's source control (aka Hatteras) also uses atomic, transactioned checkins, and the changeset number each successful checkin gets can be tracked and used much as you would with Perforce. And, naturally, it plays a big role in integating source control with the build system, the work item (defect) tracking system, and so on.
  • Anonymous
    September 26, 2004
    Chris,

    Thanks for the compliment. I used Visio for the graphics saved as a PNG and then shrunk by 75% in Paint Shop Pro... If you want to use it I can give you the original Visio file, just drop me a mail.

    One question I would have is about speed. As you probably know, Perforce is just about the fastest thing there is. This means it doesn't get in the way when you're working. Are you aiming for the same perf standards? Do you have any perf goals you can share with us?

    Regards,
    James.
  • Anonymous
    September 27, 2004
    James,

    I showed your perf questions to Sam Mullis (http://blogs.msdn.com/sammu), our resident perf and stress tester (he's probably known to the backend as the "Master of Pain and Suffering"). Look for a blog post from him on our perf story in the near future...
  • Anonymous
    June 18, 2008
    This was the most popular question asked at our booth (and perhaps all of the VSTS area) at Tech Ed Developers