On Wed, Oct 10, 2007 at 08:25:15AM -0700, Linus Torvalds wrote:
Yes, *some* SCM's have tried to do that. In particular, the ones that are
"patch-based" tend to think that patches are "identical" regardless of
where they are, and while re-ordering of them is a special event, it's not
somethign that changes the fundamental 'ID' of the patch.
For example, I think the darcs "patch algebra" works that way.
It's a really horrible model. Not only doesn't it scale, but it leads to
various very strange linkages between patches, and it fails the most
important part: it means that merges get different results just because
people are doing the same changes two different ways.
Actually, specifically darcs, different merges _always_ result in the same
data. It's a fundamental part of is patch algebra. No matter what order
you apply a given set of patches, even with conflicts and reordering, you
always get the same result, or no result. Conflicts are "resolved" by
inserting conflict markers in the file, ordered by the patch ID. It
doesn't matter which order you apply them in, you get the same markers.
Then there will be a merge patch which fixes the markers that someone could
apply, no matter what order the applied the previous patches.
Darcs breaks down in a few places, though.
- The no result. Sometimes, it just can't figure out how to reorder
patches. Even worse, occasionally, the implementation will fail to
terminate try to figure this out. There isn't much to do at this
point, except manually apply the patch, hence generating a new patch
ID.
- It doesn't scale well.
The strange linkages between patches could be thought of as a feature,
since it is basically constraining the order that the patches can be
applied in.
There is a darcs-git project that tries to do the darcs things on top of
git.
Dave
-
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
