On Mon, 7 Jan 2008, Shlomi Fish wrote: > > I'm CCing all the correspondents, because I'm banned from the vger.kernel.org > mail. This has been an obstacle for me in several legitimate occassions and > this one is the latest. I'm still CCing it, so the people in the mailing list > will receive the replies. > > On Monday 10 December 2007, Jakub Narebski wrote: > > I have noticed that your SCM comparison at "Better SCM Initiative" > > website > > http://better-scm.berlios.de/comparison/comparison.html > > misses one of the Git, version control system which is used to manage > > Linux kernel, and one of the main open source (distributed) version > > control systems (among Mercurial, Bazaar-NG, Monotone and Darcs). > > > > Indeed git is absent. That's because no one until you has volunteered to send > a patch that adds it to the comparison. Another requirement is for someone to > volunteer to become a "champion" for the version control system and maintain > it into the future. So who is going to be the champion? I can be git champion for "Better SCM Initiative" comparison... although I'd rather somebody else was it. [...] > > Below there is (slightly doctored) patch to the sources for the site. > > > > Despite the fact that I the comparison was recently patched to add Bazaar and > fix some grammatical problems, the patch still applies cleanly. However, I > saw that some people commented on it here. Can you send me a new patch > integrating all this commentary? I'll try to send revised patch soon. Integrating commentary is a bit harder that it could be because some responses were sent _only_ to git mailing list, so I'd have to browse through git mailing list archives. BTW. some of the questions / comments were caused by the fact that the features listed in Better SCM Initiative: Comparison are a bit ambiguous. What does for example "Atomic Commit" mean? Does it mean that if we interrupt commit in the middle we would always get full commit or none, and not some f**d-up intermediate state? Hos CVS can have atomic commits then? What does "Renames Support" mean? Does it mean that when browsing history we [can] show file / directory renames? Does it mean that log of file or directory history [can] follow renames? Does it mean that line-wise file history [can] follow renames? Renames support in merges is as TODO, so I don't think that this one matters in this question. Because the answer, especially in the case of git which is a bit different in that it does rename detection and not rename tracking (using inodes / file-ids), depends on that... -- Jakub Narebski Poland - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
