Software Branching and Parallel Universes

@John P:
Thanks for the links. Didn’t know VSS had so many issues.

@argatxa:
I just looked at Microsoft’s site for Team Foundation Server and it looks like its using VSS as its source control portion. Am I reading that right or do they have a new version that’s better?
http://download.microsoft.com/download/1/0/4/1046448f-3775-4c29-940c-4a2ac9ee5a02/Team%20System%20Datasheet.pdf

Looks like everyone favors Subversion using TortoiseSVN. Is Subversion hard to setup, maintain or use?

Branching is not evil, merging is not evil, SCM tools that can’t do merging well are (creating branches is usually ok, making them interact with each others usually isn’t, CVS can’t do it, SVN can’t do it, … let’s not talk about SourceSafe please).

That’s why trying a distributed VCS such as Mercurial or Git is, in my opinion, a breath of fresh air: since they’re based on the concept of merging (each checkout is basically an anonymous branch, each local clone of a repo is an other anonymous branch, and you can easily create branches of branches of branches), they have to have good merging models, or they just don’t work.

And they do work.

What makes git so different (better?) than subversion on this aspect ?

First of all, it tracks merges, which means that Git knows which revisions you have and which you don’t (when it talks to another Git repository). Subversion doesn’t, so you have to manually track revisions in order not to repeatedly merge them in, and it’s error prone, and it usually doesn’t work.

Second, when it merges two branches/trees, it doesn’t take all the changes of one branch and put them in the other one in a single, ugly, horrible, unusable revision, it leaves the two branches in parallel and creates a “merge revision” in which you basically handle the disparities and incompatibilities, if any (most of the time, there isn’t any and the merge revision is only there to say “this is the union of branches A and B at point C”). Plus that tracking allows you to create wonderful committrees such as http://repo.or.cz/git-browser/by-commit.html?r=git/repo.git

Third, it has very aggressive merge matching, which means that it resolves merges fast, it finds conflicts only when there are conflicts (usually) and it mostly doesn’t find conflicts, especially when there aren’t any, so merging between your branch and someone else’s branch boils down to pulling his branch into yours and calling something along the lines of git merge.

Found a VS plug-in for Subversion…
http://ankhsvn.tigris.org

I thought the following blog posts about branching and merging would be of interest to you Donny.

http://www.daveonscm.com/

Good luck.

Mark

I have two rules of thumb for branching:

  1. A new branch for each version (if each client has a different version, so each one has a branch)
  2. A new branch everytime more than one developer have to work in the same complex feature (simple features don’t need more than one developer). The branch is used for communication between them.

Where I work, after each release, the current code is renamed to a new production project. Upon the next release, the current production is renamed again with a release date.
Ongoing changes to the production code (the renamed project) that must also take place in the current development code are simply duplicated.
When I first started, I thought this avoidance of merging was silly. After doing it awhile, I think it’s probably much easier than merging.

If automatic merges are failing in ClearCase you are merging between branches that are not compatible or the engineers on that other branch are sabotaging you. We had this happen when we had a team who would take a merge rewrite or delete our changes and check in the change. Then when we merged back to get their changes all of our code disappeared as part of the merge.

You also have to take a look at the hyper-links–the merge arrows in the Version Tree. A merge arrow says that the merge was completed. Sometimes we will perform a merge and delete the merge arrow because we took a partial merge to fix a specific problem. When we delete the merge arrow, we can do that merge again and get what we didn’t take.

The merge tool is looking for changes made in the source branch and merging these changes into the destination. Delete a line of code in the source and it will be deleted in the destination during the merge.

If the problem is with reformatting the code (tabs or spaces) you can set a property in the merge tool to ignore whitespace. Unfortunately, I don’t think it is a global setting. You have to do it manually on each problem file.

The merge tool from the command line also supports taking the changes from one version of a file. This can be a lifesaver when you need to bring

Great article. I’ve also found that companies rarely use branching. I suspect it is because management can easily understand the need to have a source code repository, but managing different lines of development is a bit more abstract and requires some rigor to do properly.

I have always wondered how companies get along without branching/merging - I would think that at a minimum, most shops will have to deal with a 1.1 production patch while a 2.0 release is under development. Even a one-man shop will have to deal with this situation at some point.

I think every development team needs to have at least one person who has the responsibility of managing the source repository and pays close attention to branching activity. It is even better if the team has some policy in writing about when branches and merges are performed, and the purpose of each branch. The branching/merging scheme affects more than just the developers - QA needs to know when merges are performed and if retesting is needed, and project management needs to know that time is being spent doing all of this.

I belive team system has a new source control system, I don’t belive it builds on VSS. [That said I haven’t used it]

Subversion is a bit painful to install [on your server] if you want fancy things like SSL and to use your domain logins instead of logins in a text file…

Configuring clients is easy.

here’s a vs extension for subversion: http://ankhsvn.tigris.org/

Sometimes people recomend you configure tortiseSVN to start the svn folder names with underscores to work well with asp.net, if you choose to do that you’ll need to configure ankhsvn the same way if I recall.

I wish I could help you more, but I’ve only spent like a weekend playing with subversion, my work isn’t about to change to something else even if it is better and free.

