-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/2010 06:27 PM, Yury G. Kudryashov wrote: > First of all, I have no objections against mtn but I have some objections > against your reasons.
If only you could add some more criteria, too. I can take this exact feature list and spin a few points against mtn or pro mtn, by the way. This is an attempt to get some replies that clear the positions, not already evaluate all the mentioned DVCS. If someone created a better list (or made specific recomendations about mine), that would be nice. >> What DVCS is used for? I see a few options feature-wise: >> >> 3) Full project history. What, when and where was committed. Maybe with >> some additional security on top of this. > Not storing branch name is an issue and Eelco should decide whether we need > this feature. I haven't tried to use any DVCS system that stores this info, > so I have no experience whether it is really usefull. Could you please > provide any concrete usecase? Can you provide any concrete use case where having CVS-like history is not enough? After all, timestamps allow you to reconstruct the state at any needed moment. When I track back some issues with long and complicated history (like suddenly finding stdenv.bash reference in NixOS which doesn't instantiate anywhere), I try to go back and check when this change was even made. I also try to remember whether this issue was mentioned earlier to direct the search. In this case just "annotate" was not enough, unfortunately. >> 4) Extra information for ease of searching interesting places in >> history. For example, some people put BugID into commit messages. > Easy to do with git. > > I'd add the following: > > 5) Possibility to comment old commits (e.g., "bug #n was introduced here"). > > This is a weak side of git (btw, can we make git clone git-notes?). Now, I meant (5) as a part of a over-complete implementation of (4). By the way, if you teach "git notes" to be useful during search, it would also be nice. >> Now, there are some properties: >> >> 5) Reliability w.r.t. user actions. (Dangerous things are obvious) > Do you write a message "against git", or "what do we need"? Please, list > some dangerous things here. Well, if I mention reliability, it is obviously two-fold. If I want to give an example of dangerous things, these can be forced removal of a revision/certificate in monotone, rollback in mercurial, (workspace-only dangerous) revert in any VCS. If we consider this a significant point and if we recommend people to rebase their changes relative to trunk, we can look at how rebasing should be done in different VCSes. >> 7) Having any architecture behind the tool > Explain in more details, please. "Git *obviously* has no architecture" is > not a reason. Can you give a link on Git design documents not mixed with implementation description? It looks like it has the least clear concept of branch meaning and branch naming among all DVCSes that I have looked at. I would be glad if there is a description of design side of things in Git - it would be nice to read. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMZAyEAAoJEE6tnN0aWvw39b4IAK5qbZ94jPymM/8nmqQ18P7f 4lcKMgEqDoLslclau9OoSjLGcTi6NnPlbtN8QwSEgQ4Kd2IVejCa9rdeyV23oe/0 c3wLff35lBCAJq5x04HP4oGUL1ittGywRftPEZbsrtYWSB7t+UtCOox2xxYbneyN npYP1Wl0r+l98sy5z71WJMcKZE5qR4d5LIq9fx3vvsolne3SamAniyQ5lk2p5JN7 ruAWsSUlI5gjaBOeTnSs8YN/AcyANzhPv2YFx8Q1n33uEE5UTu5JPqS4iLxP4FIm ot0kaRtZT49b5NMOxoas4l4BaGZED7EqctsBR6Q5lZ+MBg3tv0NTi5IBLqoCtO8= =K+T2 -----END PGP SIGNATURE----- _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
