Re: Vendor branches: Current guidance?

Hi,

> On 23 May 2014, at 01:08, David DL <ddl877_at_outlook.com> wrote:
>
> It's my understanding that if you want the process to integrate a new vendor drop to be sane, the update ideally should be expressed as a series of "svn actions" (add/update/etc.) so that history is maintained.
>
> The obvious option of just doing a delete/add on the whole folder will mess stuff up.

Yes, you need a diff between upstream releases. In a clean svn 1.7 or later working copy, delete (not svn delete) all elements except .svn, then drop in the next upstream release files. Examine differences and add/remove files as required.
Alternatively, apply the diff between two releases. You can source that from simply diffing two releases, or from the upstream svn. (-p)

> If you don't use the client side tools, how can you maintain in-house changes against a series of vendor drops?

By following the procedure: clean drops in /vendor/foo/current, tag releases to /vendor/foo/N (1,2,3...). The diff between them can be merged.
Copy current to trunk once. Your own modifications go there only.
For a merge the difference between N-1 and N into that, thus maintaining in-house changes and bringing them together with releases.

> Or, in your case, do you not need to maintain in-house changes?

I do, with changes sent in the other direction and then contained in the exact or similar form with the drops.

> Alternately, do the client scripts just not work anyway?

Haven't found the need to use them at all.

Andreas
Received on 2014-05-23 09:27:44 CEST