[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