[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [merge-tracking] replicating commits

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-07-15 08:43:25 CEST

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.