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
Received on 2010-05-21 12:09:57 CEST