From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b88c7b1a4db3246c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.scarlet.biz!news.scarlet.biz.POSTED!not-for-mail NNTP-Posting-Date: Thu, 08 Feb 2007 08:21:55 -0600 From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Ada Reference Manual in texinfo format? References: <87sldpo83w.fsf@ludovic-brenta.org> <4dCdncquF5TP71_YnZ2dnUVZ_tOmnZ2d@megapath.net> <87odo9lhog.fsf@ludovic-brenta.org> <1170681175.011450.167450@k78g2000cwa.googlegroups.com> <0-adnRXpj9QKU1rYnZ2dnUVZ_t2tnZ2d@megapath.net> <1170752459.890968.12150@v33g2000cwv.googlegroups.com> Date: Thu, 08 Feb 2007 15:21:55 +0100 Message-ID: <87fy9genlo.fsf@ludovic-brenta.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:IqfrrRbFECBwWJUvIjzmm4sElns= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 62.235.202.12 X-Trace: sv3-IUrd83BhzaGrrArVAVyMipY/PDkoXfMTkg2zm4ZGH22SD+b5pJo/ZvO/XrUZDyxDZYK9Dc94r0noooP!1eQOXdRW5IggujzgyM4OdlQFVdWC7OXTCKvqEzl3W7I47HjZpoZNB0uE9zb/ymgzFH2Qaf0l3Q== X-Complaints-To: abuse@scarlet.be X-DMCA-Complaints-To: abuse@scarlet.biz X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:9142 Date: 2007-02-08T15:21:55+01:00 List-Id: 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.