http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660We 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. http://ayende.com/4000/the-big-merge#comment14http://ayende.com/4000/the-big-merge#comment14Fri, 08 May 2009 18:48:58 GMTI 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. http://ayende.com/4000/the-big-merge#comment13http://ayende.com/4000/the-big-merge#comment13Fri, 08 May 2009 18:21:16 GMTAs 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. http://ayende.com/4000/the-big-merge#comment12http://ayende.com/4000/the-big-merge#comment12Fri, 08 May 2009 17:28:55 GMTI don't need to know any details to agree. Manual merge sucks anytime, anyplace, anywhere. http://ayende.com/4000/the-big-merge#comment11http://ayende.com/4000/the-big-merge#comment11Fri, 08 May 2009 15:18:04 GMTAnd 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. http://ayende.com/4000/the-big-merge#comment10http://ayende.com/4000/the-big-merge#comment10Fri, 08 May 2009 15:10:18 GMTI can see it now... Rhino.Merge http://ayende.com/4000/the-big-merge#comment9http://ayende.com/4000/the-big-merge#comment9Fri, 08 May 2009 14:15:29 GMT"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 ? ;-) http://ayende.com/4000/the-big-merge#comment8http://ayende.com/4000/the-big-merge#comment8Fri, 08 May 2009 13:58:53 GMTThe 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. http://ayende.com/4000/the-big-merge#comment7http://ayende.com/4000/the-big-merge#comment7Fri, 08 May 2009 13:44:17 GMTSubversion 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](http://subversion.tigris.org/issues/show_bug.cgi?id=898) and [subversion.tigris.org/.../...enames%20problems.ppt](http://subversion.tigris.org/nonav/issues/showattachment.cgi/729/Subversion%201.4%20true%20renames%20problems.ppt)), which is a shame because is making it pretty dangerous in many scenarios. http://ayende.com/4000/the-big-merge#comment6http://ayende.com/4000/the-big-merge#comment6Fri, 08 May 2009 13:28:46 GMTI 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) http://ayende.com/4000/the-big-merge#comment5http://ayende.com/4000/the-big-merge#comment5Fri, 08 May 2009 13:28:46 GMTTake a look at this link: [google-code-updates.blogspot.com/.../...sting.html](http://google-code-updates.blogspot.com/2009/04/mercurial-support-for-project-hosting.html) and the analysis that they do of Git and Mercurial: [http://code.google.com/p/support/wiki/DVCSAnalysis](http://code.google.com/p/support/wiki/DVCSAnalysis)http://ayende.com/4000/the-big-merge#comment4http://ayende.com/4000/the-big-merge#comment4Fri, 08 May 2009 12:42:14 GMT"The one that likes to merge has yet to be born" LOL http://ayende.com/4000/the-big-merge#comment3http://ayende.com/4000/the-big-merge#comment3Fri, 08 May 2009 11:42:56 GMTIt'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). http://ayende.com/4000/the-big-merge#comment2http://ayende.com/4000/the-big-merge#comment2Fri, 08 May 2009 09:33:46 GMTThe one that likes to merge has yet to be born http://ayende.com/4000/the-big-merge#comment1http://ayende.com/4000/the-big-merge#comment1Fri, 08 May 2009 07:27:39 GMT