I [url=http://www.ogre3d.org/phpBB2/viewtopic.php?t=40994migrated] the OGRE CVS repository over to Subversion[/url] this weekend, something I’ve resisted in the past due to some problemsI’d had when using cvs2svn with our rather old and branch-litteredrepository. In all honesty, some of the problems were probablyself-inflicted since I’d experimented with branch aliases a few yearsago which cvs2svn previously didn’t like very much, but luckily thelatest version has coped acceptably. For some bizarre reason whenimported into Sourceforge the conversion decided to ressurrect a ton offolders & files that had been deleted long ago in CVS, which hadn’thappened when I tested this whole process locally, but all the otherfiles did seem to be correct so some swift purging of the cheekyLazaruses resolved it. Subversion’s advantages over CVS are well known - the local diffs,the unified changesets & global revision numbers, nice tools like [url=http://www.orcaware.com/svn/wiki/Svnmerge.pysvnmerge[/url.It’s] not perfect though - it’s slower than CVS when checking out andcommitting, occasionally has a habit of corrupting the local workingcopy (hence the need for svn clean), and its approach to tags is plaindumb. The Subversion developers clearly liked the fact that they canabstract almost every action into a ‘copy’, but in practice this isn’tnearly as clever as they think it is, and doesn’t actually work well atall for tags. For a start, you should never be able to commit to a tag,and yet you can in Subversion - configuration managers the world overtend to find this to be a breaking of holy scripture. Secondly, becausethe [i] source of the tag has no knowledge of it (because it’s justthe source of a copy), you can’t look through the log of the branchfrom which the tag was taken and see an easy-to-read tag point there,as you can in CVS. That actually applies to branches too in fact, theorigin point of a branch is only stored in the branch itself, not inthe trunk (or whatever other branch it was spawned from), so from thesource of the branch you can’t easily see where it splits off. Yes, youcan solve it by relying on the fact that the start of the branch/tagwill have a repository-wide revision number, and therefore you can lookat the SVN revision log for the trunk / originating branch and [i] infer that because the start of the branch comes between commits X and Y onthe trunk, that’s where the branch/tag was taken. Sucks though, it’smuch nicer to be explicit about these things, rather than using the‘copy’ blunt instrument for everything - this is precisely why the‘Revision Graph’ is so damn slow on TortoiseSVN even for a single file,when it’s very quick on TortoiseCVS. My hope is that they’ve addressedthis in Subversion 1.5 along with branch merge tracking. On balance though, Subversion is generally the most convenient foreveryday development tasks so it’s still worth using despite theannoying niggles. [url=http://www.perforce.com/Perforce[/urlis] an even better choice if you can afford it but most won’t choose to(it’s free for open source use, but my guess is most people feel saferfrom any future changes in that policy on Subversion), and alternativeslike [url=http://msdn2.microsoft.com/en-us/vs2005/aa718670.aspxVisual] SourceSafe[/url] and [url=http://www.softimage.com/products/alienbrain/AlienBrain[/urlare] wholly inadequate in modern times, both because of their chronicinability to work well remotely, and their primitive support forconcurrent development practices. Of course, in the eyes of the open source world, any centralisedrepository system is strictly a bit ‘old skool’ now, even the popularSubversion. [url=http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/Distributed] version control[/url] systems (DVCS) are all the rage now, and I can see why, since they mostdirectly represent the open source development methodology. The idea isthat there is no central repository (although in practice, there arebound to be those which are considered more authorative), and everydeveloper is capable of synchronising / merging with every otherdeveloper in a peer-to-peer, ad-hoc fashion. Tools like [url=http://darcs.net/Darcs[/url]], [url=http://git.or.cz/Git[/url]] and [url=http://www.selenic.com/mercurial/wiki/Mercurial[/urlimplement] this methodology, and in theory, I love the idea. Certainly Ican think of several cases where it would have been useful to allowthird parties to synchronise their working copies with each other moresmoothly & traceably - say, a small ad-hoc subgroup trying out anew technique which may take some time before it’s ready for thecentral version but people need to collaborate on it, sometimes withoutthe direct involvement of the central team. Also, improvedcontext-aware branching and merging as supported by these tools woulddefinitely be useful to me as in a number of cases, quite large patchescan get out of date while lenghty testing goes on, increasing thechances of conflicts when finally applied. So, in theory I love DVCS - it probably wouldn’t be very natural fortraditional corporate teams but for open source, and for some of thedistributed commercial teams I’ve worked on, it could be very useful.The problem I see with them right now is that they’re lacking in goodtoolsets; most are command-line only and some were clearly designedwith primarily Linux in mind (e.g. Git, which requires Cygwin to run onWindows). They also tend to be more complex, by nature of themany-to-many synchronisation approaches and high level of flexibility.I think given some more time, they will eventually supercede Subversionin the open source space, and perhaps even some corporate use, butright now I see them very much as I saw Subversion 5 years or more ago- some great ideas but most people will prefer to stick with the mature& well understood solution for now. Once we have a stable andmature TortoiseGit and Eclipse / VS integration, mainstream adoptionwill follow I’m sure. I would venture that most developers would beloathe to give up their slick Explorer / IDE integration for the kindof flexibility DVCS offers, because in most cases they need theintegration more than they need the uber-branching; as useful as thatis, it’s probably something that comes up only rarely except in themost popular open source projects.