By the way, the changeset meeting with Phil McCoog was very fruitful,
in terms of understanding the use cases and identifying gotchas. The
reason I haven't posted a novel about it is that it doesn't really
affect Subversion coding for the recent future. Here's the main
thing:
Branches and merges need to preserve ancestry meta-data. This is
partially to avoid the repeated-merge problem we all know and love
from CVS, and partially so that external facts attached to the
meta-data (such as bug id numbers or release notes) can correctly
follow changes across branches and merges. The meta-data needs to
be "non-historically user-editable", since it's always possible
that someone may manually undo the semantically significant portion
of a merge before they commit, and that this won't be realized
until later.
The current spec already talks about this sort of thing, but
hand-waves on some of the details. :-) We discussed the details some
more during the meeting, but they don't change the direction of
Subversion development anyway. To implement a true, ground-up
changeset engine would give us a very different beast from the
line-based repository model Subversion uses, and the goal of the
project is, after all, to replace CVS.
That's all on changesets for now. When we get to the genetic merging
stuff later, *after* basic Subversion is working :-), we should talk
about this in more detail.
-K
Received on Sat Oct 21 14:36:19 2006