tags:

views:

761

answers:

4

We have a project where a vendor produces some custom code for us and we produce the backend content. Every time they ship us a new version, we manually merge that whole folder structure into our repository. This is easy for added and modified files (just copy/paste), but I have to create a batch script to delete all the files/folders that were removed (I use a diff tool to get a list of the deleted files, then make a batch file from that).

Our SVN repo looks like this:

OurProject\
--OurBackendCode\
--VendorCode\

I know I could first delete all the files in the vendor directory in our repo, then add in the new version. That would be easy but leave unwanted "deleted" and "added" entries to the SVN log (the whole reason we're keeping a copy of their code in our SVN is so we can have easy access to the log for troubleshooting).

Is there an easier way to merge these deleted files into my repo?

EDIT: Tim rightly points out that if we just allowed the vendor access to our SVN repo, they could make their changes on a branch. Unfortunately, that's not my call; I'm just a developer. Plus I doubt we'd trust them (I don't know anything about SVN security).

2nd EDIT: We ended up just deleting the existing vendor branch and just adding in the new vendor code. But I brought up the idea of giving the vendor access to our SVN and it's floating upward with some promise :)

+3  A: 

Why don't you allow them access to your SVN repo - perhaps a branch and then you merge into yours?

It is simple to allow them only access to the parts they need. I really do think this is the best solution for you and them.

Tim
That's not my call; I'm just a developer. Odds are we don't trust them. That would certainly be the easiest option.
Ed Schwehm
It is ok if you don;'t trust them... They are already giving you the code, you can give them just their own branch and then you merge into your trunk...
Tim
Easy == good. You can always undo what they have and you control the users who access it. It's not like you are giving them the keys to the store - they already write the code. It makes life easier for everyone.
Tim
You're right, but I don't have the authority to make that decision here. Plus I'm trying to get this done today. I'm definitely going to bring this up though.
Ed Schwehm
+2  A: 

Would be so much easier if you could give them SVN access to the folders they need, and let them manage it. :-)

Doh, Tim hit Post before I did!

The only way to streamline what your doing is scripting the entire process of running the diff, getting the deleted/removed files, and feeding that into the svn -delete. Then at least you would have 1 command to run with a source and target folder.

Ideally you want to just give the remote developers access to SVN, like Tim said, give them a branch if you can't lock down folders, but you'll still end up running merges then (with a branch).

Adam
+1 for you. Nice answer
Tim
+1  A: 

It sounds to me like what you want here are Vendor Branches where each successive import of the vendor code gets a new version.

This way, there are no deletes to manage, and you can use Subversion to diff version 1.0 from 2.0 etc.

feoh
Just wanted to point out also, if you read the Vendor Branches chapter in the SVN book, you'll learn about 'svn_load_dirs.pl' which does EXACTLY what Adam proposes in his answer (accepts a new code tree and helps find the deletes, renames and moves so you can easily update the vendor branch in your tree).
Mark Renouf
A: 

One answer that was proposed by a coworker was to create a temporary branch for the new code drop, then do a SVN merge from that branch to the real branch (and delete the temporary one afterwards).

Ed Schwehm