+972 52-548-6969
The BIG Merge
Merging is one of my least favorite activities, this is especially true when we are talking about a big merge. You might have noticed that I have been talking lately about some big changes that we are making to NH Prof. And now the time has come to merge it all back together.
Well, big changes is quite an understatement, to be fair. what we did is rip apart the entire model the application used to work with. We moved from a push model to a pull model, and that had quite a lot of implications throughout the code base.
Of course, we also did some work on the trunk while we worked on that, so before we can even think about reintegrating the branch, we have to do a merge from the trunk to the branch, which resulted in:
Now, the problem is that this is totally stupid.
Nitpicker corner:
And yes, I am using Subversion, and before the Git fanboys totally jump on me, I am seriously considering moving to Git to ease this sort of pain.
And yes, I should have done reverse merges to the branch all along, so before the Subversion fanboys totally jump on me, I know that.
It is stupid because there are some changes that has been made in parallel in both branches, there are some changes that involve deleting or renaming files that are just not being merged. And yes, I am using SVN 1.5. So, after resolving all the conflicts, I have to do a manual check over this, to make sure that we didn’t miss a merge because of that. I am at the point of so much Argh! that I can’t really keep it inside, hence this post.
A common example that I know is going to hit me is something like FormattedStatement, which is a pretty important class. In the branch, that was changed to be SqlStatement, and I renamed the file as well. Subversion doesn’t merge changes across that. And yes, I used svn rename for that (via Visual SVN).
And, to add insult to injury, doing this manual checking means a lot of going over the network, which means that this is slow.
Comments
The one that likes to merge has yet to be born
It's a hard problem without an easy solution.
Having just done a large SVN branch re-integration (on a very large codebase), I didn't encounter too many problems. Possibly more usefully, resorting to a text editor and TortoiseSVN to do the merging on disk was easier than using a 3-way merge tool.
Sorry to rant on your blog - but git is a pig and half of it is broken (submodules for example). It's Linus's baby so people blindly follow it without doing a technical evaluation on it's competitors. Kind of like some deranged religious cult.
I've settled on Mercurial. It actually works properly on Windows, is composed of one coherent component, is well documented. There are plenty of good technical evaluations available from large, well organised groups using it (openjdk, python, solaris).
"The one that likes to merge has yet to be born"
LOL
Take a look at this link: google-code-updates.blogspot.com/.../...sting.html
and the analysis that they do of Git and Mercurial: http://code.google.com/p/support/wiki/DVCSAnalysis
I am very content with Mercurial at the moment. It's a joy to work with and works very well on Windows. (Git gave me some troubles there)
Subversion merging is working well as long as you don't do renames/moves. Svn rename is there just to keep the history of the file before rename, but doesn't help you at all when merging.
Svn never handled rename/moves merging correctly - and the situation was not improved with 1.5 (see subversion.tigris.org/issues/show_bug.cgi?id=898 and subversion.tigris.org/.../...enames%20problems.ppt), which is a shame because is making it pretty dangerous in many scenarios.
The rename of a file and change of it's content in separate branches actually works very well inside Git, a scenario that we tested at work when evaluating other options for replacing SVN.
"And, to add insult to injury, doing this manual checking means a lot of going over the network, which means that this is slow"
...time to start writing SVN Prof ? ;-)
I can see it now... Rhino.Merge
And that's why I can't really understand why so many alt.netters show so much love for svn.
We've started doing serious use of branches at work and svn it is a PITA. Ok, I know it's not sourcesafe (I haven't tried tfs so I can't compare with it) but, c'mon, as someone said, just don't move/rename files and it'll be ok (kind of). Not very agile if you asked me.
Can't wait to move to git/hg.
I don't need to know any details to agree. Manual merge sucks anytime, anyplace, anywhere.
As a perforce fanboy, i'll just add my unsolicited comments that these kind of merges are a lot easier in perforce, including renames/moves.
Still need to give Mercurial and Git a proper look, my initial overview of DVCS made me feel that they kind of hurt continuous integration because they almost encourage you to hang around on your own branch for long periods of time. But with so much DVCS love out there, i need to give it a closer examination still.
I guess the issue is the 'big merge'. So, why did you let it become a big merge? Maybe I am just stating the obvious here but merging will kill you if you don't do it frequently.
As soon as there were changes in the other branches that were relevant to the work branch, bring those changes over to your work branch immediately. You have to keep track of them daily.
Maybe Mercurial and Git will solve some of the problems but they don't solve your 'big merge' problem either. You just have to merge all the time no matter what you are using. Git just makes it easier.
We branch and merge with TFS quite often and it works very well for us, the exception being designer files that get totally re-written but I don't think anything can deal with that.
Comment preview