[development] subversion

[Trae McCombs]

It took a while, but I finally found the License.  It seems it is GPL,
which gets a thumbs up from me. :)

That said, isn't it best to simply stay with a devil you know vs. one
you don't?

Trae

On Tue, 2005-11-15 at 18:07 -0800, Chris Messina wrote:
> 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
> >
> >
-- 
Trae "occy" McCombs || http://occy.net/
      Founder - Themes.org // Linux.com
    CivicSpaceLabs - http://civicspacelabs.org/