Yes, that makes perfect sense now! But I seem to have run into another
problem. I have the same use case as in my original post
Trunk has foo with 1 line
User 1 makes a branch off the trunk, makes changes in foo, merges from trunk
and commits to branch
User 2 makes a branch off the trunk, makes changes in foo, merges from trunk
and commits to branch
Now, its time to reintegrate.But instead, I create another branch off the
trunk and call it 'merge-branch'
I update the branches folder and get this new branch with the original file
foo.
and now run
svn merge --reintegrate URL-to-Branch1 .
I get an error:
svn: File not found: revision 5, path '/branches/merge-branch'
Revision 5 was when user 1 made a change in the foo file and committed to
his branch.
Why did this happen? Doesn't --reintegrate compare two URL trees ( and
merge-branch cming from the trunk should make no difference right?)? Am I
missing something here?
Mark Phippard-3 wrote:
>
> On Mon, Aug 18, 2008 at 11:51 PM, Rohan Joseph <rohanjoseph_at_gmail.com>
> wrote:
>> Thanks! My understanding of using --reintegrate is that it is used so
>> as to avoid merging in changes on a branch, that came from the trunk,
>> back to the trunk.
>>
>> Let's say that a user branches off the trunk, does some development and
>> then
>>
>> 1. Syncs up with the trunk by merging from the trunk to the branch.
>> Makes sure everything works and commits* the change to his branch.
>>
>> Now while syncing back to the trunk, he should use the --reintegrate
>> switch. But if he instead, checked out the trunk, and blocked the last
>> commit on the branch out by doing this
>>
>> svn merge -r N-1:N --record-only URL-TO-BRANCH
>>
>> where N is the revision number in which he committed the changes from
>> step (1) [corresponds to * in step 1].
>>
>> Then instead of using the --reintegrate switch, he or she simply runs
>> the merge command. Wouldn't it do the right thing and avoid a cyclical
>> merge scenario? Or am I missing something here?
>
> That would only work if completely ignoring the revision is the right
> thing to do. For example, that commit may have also included conflict
> resolution and you would be losing all of that work if you used that
> approach.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
>
--
View this message in context: http://www.nabble.com/First-time-use-of-merge-reintegrate-tp19035647p19077189.html
Sent from the Subversion Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-08-20 22:15:14 CEST