[Svnmerge] Ignore initialized rev

[Raman Gupta]

Raman Gupta wrote:
> Rich Williams wrote:
>> On 9/21/06, Raman Gupta <rocketraman at fastmail.fm> wrote:
>>>> On Wed, 20 Sep 2006, Rich Williams wrote:
>>>> ...
>>>>> - a way of suppressing the revisions which are just setting up
>>> branches
>>>>> (i.e. Initialized merge tracking via svnmerge).
>>> The -b switch handles this fine... or did I misunderstand you?
>> Well I'm not sure what we're doing wrong then, because we
>> see quite a bit of it - doing 'avail' from our trunk to our live
>> branch at the moment, roughly 16% of the available revisions
>> are 'Initialized merge tracking' (we have 36 branches just now).
>>
>> I've attached a simple script which will reproduce it - it'll destroy
>> and create a repository and working directory in the directory it's
>> run from, so please don't run it from anywhere important!
> 
> Thanks for the repro recipe -- ok, it seems like the -b flag is not
> recognizing the "Initialized" revs as reflected (which in a strict
> sense they are not). However, when the actual merge is executed
> svnmerge.py -b does manage to do the right thing.  Strange.

I took another look at this. As I said above, it is actually correct
that the Initialized rev in Rich's recipe is not considered reflected,
since that revision deals with an unrelated branch rather than the
current target. Regardless of this however, I think that it SHOULD be
filtered out from BOTH the bidirectional and vanilla merge --
svnmerge.py currently does not support "transitive" merge data in any
meaningful way, therefore any revs that deal only with merge metadata
for tracking branches not related to the current source or target
should be excluded from merging.

Currently, we check for and exclude "phantom revisions", "reflected
revisions" (with -b), and "blocked revisions". Excluding the
initialized revs should, I think, be added as a forth category. Opinions?

On a slightly related side note, one thing that was not clear to me
was why "svnmerge.py merge -b" as the last step would not produce a
conflict in the svnmerge property, while a vanilla merge without -b
WAS producing a conflict. I will send a patch and explanation for this
in a separate email.

Cheers,
Raman