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

Re: Merging from External Files

From: Ted Stern <dodecatheon_at_gmail.com>
Date: Tue, 17 Mar 2009 14:48:41 -0700

On 17 Mar 2009 06:22:10 -0700, Felix Gilcher wrote:
>
> Hi James,
>
> if you can figure out the revision of your code theirs is based on
> you could branch your repository at that point, create a checkout,
> copy their code over it and check in. You'd have to manually
> add/remove files that they added /removed. Then you could use all
> merging capabilities of svn to pull up that branch to a current
> state and then merge from that branch back to your trunk. Depending
> on how much code change and how badly the areas of work overlap that
> might be anywhere between a no-brainer or a monster task.

Here's how you do that:

Treat this as a vendor branch and use svn_load_dirs.pl as described in TFM.

     svn mkdir $REPOS/project/branches/vendor

     # Make a vendor branch
     svn copy -r REV $REPOS/project/{trunk,branches/vendor/current}

     # tag the start of the branch
     svn copy $REPOS/project/branches/vendor/{current,start}

     # Import the new code into ^/branches/vendor/current.
     # Let's say that you have it checkout under a directory called
     # vendor-newstuff.

     svn_load_dirs.pl -t newstuff \
                      $REPOS/project/branches/vendor
                      current \
                      vendor-newstuff

svn_load_dirs.pl can be found in the Subversion source release.

The -t argument is the new tag.
Arg2 is the top directory of the vendor branch.
Arg3 is the vendor branch's trunk, which I call 'current' here.
Arg4 is the directory where you have extracted all the new stuff from
the vendor, including all directory changes and mods.

     # Get into a WC of the trunk:

     cd path/to/project-trunk-wc

     # Now merge the vendor's changes into your trunk:
     svn merge $REPOS/project/branches/vendor/{start,newstuff}

     # Resolve conflicts ....

     # then commit
     svn commit

And you're done. Hopefully there won't be too many conflicts. But I
will bet there are some :-(.

Ted
>
> cheers and good luck
> felix
>
> On Mar 17, 2009, at 12:18 PM, James Green wrote:
>
>> Hi All,
>>
>> I've just had a rather alarming conversation with my boss about a
>> particular scenario regarding our SVN repositories.
>>
>> Basically we have a third party organisation doing some outsourced
>> development on a project I am just in the process of wrapping up. I
>> have a direct link to my SVN repos and once code is written/tested/
>> approved I perform a commit and send the code to the repo. I'm just
>> about to complete this current phase of dev work and will then hand
>> over day to day dev to the outsourcer.
>>
>> I've just found out that they have already been working on an old
>> version of my code from 'a few months ago' also completely outside
>> of our source control SVN repos.
>>
>> Great ...
>>
>> How on earth am I going to deal with this scenario? Is there any
>> way to reliably merge these files with what is inside our SVN
>> server? Or is this just a completely lost cause?
>>
>> Yours,
>>
>> A rather worried developer from the UK, aka James :O|
>>
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1341043
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].

-- 
 Frango ut patefaciam -- I break so that I may reveal
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1343512
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-17 22:49:41 CET

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.