>
> I think that the merge-tracking scheme that is used by svnmerge.py and
> by the proposed merge-tracking extension to SVN will probably work
> pretty well for simple merge topologies. But if there are any loops in
> the undirected graph of branches between which revisions have been
> merged, then it will break down.
>
There is no need to say this is an opinion (using 'think').
This is a fact :)
> Only in the case that the deltas are identical for B->A and B->C will
> the merge code recognize that A->C is a noop. This problem is intrinsic
> to merge tracking the way that it has been implemented in svnmerge.py.
> Usually it is not noticed because people use a very simple merge
> topology (out of fear?).
Right. The fact that most people do simple merges is one reason why i
chose the scheme. However, the main one was that it could be
implemented fairly easily, and would provide some level of merge
tracking without making it impossible to do more later.
>
>
> It seems to me that what one wants to track in a merge-tracking system
> is the creation and motion of "novel changes".
> [On IRC I referred to
> these as "original revisions", but I think the new name is less
> ambiguous.] I define a novel change to be one created by a developer by
> the application of brainpower and emacs (as opposed to a change
> resulting from a merge):
>
> novel change == a change made from scratch (not via a merge)
>
> Most of the intellectual content of a project is in the novel changes,
> whereas (I'm exaggerating here) merges are mostly a matter of
> bookkeeping and tidying up.
Sure. This is no different than any other history sensitive merge.
Your goal is to avoid mergeing any change that already exists in your
code. Except for hand patching (which you can't detect without
ridiculously sophisticated bookkeeping), all changes already existing
in your code come from merges, so all you really need to keep track of
is which *non-merge* changes exist, and merge those.
I am positive using such a scheme would give you better information,
and had i thought it could be done in 3-6 months, I would have :)
The problem with it is that it requires teaching the WC layer, RA
layer, and FS layer to be able to communicate which files were changed
due to merge, and which weren't (I firmly believe trying to track at a
level more than that, which would be required
This is non-trivial, and not something i wanted to attempt for 1.5,
when the original goal was to get something that can do what
svnmerge.py does, and maybe a little more.
I don't see why you couldn't implement something like this for 1.6/1.7
or 2.0 (depending on the changes required), and I disagree with your
irc statement that doing what the merge-tracking branch does somehow
makes it harder to move to such a scheme later than it already is.
Unless you're going to implement something to walk the FS history and
heuristically discover which changes were made through merges, and
which weren't, nothing will give you the info you want.
At least the current merge tracking scheme would tell you where each
merge occurred, so you could figure this info out.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 26 02:12:42 2006