Re: [merge-tracking] replicating commits

Giovanni Bajo wrote:

> Did you already consider this problem?
Yes, and I don't think replicating commits is a good answer, I think
it's a workaround :).

> Do you have any possible solution in
> mind?

So, the real problem here is that merges are not considered a seperate
operation, they are just a bunch of adds, deletes, and changes applied
to a versioned tree. We don't know it's a merge if we look at history.

You will never perfectly be able to tell, even if you were to add a
property, because someone could always tweak the property post-hoc.

That said,

> If you keep merge-tracking history in revprop, so that r100 has a revprop
> saying "I'm a merge of r10-20" (which is what you are doing, IIRC), would it be
> possible to tweak svn log/svn blame so that they follow these "merge links" and
> display information based on the original revisions?

This is not necessary with the mergeinfo scheme, nor would it help.
It is just as good/bad as querying for a list of when mergeinfo has
changed for a given path, and saying any time forward mergeinfo changed,
 the operation was a merge, not a real change, and exclude that author
from blame results (or something similar).

One of the reasons for indexing mergeinfo was to make this querying very
very cheap.

--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 15 08:44:43 2006