Re: version control systems

[Stephen Leake <stephen_leake@stephe-leake.org>]

Ludovic Brenta <ludovic@ludovic-brenta.org> writes:

> Stephen Leake writes:
>> I've finally decided I need to use a distributed CM system at work
>> (I've been using CVS). I'm looking into using 'git', mostly because
>> there is a Cygwin port for it, and the Linux kernel developers use
>> it, so I think it is well-supported.
>
> Yes, and X.org also uses it for the same reasons.

Although now I see there is also a Cygwin package for monotone.

>> For a similar purpose (trusted vs untrusted committers), they
>> recommend using branches. Apparently it is easy in git to
>> synchronize two branches periodically.
>
> Yes.  All the new distributed VCSs handle and keep rack of merges
> properly, so repeated merges are usually not a problem.  GIT also
> allows you to crypto-sign revisions, but that's optional whereas in
> Monotone it is mandatory.  How can you trust unsigned revisions?  The
> only way is to review them manually.  How can you ascertain their
> origin, if someone challenges your copyright?  You can't.

That is an interesting point.

> All in all I think that GIT is pretty good, but Monotone is even
> better.  I even wrote a paper about this:
>
> http://www.ada-france.org/debian/distributed-version-control-systems.html

Thanks for that. I did wonder about the storage efficiency of git. I
could not believe they actually stored a whole new file for each
revision! The "pack" option was not mentioned in the git manual I
read.

>> That seems more straight-forward to me than the monotone trust
>> mechanism.
>
> I'm not sure how straightforward that is; I think this model is
> fundamentally flawed.  In a distributed VCS, anyone can commit to any
> branch they please, since they control their own repositories.
> Therefore, you don't trust "branches" but "revisions".
>
> So, in GIT, you'd have to carefully merge from a published but
> untrusted branch (i.e. one containing untrusted revisions) to your
> unpublished and trusted branch, and manually apply your trust criteria
> on each merge.  GIT does not allow you to keep track of which
> revisions you chose to trust the last time you merged, so each time
> you merge, you may see the same untrusted revisions again and again.

That's true.

> In Monotone you'll never see the untrusted revisions at all, if you
> don't want to; and you can "approve" a revision to record the fact
> that you trust it.  Granted, it seems more complicated but it is also
> more correct, IMHO, than GIT's model.
>
>> But I'd have to actually use both on a real project to be sure. Of
>> course, I don't have the time for that :(.
>
> In a few years, maybe there will be a clear winner between svk, GIT,
> Monotone, Mercurial, Bazaar-NG, Arch and Darcs, but in the mean time,
> I've come to terms with the notion that I'll use many VCSs
> concurrently, perhaps a different one for each project.  I have no
> problem using GIT to update Debian, if that's what you want.  (I do
> have a problem with svk and Subversion, though).

Well, I have not actually started using git. In fact, there's a
problem compiling it on Lynx (the real-time OS that is my main
application's target). So I'll give monotone a try.

-- 
-- Stephe