Not a holy war - just some salient facts

[Steve Borho]

On Thu, Apr 8, 2010 at 9:23 PM, Mike Meyer <mwm at mired.org> wrote:
> On Thu, 08 Apr 2010 17:45:09 -0500
> Harry Putnam <reader at newsguy.com> wrote:
>
>> Can some advanced user here list reasons why bazaar might be better
>> than mercurial, for the usage described briefly below.
>>
>> Or, if merc would, in fact, be the better tool.
>>
>> Usage scenario:
>>
>> One repo each for hosts on home lan.  At least the linux/opensolaris
>> hosts. Which amounts to some 8 hosts.  (Some are vmware guests on
>> windows machines).
>>
>> Not much need for repos on windows machines here.  Or at least, I've
>> never really felt the urge to do programming or experimentation on the
>> windows machines, beyond installing various bits of software.
>>
>> 1) (Probably) Main usage is keeping versions of quite a few OS related
>>    `rc' files.  Quite a few under /etc but also /boot and the
>>    directories that contain my 150 or so scripts. Also a few under
>>    /var.
>
> For this kind of thing, I'd say neither mercurial nor bazaar works
> very well. Both of them store the repo with the files in question,
> which means you need to keep backups of all this stuff. Using a
> server-based VCS avoids that: you have the stuff that came with the
> distribution, and then as you config the machine, you add/edit/commit
> the changed files. You back up the central repo, and don't need to
> worry about backing up the os/config parts of the clients.
>
> CVS-derived VCS systems are slightly better - they at least store the
> content on the server. However, the information about what's actually
> on the server is stored in little turdlets scattered all over your
> file system. If this is in any way complicated, you have to back that
> information up somewhere.
>
> FWIW, perforce rocks for this, as it stores *everything* on the server
> (normally a performance problem), including what parts of the repo map
> to where on the file system, with no turds at all in your local file
> system. Restoring a completely trashed system amounts to doing enough
> config to get it on the net under the old name, then doing "p4 sync
> -f" at the root of the system.

I find the backup argument for central VCS pretty weak.  All of the
major DVCS allow one to easily automate pushes to backup locations.
And these backup clones are typically much easier to backup to media
than a live CVCS server.

--
Steve Borho