Mark Phippard wrote:
> On 9/20/07, Peter Samuelson <peter@p12n.org> wrote:
>> [Mark Phippard]
>>> I think you are wrong on this. The ranges in svn:mergeinfo are the
>>> actual revisions that have been merged, not the range you would have
>>> used on svn merge.
>> My mistake. I assumed it was the other, based on your original example:
>>
>> $ svn mergeinfo .
>> Path:
>> Merge source: file:///Users/username/repositories/conflicts/trunk
>> Merged ranges: r0:4, r8:9, r12:16, r21:22
>> Eligible ranges: r4:8, r9:12, r16:21, r22:25
>>
>> The ranges in question seem to support my hypothesis: that the numbers
>> are _not_ inclusive on both sides, but only on one side. Or am I
>> interpreting that data wrong?
>
> That is because Mike chose to take the data from the mergeinfo
> property and "normalize" it into this format. Here is the property:
>
> $ svn pg svn:mergeinfo
> /trunk:1-4,9,13-16,22
Actually, I didn't make an explicit decision to that "normalization" -- the
mergeinfo parsing/unparsing utility functions do this for me. As you can
see with simple code inspection, I print what is given me in the
merge_range_t structure:
printf("r%ld:%ld%s", range->start, range->end,
(i == (ranges->nelts - 1)) ? "\n" : ", ");
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Thu Sep 20 15:29:13 2007