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@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/