Below, I will refer to the information from: http://wiki.services.openoffice.org/wiki/SCM_Migration#Evaluating_the_SCM_candidates.2C_Metrics
(thanks to Meeks for pointing me there) On Tue, Jun 14, 2011 at 11:28, Mathias Bauer <[email protected]> wrote: > > From our own experience the biggest problem with svn was merging of > branches. The above page was written using Subversion 1.4. That was before we had merge tracking features, and before a number of merge-related optimizations. We're now on the cusp of releasing Subversion 1.7. Infrastructure has been discussing whether to install a build on the server. It definitely has some faster merging, and much better features. > We often had features that took several months of development time. We > didn't want to commit incomplete or buggy code to our master, so we created > feature branches for them and called them "child workspaces" (cws). When a > cws was finished, it had to be synchronized with the current master before > it could be integrated. Developers also might want to merge in changes from > master into their branch in between so that code change conflicts can be be > reduced or solved early. Right. We use the same in the development of Apache Subversion itself. "svn merge" is used to keep the branch up to date. "svn merge --reintegrate" to bring it back onto trunk. Merge tracking makes this much, much easier than when you had to do it (no anchor tag, for example). I know that Subversion is slower in some ways from Mercurial or Git, I believe that the CWS process amplified that problem. > This merging of branches took hours with svn and was a PITA. With Mercurial > it usually took only a few minutes and it was done completely on a local > computer. No problems with slow or interrupted internet connections. We do the merges on a local computer, too. It is impossible to merge only on the server (it cannot resolve conflicts). > Beside that, if you ever worked with a DSCM, you never want to go back to a > centralized SCM. It's as easy as that. The OOo repo is huge, but with > Mercurial it took only a few seconds or minutes to create a clone or 10 > minutes to get the source from it. Checking out from svn over http took > hours. But I'm sure the pros and cons of DSCM are known. The page from above did not show "hours" for non-Windows developers. Since that old 1.4 release, we have fixed Windows checkouts. Their performance is comparable to the Unix-ish platforms. To be specific, it says a Unix checkout to local disk is a mere 5 minutes. That sounds faster than Mercurial. [and I'll note that it says a Windows git checkout did NOT even complete] > > *If* we had some options, I would like to think about the following ones: > > - start with svn and decide later (at least in the next few months we won't > need feature branches a lot) This is the only choice available to us at this time. > > - have svn for the master and do all work on a git repo elsewhere that at > times is pushed to the svn master People use git-svn to do some work, but I seem to recall hearing that it does not manage the merge-tracking information properly. And that it may not deal with properties either. I think we would want some git-svn people to detail any pitfalls if that tool is recommended at all. > > - start with a git repo from the beginning As stated elsewhere, this is not available right now. There are the technical issues, and I know that many people also have concerns with potential community issues. But that is all a discussion for a later time. Not here and now. Cheers, -g
