[development] subversion

Chris Messina chris.messina at gmail.com
Wed Nov 16 02:07:55 UTC 2005


Just an FYI, we recently decided at Flock not to go with SVN for our
browser work but to instead use Mercurial
(http://www.selenic.com/mercurial/wiki/index.cgi). Here are the
reasons:

Up sides:

  1. distributed source model
     local versioning and ability to merge with other repositories
  2. native binary support
     no stupid corrupt image files from forgetting to tag things,
     better performance
  3. 3 way merge
     better merging logic for changes
  4. native client-server concept
     better network performance
  5. good performance on all platforms
  6. simple clear architecture
     this is as opposed to svk, or CVS.  I don't see it quite as clean
     as svn, where you can just imagine everything as a file sitting in
     a path
  7. Has concept of both versions and change-sets
     nicer ways to think about changes

Down Sides

  1. mediocre windows support
     seems to work on windows, but the dev team does not have a
     full-time windows user, and there are more "minor" bugs on the
     windows version than UN*X versions (double warning messages, fewer
     command-line shortcuts)
  2. rename support is not yet there
     this is in dev tree
  3. medium disk space usage
     340MB in CVS -> 700MB in HG
  4. Not much integration with existing software
     There is no bug/project tracking system integrations, or very
     many  web front ends to it, though the one it has is pretty good
  5. mediocre branching
     branching is no worse than CVS, but not really much better, not as
     nice as svn/svk
  6. still a bit immature
     but pretty well documented, this is a very active developing project

Other things we evaluated:

svn: is no because of poor performance on large projects especially on windows
svk: is no because it is written in perl and that is not liked by some
developers
cvs: is no because it is old and there are several better options
monotone: is no because it doesn't have real version numbers, and a
very complicated data model
clearcase: is no because it is obscenely expensive, and doesn't have a
detached working mode, and is super complicated, and proprietary
perforce: is no because it doesn't have a good concept of detached
working and is proprietary
git: is no because it doesn't work on windows and has a very specific
work flow in mind
arch: honestly haven't looked at that much, has a complicated model
for versions.

So we're going to use SVN for managing our website and Drupal on our
end, but for browser development, we're using something other than
SVN.

Just thought you guys might like another (poosibly OT) opinion.

Chris

On 11/15/05, Moshe Weitzman <weitzman at tejasa.com> wrote:
> > If anybody wants to code this please get in touch and I'll
> > support it so we can move to SVN.
>
> and if you do, feel free to just commit on top of the current
> svn.module. i built that out of need when few php based svn repos
> browsers were available.
>
> -moshe
>
>


More information about the development mailing list