[Svnmerge] Difference between avail and merge header/body revision lists

[Mark Kempster]

After a quick look at the script (as an aside, I continue to marvel at the utility of open source 
projects, and how helpful it can be to review the code), I _think_ I'm coming to a better
understanding of phantom revisions. It looks like those are revisions that landed in other branches
that can be considered for merging since they'll be a no-op, and it'll be faster to ask svn to do
fewer larger merges, as opposed to more smaller merges. So, 'svnmerge merge' will always report on
both 'real' and 'phantom' revisions, but nothing merge-wise will happen wrt. the phantom revisions.

I'm no python coder, so if I've misread something, please correct me!

I think I'll play the moderately-paranoid card, and block all of the svnmerge property changes made
in /branches/0.2, then go for the proverbial brass ring and give it a shot. Then go back and clean up
the 0.1 revision list, and it'll all be groovy!

Raman - thanks again for your help.
Devs - thanks for having decent comments in the code.

Cheers
- Mark

On Wed, 04 Apr 2007 18:26:12 -0400, Raman Gupta <rocketraman at fastmail.fm> wrote:
> Mark Kempster wrote:
>> Hi there. Short time lurker, first time poster.
>
> Welcome.
>
>> This is what's listed in svnmerge-commit-message.txt Header line:
>> Merged revisions
>>
> 2202-2207,2210,2223-2224,2233-2237,2242,2246,2260-2261,2263-2264,2267-2274
>>  Details list 2270, 2271, 2272, 2273
>>
>> I really only want the revisions listed in the Details section of
>> the commit message. Why the difference between the summary line and
>> the details section?
>>
>> The change to property svnmerge-integrated reflects the longer list
>> of properties, not the shorter one.
>
> The code that creates the merged revision list for the commit log
> message includes "phantom" revisions, as well as the available
> revisions. These revisions are ones that are unrelated to the source
> branch and therefore can be considered effectively "merged" as far as
> svnmerge.py is concerned. Normally, this makes the merge range look
> nice and simple.
>
> Now in your case, revisions 2208, 2209, 2211, etc. are breaking the
> range. These revs are not merge candidates, nor are they phantom
> revisions. If you re-run the merge with a -v parameter, the output
> might tell you what svnmerge.py thinks of those revs.
>
>> One interesting change is to r2233, which was a 'svnmerge block'
>> command for some prior revisions, which should have just been a
>> property change on /trunk. r2210 was a checkin to /trunk. Why would
>> those be listed when I'm trying to pull from /branches/0.2?
>>
>> I'm guessing that I mucked something up during init, but I'm not
>> sure what.
>
> I don't think so, unless the gave -r the wrong values. Was the actual
> merge incorrect, or just the commit log message?
>
> Cheers,
> Raman Gupta
>
> _______________________________________________
> Svnmerge mailing list
> Svnmerge at orcaware.com
> http://www.orcaware.com/mailman/listinfo/svnmerge