Karl Fogel wrote:
>Golly.
>
>That's pretty simple. But I can't see anything wrong with it -- at
>the very worst, it preserves too much information (or rather fails to
>compress information), but we can always deal with that later.
>
>Thoughts, folks? Brane, GregH? :-)
>
>
Apart from merges and becoming O(N)? Well, I think it's a nice idea, but
rather naïve and deserves to be scuttled on its maiden voyage, like the
Vasa. :-)
What we should ask ourselves is this: What do we want merge history for?
The simple answer is, "To avoid the repeated-merge problem." Now, while
this solution tells us which versions of which files contributed to a
file's contents, it doesn't give us enough information to implement real
changesets.
That simply isn't good enough. We know (at least I know :-) that we'll
have to at least simulate true changeset knowledge in order to get
variance-adjusted merging. To do that, we'll need a way to track
indivdual diff hunks, their relatedness and collisions. I have a strong
feeling that this cannot be done efficiently in properties. The word
that comes to my mind is "micro-branches", but that's all it is for now
-- just a word, without much substance behind it. I suspect the schema
modification that gives us efficient changeset management will also give
us efficient distributed repositories, and a _lot_ of thought has to go
into that (Bill, don't get hit by a car yet! :-).
If we implemented this proposal now, we'd just have to rip it out later.
Right now, our repeated-merge problem is no worse than CVS's, and is a
bit better in places -- the possible exception is our use of diff3
instead of an (the?) integrated diff library. It think that is
sufficient for 1.0.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Aug 12 03:03:47 2002