hello Mark, many thanks for your reply.
2009/4/22 Mark Phippard <markphip_at_gmail.com>:
> On Wed, Apr 22, 2009 at 3:50 PM, marc gonzalez-carnicer
> <carnicer.lists_at_gmail.com> wrote:
>
>> this was discussed long time ago, i've been looking for an answer
>> before posting.
>>
>> i need to do multiple non-sequential revisions merge (cherrypicking),
>> from a "new feature" branch to the trunk. the "new feature" branch has
>> been updated with revisions from the trunk several times.
>>
>> when the "new feature" has been finished and tested it's time to bring
>> over. for that, i need to perform the above mentioned cherrypicking,
>> which consists on a merge of multiple non-sequential revisions.
>>
>> for reference, i am using svn 1.5.1 on the client and svn 1.3.2 on the
>> server side. i am not using mergeinfo, i can't yet.
>>
>> the syntax for that appears to be obvious, since examples of it
>> neither appear on the svnbook nor on the built-in help. finally, i end
>> up with a command like that :
>>
>>
>> $ svn merge \
>> -r 2471:2473 -r 2477:2479 -r 2484:2485 -r 2486:2491 \
>> -r 2492:2493 -r 2494:2496 -r 2505:2506 -r 2578:2586 \
>> -r 2596:2600 -r 2607:2610 -r 2611:2612 -r 2621:2624 \
>> -r 2626:2630 -r 2667:2668 \
>> svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
>>
>> this variant seems to be possible too
>>
>> $ svn merge -c 2472,2473,2478,2479,2495,2487,2488,2489,2490,2491 \
>> svn://srv-peat-svn/home/svn/8568/branches/code.Lane.LNT .
>>
>>
>> to my surprise, neither command does NOT perform a unique merge
>> operation, and instead, as many merges as revision ranges specified.
>> this causes that if a file has been modified in more that one revision
>> group, it is merged more than once. if there are conflicts, the
>> situation becomes scary, and the WC a mess.
>>
>> i was expecting svn merge to behave as the good old svnmerge.py
>> script, now forgotten by many.
>>
>> am i doing something wrong or is it that svn merge can't perform these
>> multiple revision merge in just one try? if it is the latter case, i'd
>> appreciate confirmation about it.
> It does one merge for each revision range specified.
thanks for confirming it.
>This is also how
> svnmerge.py did it. After all, it used the svn command line to
> perform the merges so it cannot do anything the command like cannot.
i see. if i had that feeling it's probably because i may have not had
conflicts when i used svnmerge.py.
anyhow, i don't understand why svn merge, when invoked with multiple
revision ranges performs a merge for each range. is this an
intentional feature, or a design overlook? i really can't think of a
case when this would be useful. when a merge includes a *single*
revision range, only 1 merge is performed, even if the range contains
hundreds of revisions. to me, a multiple revision range is
conceptually *exactly* the same : a single merge operation.
i would expect a multiple revision range merge to internally produce a
diff-patch of all the specified revision ranges, and then merge it
with the WC (the target). some revision ranges may cancel some others,
and that would probably reduce the number of conflicts, if there are
any.
i can provide the log and results of my real-world example in order to
support my point of view :)
PS : i do hope my email does not sound harsh. my apologies in that
case. i can only be grateful towards subversion developers.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1891305
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-24 14:17:57 CEST