Hi, > On 23 May 2014, at 01:08, David DL <ddl...@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
