[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: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-09 19:35:52 CET

On Dec 9, 2007 4:50 AM, Folker Schamel <schamel23@spinor.com> wrote:

> To verify that I understand you correctly,
> I try to rephrase it in my own words.
> Can please you acknowledge that I am correct? Thanks!
> Subversion stores two kind of merge-information:
> a) "exact revisions/path that was merged for a given transaction".
> b) "The [current] mergeinfo itself might contain additional
> information that came from the merge itself.".
> Information a) is currently stored only in SDLite indices, right?
> And a) is what I propose to store in the mergeinfo property, right?
> Information b) is currently stored both in SQLite indices
> *and* in the mergeinfo *property*, right?
> And information b) can be reconstructed from a), right?
> (Ignoring performance implications at the moment.)
> Then, my proposal is the following:
> Why not just changing the meaning of the mergeinfo property
> so that the mergeinfo property represents a) instead of b)?

Hmm, so you are proposing that the svn:mergeinfo property for path P
at revision R contains information specifically about what happens at
revision R?

If this really is a normal svn property, does that not imply that when
revision R+1 is committed, no matter where on the tree that is, we
also have to clear out all the svn:mergeinfo properties committed in
revision R?


David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 9 19:36:10 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.