question about the section on vendor branches

C. Michael Pilato cmpilato at
Fri Dec 3 11:33:17 CST 2010

Alvin, I've not been able to full process your question.  But you should
know that the Vendor Branches section of the book is one of its oldest and
least-maintained.  It could really stand to be completely rewritten, ideally
introducing new concepts such as the support for foreign repository merges.
 (And anything we can do to avoid a doc dependency on is a
good thing, as none of the book authors has ever even used that tool!)

On 11/04/2010 03:24 PM, Alvin Thompson wrote:
> I have a question about the example under the subsection labeled "General
> Vendor Branch Management Procedure".  Why do you need the "current" folder
> at all?  Why not just import each vendor release straight to the
> appropriate folder for that version (for example, straight to
> ^/vendor/libcomplex/1.0)?  When merging the new version with your project
> (in this case, the "calc" project), instead of using:
> svn merge ^/vendor/libcomplex/1.0 \
>           ^/vendor/libcomplex/current \
>           libcomplex
> You use:
> svn merge ^/vendor/libcomplex/1.0 \
>           ^/vendor/libcomplex/1.1 \
>           libcomplex
> As far as I can tell, this simplifies things greatly, since there's no
> need to merge the files for the new version of "libcomplex" into that
> "current" folder.
> * The "vendor" path can be treated like the "tags" path; no commits
>   ever need to be made to it.  The path only needs to allow imports.
> * There's one fewer revision, since you no longer need to commit the
>   changes to "current" and then copy them to "1.1".
> * There's no need to "svn add" any files new to "1.1".
> * You guarantee that the structure of the "1.1" folder corresponds
>   exactly to the "1.1" release (see below).
> * You don't have to worry about files that were present in "1.0" but
>   are no longer present in the "1.1".  With the procedure outlined
>   in the current example, those files linger.
> * There's no need at all for that "" script.
> What am I missing?
> Thanks,
> Alvin
> _______________________________________________
> svnbook-dev mailing list
> svnbook-dev at

C. Michael Pilato <cmpilato at> |

More information about the svnbook-dev mailing list