On Fri, May 21, 2010 at 04:58:02AM -0500, Ryan Schmidt wrote: > > On May 21, 2010, at 04:32, Gary . wrote: > > > We use a product which we > > customise and add features to, both of which mean changing the > > source. Sometimes these changes also get accepted by the vendor > > and are included in the next release. > > The Vendor Branches chapter in the book addresses how you can handle this in > Subversion. > > http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html > > If the source code is coming out of a Subversion repository on their > end, and you have at least read access to it, then it can be even > easier (you can just "svn merge" their latest changes from their > repository to yours). >
Also, Subversion 1.7 will have a 'patch' subcommand, which in addition to patching file content will automatically add new files and directories the patch creates and automatically remove files and directories left empty after patching. So in 1.7, you will be able to update a vendor branch like this: tar -zxf vendor-release-1.0.tar.gz tar -zxf vendor-release-2.0.tar.gz diff -urN vendor-release-1.0 vendor-release-2.0 > /tmp/vendor.patch svn co http://svn.example.com/repos/branches/vendor cd vendor svn patch /tmp/vendor.patch svn commit -m "update to 2.0" Stefan
