Re: [RFC] Design of svnvendor.py

John Peacock wrote:

> 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,

I'm speaking of the **repository** path here.

>> 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

This does a new import of the vendor, so it's not answering my concern. The
problem I'm thinking of is the following:

1) svk import of libcomplex 1.1
2) svk cp: use 1.1 in my project
3) svk import of libcomplex 1.2
4) svk smerge: upgrade to 1.2 in my project

Now, how can I get back to version 1.1?

> 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.

There is a merge management facility: it's called svnmerge.py. My point is
that I simply don't need it because it's enough to issue a single "svn
merge" command with the correct URL. In the above case, I need something
like:

svk merge //project/vendor/libcomplex/1.2 //project/vendor/libcomplex/1.1 .

[this assumes you have already find out that you're using libcomplex 1.2.
Notice that there is no way to find out which version you are using, without
a manual inspection of the log]. After this command, I believe you cannot
use svk smerge anymore.

Now compare this with what I plan to do:

$ cd ./project-wc
$ svnimport.py ls
libcomplex
libfoo
libbar
$ svnimport.py ls -l
libcomplex: 1.1, 1.1b, 1.2
libfoo: 0.45
libbar: 2.4.8, 2.4.9, 2.4.12
$ svnimport.py copy libcomplex
Copying libcomplex into the current project (version: 1.2)
[...]
$ svn ci -m "Imported libcomplex 1.2"
$ svnimport.py info libcomplex
[...]
Version: 1.2
Available versions: 1.1, 1.1b, 1.2
$ svnimport upgrade libcomplex --version=1.1
Downgrading libcomplex to 1.2
[...]
$ svn ci -m "Downgraded libcomplex"
[...]
Version: 1.2
Available versions: 1.1, 1.1b, 1.2

See how there are absolutely no URLs, and all the information are being
provided in a way to totally hide the remote URLs. This is what I call a
user-friendly interface. When I think of a graphical tool for handling this
(like a boosted version of TortoiseSVN with svnvendor.py integrated), I
think I should see the copied libcomplex within the project with a different
color, telling me it's a vendor import; I would be able to right-click on
it, and select "upgrade"; this would pull up a menu with the list of
available versions, let me pick one and press OK; and that's it! no URLs
altogether!

So this script is not a mere "powerful convenient import ala svk import"
(even though this is one of the biggest concerns). And it's not about
"merge-tracking for vendor branches ala svk smerge" (I do that everyday with
svnmerge.py, and it works well for me). It's a fully hi-level, opaque layer
for vendor branch management.

Did you read it the design document through?

-- 
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org