hg, git, fossil, ...

[Lele Gaifax]

Marko Rauhamaa <marko at pacujo.net> writes:

> Chris Angelico <rosuav at gmail.com>:
>
>> What you're saying, though, is that there's something inherently
>> special about file boundaries. You want files to be magically
>> separable within a repo. Why? What's the significance of the file?
>
> Files do have that magic property. That's only an approximation, but it
> is a very accurate and fitting approximation. Developers have a strong
> tendency of collecting functions to files. More to the point,
> functionality may be split across multiple files, but a large repository
> is far too blunt an abstraction.
>
> As I have mentioned, Darcs tries to get everything right. I haven't used
> it, but I have read it sometimes gets entangled in its smart algorithms.

Well, even conceding the file specialty, and more than that acknowledging
the extraordinary beauty of the darcs model, it too considers a patch
spanning several files as an atomic operation.

So, even if it makes very very easy to "cherry-pick" a given changeset,
it still insist in carrying in all the changes it involves: in your
scenario, you'd still need to withdraw the (unwanted) modifications
applied to the other files, recording an additional changeset with the
reverts.

As you cited in a later messages, unlike other systems which focuses in
tracking files *content*, darcs tracks *patches*: files content is
solely determined by the patches collected in the repository they
live. Darcs patch theory "promises" that non-conflicting patches may be
applied in any order (they can be commuted at will), that's what makes
"cherry-picking" a very common/no fuss operation. OTOH, that's also
exactly the main reason (the other is performance...) why Linus
discarded that tool when he looked around for a Bitkeeper replacement.

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele at metapensiero.it  |                 -- Fortunato Depero, 1929.