I have found out the reason for this.
It's not a bug, it was not even a problem in a first place.
I just might happen (if some corrections are already in the branch) that one-by-one merge will do the job as expected, while range merge will fail (as it suppose to fail by definition).
Simple test case is:
- Have an initial version of trunk with a file
- create a branch out of this initial version
- make a change to trunk/file and commit
- make another change trunk/file (on the same line) and commit
- merge only first change from trunk to the branch
- try to merge both changes from trunk to branch (this is range merge and will fail because of conflict, first change was already in branch, the diff does not fit to the branch)
(this is expected)
- now revert conflicted file and try to merge it one-by-one
- first merge will be scilently accepted (changes are already in the branch)
- second merge will succeed, because the diff now fits to the branch
(therefore one-by-one merge will succeed)
(this is also expected)
This is what happened to me on a large project and was not obvious at first.
Zoran
> -----Original Message-----
> From: Karl Fogel [mailto:kfogel@red-bean.com]
> Sent: Thursday, May 10, 2007 12:02 AM
> To: Bosnjak Zoran
> Cc: users@subversion.tigris.org
> Subject: Re: merge range of revisions or one by one
>
> "Bosnjak Zoran" <Bosnjak@iskratel.si> writes:
> > what you are saying makes sense, but my observation is the oposite.
> > I get conflict in range merge while one-by-one merge is fine.
> > Do you have any explanation for this situation?
>
> Not off the top of my head, but if you can make the repository and
> actually test cases publicly available, we could probaby figure this
> out quickly...
>
> -Karl
>
> --
> Subversion support & consulting <>
> http://producingoss.com/consulting.html
>
> >> -----Original Message-----
> >> From: Karl Fogel [mailto:kfogel@red-bean.com]
> >> Sent: Wednesday, May 09, 2007 7:58 AM
> >> To: Bosnjak Zoran
> >> Cc: users@subversion.tigris.org
> >> Subject: Re: merge range of revisions or one by one
> >>
> >> "Bosnjak Zoran" <Bosnjak@iskratel.si> writes:
> >> > Should I get the same result if I merge:
> >> >
> >> > - a set of revisions from branch X to my working copy, like this:
> >> > $cd working_copy
> >> > $svn merge -r rev1:rev2 url_of_X
> >> >
> >> > - or the same set of revisions, but one at the time in sequence, like
> >> this:
> >> > $cd working_copy
> >> > $<for each rev from rev1:rev2 do>
> >> > $ svn merge -r (rev-1):rev url_of_X
> >> > (rev1 is 'from revision', so it's not included in a loop)
> >> >
> >> > I have 96 revisions to merge.
> >> > In the first approach I end up with one conflicted file.
> >> > But in the second approach I get no conflicts.
> >> > The reset of the branch is merged correctly.
> >> > (observed on svn 1.4.3)
> >> >
> >> > Where is the trick?
> >>
> >> You can get different results, because later changes can cancel out
> >> (undo) earlier ones. For example, say r22 is a reversion of r21, and
> >> r21 conflicts with something in the working copy you're merging into.
> >> If you do the one-by-one merge, you'll encounter the conflict, but if
> >> you do the range merge (which just merges in the diff between the
> >> endpoints), you won't get the conflict.
> >>
> >> -Karl
> >>
> >> --
> >> Subversion support & consulting <>
> >> http://producingoss.com/consulting.html
Received on Thu May 10 17:20:28 2007