Re: Ada Reference Manual in texinfo format?

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

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.

> 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.

My other gripe with GIT is that it requires a new repository for each
working copy.

On the other hand, I like its append-only storage mechanism where you
can pack a repository on a CD-ROM and "append" to it in your working
copy.

Perhaps the biggest advantage GIT has over Monotone is its ability to
serve repositories from dumb HTTP/scp servers.

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

> 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.

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).

-- 
Ludovic Brenta.