[Oh, the book pragmatic version control using subversion is good, but somewhat assumes you haven’t used source control at all before. And for brevity/compatibility it describes the command line tools, which isn’t a problem because graphical tools use the same language typically. The installation chapter is really helpful though, and so is the reference. ]

yes yes yes use git, bzr, mercurial (hg), etc. - subversion and other centralized systems are broken by design when it comes to merging.

It was a nice article. Actualy Visual Source safe was the only tool i have used as a source control. It’s a very small tool and has many limitations. Even till Visual Studio 2003 they hadn’t improved anything in the area of source control. When I got a chance to work at my client office… The Clear Case source control system was a fantastic new experience for me. Even it has a small learning curve, it’s really nice system which help to smoothen our development especially dealing with a gigantic source structure. It’s simply awesome. Thanks for such a nice article.

if your application is split into many discrete modules, and
you have 1 person who works on each module, then you never
need branching.

not true

branches are the perfect tool when you’re developing an application, and continue to make support fixes to the previous version. This is probably the most common scenario.

Companies that don’t use SCM properly will do things like make a full copy of the source code in a network drive.

In some very trivial case you can get away with just labels, and move labels when a fix is made, but this really doesn’t work in the long run.

Many times the automatic merge has produced code that
didnt compile, cut of half of a cs file.

Is the automatic merge in CC just plain stupid or is
this a problem with all merge tools?

ClearCase’s automatic merge is excellent, and well proven.
If you’re having trouble with this, it’s probably that

Many times the automatic merge has produced code that
didnt compile, cut of half of a cs file.

Is the automatic merge in CC just plain stupid or is
this a problem with all merge tools?

ClearCase’s automatic merge is excellent, and well proven.

It remembers what’s been merged and at what point, that’s very important for good merges in the future. ClearCase Details is the tool to master here, for tricky merges.

If you’re having trouble with this, it’s probably that you’re doing too drastic or conflicting changes between branches. In that case, merging can’t be expected to work too well.

For example, if a dev in your team has the habit of moving code around in a file, or changing the coding standard for fun, this will cause major merge problems if you have concurrent branches of the same files. Obviously. If that’s your environment, you have to code with merging in mind.

In my experience I never had problems with branching with Subversion. For branching to actually practically work you have to do whatever it takes to avoid problems with merging. That means you have to merge frequently (continuous integration anyone?) and enforce a coding standard. If not then chances are that you will end up with an unmergeable hell.

A professor in configuration management once told me that tools are not the problem and people using them in the wrong way are. The things he saw what developers did was using branches for other reasons than parallel development which left the branches unmerged.

Then again, if git and whatever actually enforces merging, then probably tools are the problem (speaking from a usability standpoint)… Again, unless people use the tools in the way that was not intended.

Another reason to really dive in and understand branching and merging is that anytime you check out code to your local machine and start working on it there, you’ve created an implicit branch.

http://haacked.com/archive/2006/06/02/ImplicitBranchingAndMerging.aspx

You’re already branching and merging, so might as well understand good patterns for doing so.

For branching to actually practically work you have to do whatever it takes to avoid problems with merging.

And that’s the core problem.

You shouldn’t have anything to do to avoid problems with merging, the tool should take care of that.

Subversion, of course, doesn’t.

We have SVN and what we do is have a “current”. When there’s a complex new functionality, we branch for that, but the guy in charge of that must make sure that he portes and merges when needed. Basically, what he does, is porting from current to his/her branch. That way, the later merge (from the branch to the current) is not difficult (in theory).

When we release a version, we just create a TAG (in SVN tags and branches are the same). So we have a rigid structure of “release/version/”

We also move that “release” to a stable “branch”.

We continue to add new stuff to current. But when a Bug is found, it’s either applied to stable and later ported to current or viceversa. Stable always compile. When enough bugs have been fixed in stable, we might release a “minor” revision. Again, this gets “tagged”.

When Current is ready for a new “major” release, it goes to “stable”. It gets also tagged as release-xxxx and the process is all over again.

The day we ran out of bugs and new features. We’d need to find a new job. :wink:

So far this has worked fine por 95% of the merges. The problem is that VStudio and the .NET tools in general do not tend to play nice with Source Control systems. Too many user files you have to exclude and stuff like that.

But so far, it’s nice to have a subversion under the hood. We don’t use ANKH (dunno if it has been updated) but we use TortoiseSVN and do all the stuff from the command line.

My two c.

anytime you check out code to your local machine and start working on it there, you’ve created an implicit branch

This isn’t true at all-- your local work is not revision controlled, it will have no history, so it’s not a branch. A branch is an alternate set of history. No history, no branch.

You shouldn’t have anything to do to avoid problems with merging, the tool should take care of that.
That’s why trying a distributed VCS such as Mercurial or Git is, in my opinion, a breath of fresh air … they have to have good merging models, or they just don’t work

How exactly do these distributed version control systems make merging easier, though? I think merging two people’s independent work is hard no matter how you slice it. This sounds awfully silver bullet-ish to me. Can someone explain this better?

This isn’t true at all-- your local work is not revision
controlled, it will have no history, so it’s not a branch. A branch
is an alternate set of history. No history, no branch.

That’s true if your local environment does not have local history. That’s limitation is becoming pretty much just an MS thing now.

Eclipse has had local history for years, and Netbeans 6 does as well. :slight_smile: