Re: [RFC] Design of svnvendor.py

Giovanni Bajo wrote:
>> http://svk.elixus.org/?SVKTutorial
>>
>> See the section labeled "Painless import".
>
> Interesting. But I don't use SVK (I tried to, and find it too slow and too
> badly documented) and I don't see a way to use SVK just to manage vendor
> branches.

An SVK repository is merely an SVN repository in a hidden directory. I
regularly expose my SVK repositories as svn:// or http:// for
distribution purposes (i.e. I develop in SVK, but I checkout on the
production servers using SVN). I'm not trying to force you to use SVK,
but suggesting that if it has been a while since you tried it, you
should try it again (the code has been refactored for performance and
the documentation is much improved). It is actually trivial to use SVK
only for managing vendor branches with little or no user input involved.

> Moreover, it doesn't hide from the user the full paths of the vendor
> imports, nor it does allow to downgrade a copied vendor package (which is
> also the reason why I don't plan on using svnmerge.py, which provides the
> equivalent of "svk smerge").

   $ export VENDER="/long/path/to/the/vendor/current"
   $ svk import -m "new 1.2 release" //project/$VENDER ./libcomplex-1.2

You are ignoring the fact that "downgrading" a vendor package is a
reverse merge with *any* scheme. Without a merge management facility,
you are better off using svn:externals instead and just squirrel the
vendor code inside your filespace.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org