Re: Vendor branches: Current guidance?

On Thu, 22 May 2014 20:08:15 +0000, David DL 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. 
>
>
> Is that correct? 

Yes. When you remove all the files and add them anew, svn will think
they are different files, and any attempt to merge that onto your own
modification will end in tears.

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

You need to use some kind of tool to perform the file-wise
add/remove/modifiy commits. Core svn doesn't provide such, it's somewhere
in the contrib area. (It's not that hard to implement yourself, either.)

But the best tool I know for that is actually git-svn. Because, if the
vendor renames files in his tree, with the usual tools the rename will
not be recorded as such in the vendor branch. git-svn applies its rename
detection, and will handle that part better.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800