Problems merging two branches - Subversion 1.3

[Jonatan Soto <se...@gmail.com>]

Hi all,

We are facing some problems during a merge process from a branch to trunk (2
URL merge). Note that we didn't synch the branch with the trunk at any time.

We want apply all changes made in that branch back to the trunk but for some
reason the results that are we getting are very odd. Lots of files are not
merged nor added and for some strange reason all conflicts are tree
conflicts.

The command we are using is something like this: svn merge
branch@HEADtrunk@HEADWorkingCopyWhereTrunkWasCheckedOut

We know that the --reintegrate option is only available since version 1.5
and perhaps it's the right thing to do, but we cannot upgrade subversion,
it's out of our scope and impossible to accomplish.

May you help us please? Any help would be much appreciated.

Thanks in advance.

-- 
-----

Jonatan Soto

Re: Problems merging two branches - Subversion 1.3

[Mike Dixon <mi...@denovosoftware.com>]

On 4/27/2011 12:20 AM, Jonatan Soto wrote:
> Sorry if we were mistaken, but when the merge finishes (following
> Ryan's indications) it says:
>
> Summary of conflicts: Text conflicts: 15 Tree conflicts: 8
>
> Perhaps the problem is that we are using the latest subclipse plugin
> as a client and if we are not wrong it is based on 1.6 client.

Ah, yes, that'd be it. So in that case you (the user) are actually using
1.6, not 1.3, and you should be able to use the --reintegrate option
when merging.

> We've downloaded a 1.4 client but when we use it, says that the
> version is not correct. We assume that it is caused because the
> working copy was previously checked out using subclipse. The
> subversion server is 1.3 for sure, it is shown at the bottom of the
> page when we are browsing it through a web browser.

Yeah, generally speaking all of your subversion-based client-side tools
need to be built using the same version of subversion, or else you run
into problems like this. I don't use subclipse myself, but there should
be a way to find out the exact svn version it's built from.

> On the other hand, I totally agree with you, we should upgrade the
> svn server version but we are working for a big company and as you
> can figure it out, the infra team would not be agree with us if we
> tell them to upgrade. Many projects are under this repository and it
> won't be easier to tell them that (lot's of bureaucracy).

