Jan Wieck JanWieck
Tue Nov 28 12:02:37 PST 2006
On 11/28/2006 6:52 PM, Christopher Browne wrote:
> Preface: This is NOT a change that would take place anywhere near
> immediately; any SCM migration would take place later.
> 
> Jan Wieck wrote:
>> On 11/28/2006 3:43 PM, Christopher Browne wrote:
>>>
>>> Agreeable to me; I'd like to consider moving to some other SCM,
>>> preferably something inherently distributed, like
>>> {Git|Mercurial|Darcs|Monotone} (where that's probably in decreasing
>>> order of preference).
>>
>> What existing problem would that solve and what possible new problems
>> would that eventually introduce?
> One thing that the distributed SCMs all "solve" is that each checkout is
> a full-fledged repository.  No need for special tools like cvsup or for
> special backup tools; any repository could become the authority simply
> by fiat.  Outages of a "central" server become fairly much irrelevant;
> there is no need for access to the "central" server to do diffs or other
> analysis.
> 
> An attendant obvious disadvantage is that a checkout is somewhat bigger.

Nobody using Slony cares for disk space ...

Having the full repository at hand reduces bandwidth when doing diffs 
and other local stuff, which certainly conserves bandwidth.

> 
> A few little stats...
> 
> Repository         Size    Size of tarball
> -------------------------------------------
> Darcs              17660k        4916k
> Mercurial          13656k        4412k
> CVS                18096k        1928k
> Subversion         19572k        5208k
> Git                18444k        9092k
> 
> CVS Checkout (HEAD): about 11M
> 
> <http://www.dwheeler.com/essays/scm.html>
> -----------------------------------------------
> CVS <http://www.cvshome.org/> is extremely popular, and it does the job. In fact, when CVS was released,  CVS was a major new innovation in software configuration management <http://www.dwheeler.com/innovation/innovation.html>.  However, CVS is now showing its age through a number of awkward limitations: changes are tracked per-file instead of per-change, commits aren't atomic, renaming files and directories is awkward, and its branching limitations mean that you'd better faithfully tag things or there'll be trouble later.   Some of the maintainers of the original CVS have declared that the CVS code has become too crusty to effectively maintain. These problems led the main CVS developers to start over and create Subversion.
> -----------------------------------------------
> 
> Generally, the newer SCMs support atomic commits, better handling of renaming things, and more sophisticated branching.

Can I have a few days off to play with all this?


Jan


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #



More information about the Slony1-general mailing list