[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge between a legitimate branch and an alien one

From: Ryan Schmidt <subversion-2006d_at_ryandesign.com>
Date: 2006-12-16 01:03:27 CET

On Dec 14, 2006, at 16:47, garbage wrote:

> I didn't find a very good wording for the merge I'd like to do. So
> let me explain my problem.
> I have a SVN repository with a trunk and some c++ projects inside.
> I've created a branch, called myOwnBranch, with let say revision 1000.
>
> But before I had SVN, one of my friend got a copy of my projects
> and started working on them and making changes.
> On my side I discovered SVN and started to use it. Nearly at the
> same time my friend discovered also SVN and started to use it.
>
> Now we'd like to merge our version and let say add all my changes
> to my friend new code.
>
> So I created an empty branch, called buddyBranch, (rev 1001) on my
> repository and imported my friend latest code inside (rev 1002).
> My working copy is then this buddyBranch and I want to do a svn
> merge of all my change from rev 1 to 999 from myOwnBranch and apply
> them to my working copy.
> When I do that SVN treats all changes as conflicts which in that
> case is far for an automatic merge.
> The problem I see is that the buddyBranch doesn't have any svn
> shared history with myOwnBranch and so when merging SVN can't
> decide which version is newer than the other.
> Maybe I am of the hook here. But I don't what to do to solve that
> problem
>
> So my question is : does SVN can handle such particular merge ? if
> yes what are the steps I should follow ?

There is an --ignore-ancestry option to svn merge which may be
helpful, though I'm not sure as I've never used it. You may want to
see what the book has to say about it. http://svnbook.org

The best option would have been to have both branches have a common
ancestry. This would not have been hard to do. Everything needs to be
in one repository, if that's not already clear. One of you will have
to abandon your history [1] and merge it into the remaining
repository. Let's assume that you will keep your history and your
friend will give up his and merge his code into your repository.

You hopefully have a version of the code before your two versions
diverged, before the two of you started making different edits.
Hopefully this is in your repository. Let's call it revision 100.
Hopefully this is in a directory called "trunk". You've made various
changes, let's say up through trunk revision 200.

To add your friend's code, do this: create a branch from revision 100
of the trunk, and call it buddyBranch if you like.

svn cp -r 100 $REPO/trunk $REPO/buddyBranch -m "Making buddy branch
from r100 of trunk"

Now get an export of your buddy's current code. Use svn_load_dirs.pl
[2] to load it into the buddy branch. Now you have your code in
trunk, and his code in the buddy branch, and they're both based on
r100 of trunk. Now you can merge the buddy branch into the trunk as
per usual, and get rid of the buddy branch, and from then on both of
you will use the trunk. Or create feature branches. Or whatever.

[1] Ok, so it's not strictly necessary that the history be thrown
away: you could manually redo each of your friend's edits in your
repository to retain history. Or you could use svn_load_dirs.pl [2]
to help automate it. You'd get an export of his repository at each of
his revisions, and load those in to his branch.

[2] This script is described in the vendor branch section of the
book, and is available in the contrib directory of the Subversion
source distribution.

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 16 01:04:02 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.