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

Re: Progress of extract and merge non-reflective changes from a reflective rev

From: Tom Widmer <tom.widmer_at_camcog.com>
Date: 2007-12-11 18:54:09 CET

Tom Widmer wrote:

> A crucial thing for some of the merge tracking algorithms to work is
> that the implementation must be able to distinguish between:
> a) direct merge info
> b) indirect merge info
> Since b) is reconstructible from a), it makes sense for the mergeinfo
> property only to contain a) (proposals A and C). Proposal B, the current
> state of affairs as I understand it, is a 'dead end' since it doesn't
> distinguish between A and C. An alternative, that might make you both
> happy since it might avoid the need for SQLite for 1.5, is proposal D,
> something like:
> (D) trunk@31 has svn:mergeinfo = branch1@1-20D,26-30D;branch2@8-10I
> Where D and I are for direct and indirect, respectively.
> It's likely that I information in the mergeinfo property will be ignored
> in some future version of SVN, once the advanced use cases for for
> merging are implemented, since they may need a database to optimize
> various lookups, beyond what is in the mergeinfo property.

svn:mergeinfo = branch1@1-20,26-30;
svn:indirectmergeinfo = branch2@8-10

The point is to keep svn:mergeinfo clean and future proofed - as long as
it says exactly what the merge performed was (basically what command was
typed in to do the merge), there shouldn't be a problem.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 11 19:04:51 2007

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.