On Tue, 2008-11-11 at 16:13 -0500, Bill Branan wrote: > During our developer meetings last week, Eddie brought up the > potential of switching from Subversion to Mercurial for source > control. After doing some reading (and no actual experimentation) I > wanted to put out my thoughts in order to get the conversation going > again. > > Benefits provided by Mercurial: > - Performance gains when doing commits, diffs, and merges against what > is currently in the central SVN repository > - Ability to work completely offline (such as in an airplane) > - Potentially promotes a more open feeling with regard to community > members having the ability to commit code changes > - Allows for private code experimentation without the need to make > formal commits to formal branches > - No more .svn directories everywhere
Not to muddy the waters too much, but I just switched to using git a few weeks back and really like it. These two articles helped me decide: http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html Git has git-svn making working with existing svn repos simple - I don't know of such a tool in Mercurial. Regardless, Mercurial and Git are both needed updates for the VCS world, I'd support any migration to them. P > Notes: > - We would still need a copy of the code acting as a central > repository in order to perform backups and keep a continuously > integrated trunk over which automated tests can be run > - Merging would likely still need to happen with a centralized > repository, otherwise the need to merge the same changes into multiple > places could become a major headache, not to mention the issues > related to keeping track of which changes have been merged where. > > > Concerns: > - Committing locally means that until you merge your branch, none of > your work is backed up. This puts the burden of consistent code > backups on each developer. > - SVN provides code-watch updates on each commit which helps > developers keep track of what everyone else is doing. With local > commits we would likely only see such messages on branch merge. In > general, it seems that a central repository promotes more openness and > communication than a distributed source model. > - It's not clear how tagged releases would work with Mercurial. > - We're requiring the community to become familiar with a new source > control system in order to work with our code, could this be an > unintentional barrier to entry? > > Thoughts? > > Bill > > p.s. I found this blog posting (particularly the comment trail) to be > particularly useful in thinking about the tradeoffs: > http://blog.red-bean.com/sussman/?p=20 > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ Fedora-commons-developers > mailing list [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers -- Phil Cryer | Open Source Dev Lead | web www.mobot.org | skype phil.cryer ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fedora-commons-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
