Reputation: 2171
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 :)
Upvotes: 2
Views: 2657
Reputation: 11
Create a verdor repo (seperate from your development repo), and ask vendor to dump the revisions since the previous version delivered to you. On your site you can simply load it back to the vendor's repo. Easy and simple.
Upvotes: 1
Reputation: 2171
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).
Upvotes: 0
Reputation: 1383
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.
Upvotes: 2
Reputation: 7900
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).
Upvotes: 2
Reputation: 20360
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.
Upvotes: 2