[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Vendor Branch Here

From: Ben Fritz <fritzophrenic_at_gmail.com>
Date: Wed, 16 Oct 2013 19:27:32 -0500

On Wed, Oct 16, 2013 at 6:00 PM, Gavin Lambert <tsvn_at_mirality.co.nz> wrote:
> On 17/10/2013 06:13, Quoth Stefan K√ľng:
>>> Presumably it does not preserve local edits either (as I can't see how
>>> it could without having a reference unmodified copy of the previous
>>> vendor drop). Isn't this the most important feature of vendor branches?
>> It's for vendor branches, which should not have local modifications.
>> IMHO if you have to change/modify an external lib, create a patch from
>> your changes and have that patch somewhere versioned as well. Then after
>> upgrading the lib (using the vendor branch command) you can apply the
>> patch again to that new version.
> I'm referring to
> http://svnbook.red-bean.com/en/1.7/svn.advanced.vendorbr.html, which
> discusses the concept of "vendor branching" as it relates to Subversion.
> It is pretty much entirely about tracking and preserving custom local
> changes made to code supplied by external vendors. So this is what
> people will be expecting when they see something associated with SVN
> talking about vendor branching.
> I'm not saying that this feature is a bad feature (in fact it's a very
> useful one, in the absence of local changes), just that it has a bad
> name -- it's going to make people jump to the wrong conclusions about
> its functionality.
> Maybe you should call it "reimport here" rather than "vendorbranch
> here"? (And clarify that the containing folder needs to be dropped, not
> the contents.)

If you're blowing away your changes, then you're doing vendor branches
wrong. That page you linked to says:

> you create a top-level directory (such as /vendor) to hold the vendor
> branches. Then you import the third-party code into a subdirectory of
> that top-level directory. You then copy that subdirectory into your
> main development branch (e.g., /trunk) at the appropriate location.
> You always make your local changes in the main development branch.
> With each new release of the code you are tracking, you bring it into
> the vendor branch and merge the changes into /trunk

Thus, you should use "vendor branch here" on the directory called
/vendor. You should never manually modify files in this directory.

You should have a separate copy of the files within /vendor, somewhere
under /trunk. This copy is what you should be modifying.

This way, after you commit the changes you received to /vendor, you will
then use an svn merge command to pull those changes over into wherever
you are maintaining your customizations. In this way, you always have a
pristine copy of the actual vendor code, and you always have the ability
to merge in vendor updates using SVN's merge machinery so that you don't
lose your local changes.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-10-17 02:27:59 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.