Out of curiosity, have you actually asked? Subversion is designed with
the idea that any 1.x client should be able to work with any 1.x server
(as you've demonstrated by using a 1.6 client against a 1.3 server). The
infra team should be able to upgrade to the latest 1.6 server and none
of the project teams need to care. It doesn't really matter for the
problem at hand, but there are a lot of performance benefits that might
make the infra team happy, like reduced storage space on the server.

-Mike

Re: Problems merging two branches - Subversion 1.3

[Jonatan Soto <se...@gmail.com>]

Hi Mike,

Sorry if we were mistaken, but when the merge finishes (following Ryan's
indications) it says:

Summary of conflicts:
  Text conflicts: 15
  Tree conflicts: 8

Perhaps the problem is that we are using the latest subclipse plugin as a
client and if we are not wrong it is based on 1.6 client. We've downloaded a
1.4 client but when we use it, says that the version is not correct. We
assume that it is caused because the working copy was previously checked out
using subclipse.
The subversion server is 1.3 for sure, it is shown at the bottom of the page
when we are browsing it through a web browser.

On the other hand, I totally agree with you, we should upgrade the svn
server version but we are working for a big company and as you can figure it
out, the infra team would not be agree with us if we tell them to upgrade.
Many projects are under this repository and it won't be easier to tell them
that (lot's of bureaucracy).

Anyway, thanks a lot for your support!


On Tue, Apr 26, 2011 at 7:26 PM, Mike Dixon <
michael.dixon@denovosoftware.com> wrote:

> On 4/26/2011 9:47 AM, Jonatan Soto wrote:
>
>> Subversion 1.3
>> tree conflicts.
>>
>
> Wait, what? Tree conflicts weren't introduced until svn 1.6. Something
> strange is going on here if you think you're using 1.3 but you're getting
> reports of tree conflicts.
>
> (And yes, as you suspected the real solution is probably to upgrade to at
> least 1.5, and 1.6 is pretty stable at this point too. With such an old
> version, you're going to have a hard time finding anyone with much insight
> into your problem.)
>
> -Mike
>



-- 
-----

Jonatan Soto

Re: Problems merging two branches - Subversion 1.3

[Mike Dixon <mi...@denovosoftware.com>]

On 4/26/2011 9:47 AM, Jonatan Soto wrote:
> Subversion 1.3
> tree conflicts.

Wait, what? Tree conflicts weren't introduced until svn 1.6. Something 
strange is going on here if you think you're using 1.3 but you're 
getting reports of tree conflicts.

(And yes, as you suspected the real solution is probably to upgrade to 
at least 1.5, and 1.6 is pretty stable at this point too. With such an 
old version, you're going to have a hard time finding anyone with much 
insight into your problem.)

-Mike

Re: Problems merging two branches - Subversion 1.3

[Jonatan Soto <se...@gmail.com>]

Thanks a lot for you useful responses!


On Tue, Apr 26, 2011 at 7:24 PM, Ryan Schmidt <
subversion-2011a@ryandesign.com> wrote:

>
> On Apr 26, 2011, at 11:47, Jonatan Soto wrote:
>
> > We are facing some problems during a merge process from a branch to trunk
> (2 URL merge). Note that we didn't synch the branch with the trunk at any
> time.
> > We want apply all changes made in that branch back to the trunk but for
> some reason the results that are we getting are very odd. Lots of files are
> not merged nor added and for some strange reason all conflicts are tree
> conflicts.
> >
> > The command we are using is something like this: svn merge branch@HEADtrunk@HEADWorkingCopyWhereTrunkWasCheckedOut
>
> Before Subversion 1.5, it did not track merges for you; you must track
> merges yourself.
>
> First, I assume where you write "branch" and "trunk" you actually mean the
> complete URL to the branch and the trunk, such as
> http://www.example.com/svn/branches/mybranch and
> http://www.example.com/svn/trunk.
>

Sorry for not be clear. We meant that you pointed.


>
> This merge is not correct. You've asked Subversion to compute the steps
> necessary to convert the head of the branch into the head of the trunk, and
> to apply those steps to a working copy of trunk. This doesn't make sense and
> is not the right thing to ask Subversion to do.
>

Yeah, that is what we did wrong. We follow your advices and it works as
expected. After lots of documentation reads we did not understand correctly
properly this part but you make this clear to us. Thanks a lot again.


>
> Instead, you need to ask Subversion to compute the steps to convert the
> branch as it was when you created it, into the branch as it is now, and
> apply those steps to the trunk working copy. The command to do that is:
>
> svn merge -rA:B http://www.example.com/svn/branches/mybranchworkingcopyoftrunk
>
> "A" should be the revision when this branch was created. You can use the
> following command to determine this revision:
>
> svn log --limit 1 -r 1:HEAD --stop-on-copy
> http://www.example.com/svn/branches/mybranch
>
> "B" should be the current head revision, or the last changed revision of
> the branch, as you wish.
>
> You'll then have to resolve conflicts in the working copy, if there are
> any.
>
> When you commit this working copy, your commit message should state what
> range of revisions you just merged, so that if you need to merge again
> later, you'll know what revisions to include -- don't merge the same
> revisions twice. This means if you do merge a second time, "A" won't be the
> revision when the branch was created, but will be the revision after the
> last one that was already merged.
>
>
We will proceed as you marked on future merges.



>
> > We know that the --reintegrate option is only available since version 1.5
> and perhaps it's the right thing to do, but we cannot upgrade subversion,
> it's out of our scope and impossible to accomplish.
>
> Understand that the current version of Subversion (1.6.x) and the preceding
> one (1.5.x) are supported; earlier versions are not.
>
>
> http://subversion.apache.org/docs/release-notes/1.6.html#svn-1.4-deprecation
>
>
>
>


-- 
-----

Jonatan Soto

Re: Problems merging two branches - Subversion 1.3

[Ryan Schmidt <su...@ryandesign.com>]

On Apr 26, 2011, at 11:47, Jonatan Soto wrote:

> We are facing some problems during a merge process from a branch to trunk (2 URL merge). Note that we didn't synch the branch with the trunk at any time. 
> We want apply all changes made in that branch back to the trunk but for some reason the results that are we getting are very odd. Lots of files are not merged nor added and for some strange reason all conflicts are tree conflicts.
> 
> The command we are using is something like this: svn merge branch@HEAD trunk@HEAD WorkingCopyWhereTrunkWasCheckedOut

Before Subversion 1.5, it did not track merges for you; you must track merges yourself.

First, I assume where you write "branch" and "trunk" you actually mean the complete URL to the branch and the trunk, such as http://www.example.com/svn/branches/mybranch and http://www.example.com/svn/trunk.

This merge is not correct. You've asked Subversion to compute the steps necessary to convert the head of the branch into the head of the trunk, and to apply those steps to a working copy of trunk. This doesn't make sense and is not the right thing to ask Subversion to do.

Instead, you need to ask Subversion to compute the steps to convert the branch as it was when you created it, into the branch as it is now, and apply those steps to the trunk working copy. The command to do that is:

svn merge -rA:B http://www.example.com/svn/branches/mybranch workingcopyoftrunk

"A" should be the revision when this branch was created. You can use the following command to determine this revision:

svn log --limit 1 -r 1:HEAD --stop-on-copy http://www.example.com/svn/branches/mybranch

"B" should be the current head revision, or the last changed revision of the branch, as you wish.

You'll then have to resolve conflicts in the working copy, if there are any.

When you commit this working copy, your commit message should state what range of revisions you just merged, so that if you need to merge again later, you'll know what revisions to include -- don't merge the same revisions twice. This means if you do merge a second time, "A" won't be the revision when the branch was created, but will be the revision after the last one that was already merged.


> We know that the --reintegrate option is only available since version 1.5 and perhaps it's the right thing to do, but we cannot upgrade subversion, it's out of our scope and impossible to accomplish.

Understand that the current version of Subversion (1.6.x) and the preceding one (1.5.x) are supported; earlier versions are not.

http://subversion.apache.org/docs/release-notes/1.6.html#svn-1.4-deprecation