Daniel Carrera <[EMAIL PROTECTED]> writes: [...]
> Yeah, I was just reading up on those three (I already know Darcs and > it doesn't use signatures). A lot of people say that Git is > complicated and poorly documented, so I'm ignoring Git. Mercurial and > Bzr both look easy to use, but like you say, they don't seem to have > digital sigs, or the over-all security of Monotone. I'm not convinced that such opinions of git are fair. It's true that it's not a particularly cohesive design, but it's not nearly as bad as it used to be (so I hear---I've only used versions later than 1.5). Underneath, the model really is cohesive, and is (IMHO) just as simple as monotone's. The issue is all the higher-level commands that enough people thought useful, and those commands don't always fit together very well (because nobody uses all of them). See <http://eagain.net/articles/git-for-computer-scientists/>, <http://cworth.org/hgbook-git/tour/>, <http://www.kernel.org/pub/software/scm/git/docs/user-manual.html>, <http://book.git-scm.com/>, for examples of good documentation of git after 1.5. Avoid documentation that mentions cogito, or seems more than a couple of years old. (The first link is different---that's just the underlying DAG model which hasn't changed much.) I think the three systems do offer signing, just not as pervasively as monotone. Ah, OK, bzr doesn't (yet) by the looks of it. The other two do: <http://www.kernel.org/pub/software/scm/git/docs/git-tag.html>, <http://www.selenic.com/mercurial/wiki/index.cgi/GpgExtension>. In the git case you can sign (and verify) a tag object using gpg. Such a tag will reference a revision, so transitively that gives you assurance of the history. (In that case it's not much different from monotone; in monotone revisions aren't signed, rather the things attached to revisions get signed, so if you have a tag, the only signature that matters (arguably) is that one signature.) >> Ease of use probably varies according to taste. Viewed from a >> distance they're all (disappointingly) equivalent, storing DAGs of >> snapshots. > > DAG? Directed acyclic graph. (i.e., revisions typically have one or more parents and one or more children, and that graph never has cycles.) So different to darcs's set of patches model, and probably different to AccuRev's streams model. ("disappointingly" because it feels like there ought to be other workable models, even if I don't have good ideas of what they might be. It's perhaps worth mentioning for the n-th time that these systems tend to credit monotone for the basic DAG model (where you hash the revision (including its parents) to get the new hash, so you have a chain of hashes).) >> They differ more in the details, and which details matter probably >> varies. > > Yeah. Ex: Linus cares a lot about quickly merging large trees, Mozilla > cares about decent performance on Win32 (so they chose Mercurial), > etc. For me, desirable features include ease of use, security and > being able to push changes to a live web host. Mercurial seems to have > the 'push' part: > > hg push ssh://[EMAIL PROTECTED]/public_html/main > > So, if indeed I can't run Monotone on the server, I'll have to balance > out Monotone's signatures against Mercurial's push. I'm not sure what > I'd pick, but I think I'd lean toward the push (Mercurial). But what does "security" mean for you? I think monotone's security has legs: if you use monotone, then you can trace every cert to its signer, so you can find who made each assertion about each revision. (Well, you can see which key was used, anyway.) That feels potentially of value to an open source project that might need to defend itself. But maybe you just want to be sure that nobody else has changed something, in which case adding a signed tag now and again might be enough. Or just make a note somewhere of the most recent commit hash. >> I work in an environment where we do code review (for every >> change), so git's idiosyncratic (and awkwardly named) index, and >> ability to revise commits (and ultimately automatically discard older >> versions) is natural and valuable: it provides better support for the >> workflow we used with CVS (preparing patches in a checkout, emailing >> them out, then often revising them before integration). > > Interesting. I didn't know about that about Git. As a sole developer > that feature doesn't apply to me. But it's interesting. Perhaps it doesn't apply, though I'd be surprised if you didn't find it useful. > Do you use Monotone anywhere? I ask because you are, after all, in a > Monotone mailing list. I used to use it, but I don't any longer. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel