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