On 1-Aug-05, at 12:43 PM, Martin J. Stumpf wrote:
> Scott Palmer wrote:
>> On 30-Jul-05, at 11:31 AM, David Summers wrote:
>>> On Sat, 30 Jul 2005, Ben Collins-Sussman wrote:
>>>> On Jul 29, 2005, at 3:35 PM, David Summers wrote:
>>> I.E., I originally did svn merge -r 1:99 URL_OF_TRUNK and
>>> committed that as r100 on the branch, then later I did svn merge
>>> -r 101:199 URL_OF_TRUNK.
>>
>> The merge command merges the changes that were made *starting
>> with* one revision to get to another revision.
>> In you example above, what changes were made to get from r100 to
>> r101? In your case it would be ok to skip the commit to trunk,
>> but you are also skipping that the next commit after it. It
>> probably isn't worth the effort to try to skip commits that
>> happen on an unrelated branch, since they won't be included in
>> the branch you are merging anyway.
>
> If what Scott says is true, which I believe it is, then why would
> Ben suggest the use of 100 to remove the errors? ie. overlapping
> the previous last rev with the current first rev. I have always
> skipped the commit rev on the branch just like David suggests. It
> seems so logical somehow. I am confused a bit now.
In this particular case he could start the second merge at r99 or
r100. The point is you have to start with the rev prior to r101 in
order to pick up the change that *made* r101. Ben suggests not
going back as far as r99 because 99 to 100 was the commit on the
branch,which doesn't matter in this case. You could include r99 as
the starting point for the second merge, since the change was not on
the trunk it wouldn't have any effect.
The first number (A) in the merge rA:B is the revision that you are
at, the second (B) is the revision you want to get to. in terms of
changes to merge.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 2 03:33:09 2005