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.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3066464
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-10-17 02:27:59 CEST