[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: Folker Schamel <schamel23_at_spinor.com>
Date: 2007-12-09 20:03:21 CET

Folker Schamel wrote:
> Hi David!
>> 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?
> No, what I suggest is simply that svn:mergeinfo contains all path@rev
> which have been merged into that path directly (but not indirectly).
> For example, if you have
> trunk@30 has svn:mergeinfo = branch1@1-20
> branch1@25 has svn:mergeinfo = branch2@1-7
> branch1@30 has svn:mergeinfo = branch2@1-10
> and then you merge branch1@26-30 into trunk as r31,
> then, according to my proposal, you get simply
> trunk@31 has svn:mergeinfo = branch1@1-20,26-30
> but NOT (as currently, if I understand it correctly)
> trunk@31 has svn:mergeinfo = branch1@1-20,26-30;branch2@8-10
> and also NOT (as your interpretation)
> trunk@31 has svn:mergeinfo = branch1@26-30

     (A) trunk@31 has svn:mergeinfo = branch1@1-20,26-30
     (B) trunk@31 has svn:mergeinfo = branch1@1-20,26-30;branch2@8-10
     (C) trunk@31 has svn:mergeinfo = branch1@26-30

Scheme (A) and (C) are just different representations of the same
information, so both would work.
I personally just would prefer (A) to (C) for simplicity
and being "more natural".
While (B) lacks information as discussed.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 9 20:03:53 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.