Have you seen this video? http://www.youtube.com/watch?v=4XpnKHJAok8
Linus Torvalds is sharing his opinions about SCM, branching and merging. It’s brilliant.
There was this video with Linus Torvalds talking about git, and explaining the philosophy behind it.
http://www.youtube.com/watch?v=4XpnKHJAok8
I can’t remember the details, but the idea is that if the tool’s philosophy is that everything done is a merge, and that you can work “offline” without connecting to a central server, then merging becomes much easier.
I am not convinced that merging is particularly hard for strong tools, whether centralized or not. My experience with CC was that merging is pretty effortless. Google have thousands of developers all over the world, and they seem to be quite happy with Perforce. Both of these tools have centralized servers.
Maybe it’s because we employed some discipline (not that much) when merging, though.
I just searched for other YouTube videos about SCM. This one is histerical. Historical? Well, you be the judge.
http://www.youtube.com/watch?v=vpILRv_tZy4
Jen
One branching mistake you left out of your Anti-Patterns that I have had to deal with is developers copying code to make a “branch”, but they don’t set it up as a branch in the source control system.
Depending on which Source Control system you have this can be a huge problem. Visual SourceSafe, for example, has significant problems with this when it comes to merge time. You have to trick it with unsupported command line calls to make it think that the copied files should be “Merged” into to the main line.
Just an FYI, Microsoft’s Visual Studio Team Services is a COMPLETELY DIFFERENT source control system than VSS. It uses SQL Server to store revisions, has all the goodies for branching and merging, and even includes shelve sets for getting local changes put into a shared storage area without affecting the main source control. Once one gets used to it, it’s very easy to deal with.
YMMV…
“A friend of mine had what I consider a brilliant idea: let the version control system operate on the abstract syntax tree, and let each user check it out via her own formatter. There are issues, of course - like how to deal with code that doesn’t compile, and how to keep comments in the mix - but I really hope someone puts such a system together.”
I can up with a similar idea when there were discussions about the possibility of making Visual Basic keywords lower case. To avoid conflicts between machines files would be saved with upper case keywords, but if the preferences were set so they would be displayed with lower case. The same could be done for a variety of style options.
At work, we use ClearCase. Creating a branch is difficult, time-consuming, and error-prone. Merging is also difficult, time-consuming, and error-prone. All of these are faults of the tool.
I moved my development to a Mercurial repository – I use a separate branch for each major task, and employ a couple of scripts to keep things synced with my colleagues’ ClearCase checkins.
I’ve never looked back.
Merges now take mere seconds and are conflict-free. The SCM tool cleans up my mistakes, rather than the other way around. Best of all, I don’t need to beg permission from the tool before editing a file.
On a previous project I was working on, at the site of the subcontractor we were not allowed to branch: too difficult.
Well, after a month they saw that this wasn’t workable anymore, so we could branch… but only files, no directories.
Again too difficult, but again after a month we could also branch directories. (what’s so difficult about merging a directory?)
So here we had ‘experienced’ SCMs saying that we could not branch files and directories, although we were doing this on our own site already for years. I still remember the shouting match between our SCM and theirs, ours won 
The branching system we used there (embedded software):
- one main branch that continues forever
- a branch per product group
- a branch (of the product group) per product (made a few months/weeks before its release)
- all branches always have to be merged to the main branch
- main branch is not merged to side branches
Never had any problems with it as long as you keep a clear overview of all branches and communicate this to everyone!
I think that is the most often overlooked thing about branches: communication! What is the branch for, who can work on it, from/to where to merge, …
Tool we used btw, was CMSynergy/Continuus.
A very good merge tool is Beyond Compare.
Somewhat of a newbie - but here’s my 2c…
As I work, I check in often via the Eclipse shell to CVS. I also update often. Several times a day sometimes.
Occasionally there are code conflicts, but these are not big - how much can a team change in a few hours, after all?
Several times a day, the Test runner sends out an email informing us whether the build passed or failed. Personally, I don’t trust my own code at all unless I’ve written a few tests for it. These tests are also checked in, and the test runner picks them up.
This ‘continuous’ checkin+update+test process ensures that things work well…
Although admittedly, the team is still small. Don’t know how well it would work if there were 40 of us all at the same time…
Another very useful feature of CMSynergy/Continuus that I haven’t seen used anywhere else is task based development.
See also http://www.cmcrossroads.com/articles/cm-journal/scm-patterns:-building-on-task%11level-commit.html
This was a big change in our organization because it’s not efficient to mix task based with file based checkouts.
A task can be a normal task that you would give to a developer, but also solving a particular bug, etc.
Making a build “with that and that bug solved” is very easy then, just take a base and add the tasks you want.
I don’t know which other tools support Task Level Commits.
@Jon Galloway
Example: if you went back in time 24 hours, you’d be floating somewhere in outer space since the earth would have moved on.
This just show how confusing parallel timelines can be and how carefully you have to think about them.
You should have said either…
Example: if you went back in time 24 hours, you’d be floating somewhere in outer space since the earth would not be there yet.
…or…
Example: if you went forward in time 24 hours, you’d be floating somewhere in outer space since the earth would have moved on.
Sorry to be the pedant, but this is typical of the kind of error found in sci-fi movies - simply because somebody had an essentially good idea but didn’t think it through.
I’m a first-time commenter here, but just wanted to say what a fantastic article this is.
Branching is a very much misunderstood, and mistrusted version control tool. I used to use Visual SourceSafe’s branching functions when I was a developer, but there was great mistrust of it.
Some things never change!
That’s because VSS’s “branching” concept is a truly horrible thing that should be mistrusted.
Jeff,
actually the first branching pattern you display (Branch per Release) is - as displayed - one of the worst to start with (read Appleton and related posts). Please update and replace it with a better one!
We do branch for each version, then do bug fixes in that branch and merge them back into the trunk (or development branch). It works quite well, the merging is usually done in a relatively short time and hardly causes problems. Just don’t wait too long with it!
I have to agree with all the other fans of distributed CM systems. When branching and merging is cheap, fast, easy, and doesn’t need to go thru a central chokepoint, it becomes much much more useful.
I use Mercurial myself.
What kills me about merging is that every mistake you make is a bug. And it’s probably a regression, which looks the worst.
git looks pretty awesome, from the perspective of making your code look like a london tube map. ^.~
“Eclipse has had local history for years, and Netbeans 6 does as well. :)”
It helps, but it’s not as helpful as a local repository (centralized or distributed). It doesn’t help smooth painful merges or give anyone else the ability to view your change history.
Sorry dude, you lost your argument by invoking Godwin’s law!
We do branch for each version, then do bug fixes in that branch and merge them back into the trunk (or development branch). It works quite well, the merging is usually done in a relatively short time and hardly causes problems. Just don’t wait too long with it!
This is exactly what we do and I find it works really well - development can continue on the trunk, and hopefully if no bugs come out in QA process we have no merging to be done backinto the trunk.
Having been the CVS guy on 3 seperate dev teams and, along the way, having actively developed advanced environment management techniques, abusing CVS heavily, I have had my share of real-world experience.
In my experience,the best SCM techniques are discipline and communication.
The former in the form of regularity in branching/merging and the reasons why, not modifying code layout for the hell of it or (more typically) to inflict one’s personal style (or belief system).
The latter on all occasions where one might create merge conflicts; beforehand (a certain amount of archtecture and planning to avoid everyone and their dog necessarily modifying the same six files every two days) and during development, at those times when well-planned interfaces prove inadequate, borken or otherwise deficient. Don’t just sit on your branch and pretend the rest of the world doesn’t exist; if it looks like you might be stomping on someone’s toes a week from now, ask them where they think they might be putting their feet.
Note: this is no guarantee or a fail-safe method; it merely sensibly avoids creating the bulk of unnecessary conflicts.
That all said, I am turning around to see the error of my ways wrt my tendencies towards wanting to run The Department Of Centrally Controlled Source Control And Build Management For The Benefit Of All—DVCS are just sooooo much more sensible.