[Nix-dev] Re: DVCS - what we care about?

Michael Raskin 7c6f434c at mail.ru
Thu Aug 12 17:00:21 CEST 2010


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



More information about the nix-dev mailing list