You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Giovanni Bajo <ra...@develer.com> on 2006/05/19 13:35:05 UTC
[RFC] Design of svnvendor.py
Hello,
I find inconvenient the way vendor branches "work" under SVN. The book
describes quite a few operations that need to be manually done, and some of
them are really annoying:
"""
To perform this upgrade, we checkout a copy of our vendor branch, and
replace the code in the current directory with the new libcomplex 1.1 source
code. We quite literally copy new files on top of existing files, perhaps
exploding the libcomplex 1.1 release tarball atop our existing files and
directories. The goal here is to make our current directory contain only the
libcomplex 1.1 code, and to ensure that all that code is under version
control. Oh, and we want to do this with as little version control history
disturbance as possible.
"""
This is complex to do, and a careful operation. It's quite easy to get
something wrong. I plan on writing a Python script (svnvendor.py) to
automate this process. This is the design document for this script,
I'll await any comments!
***************
ABSTRACT DESIGN
***************
Terminology
-----------
- "Package" or "vendor package": a third-party set of files (usually a
library), which we want to import and version within a SVN repository.
- "Project": a tree of files being developed within the SVN repository,
which might want to make use of a local copy of vendor packages.
- "Import a package": the act of adding the third-party package to the SVN
repository.
- "Copy of a package": a local versioned copy of an imported project within
a project.
Requirements
------------
This program is trying to make very easy to do the following things:
- Import a 3rd-party package within a SVN repository (maybe even starting
from the .tar.gz distribution).
- Update an already imported 3rd-party package with a new version, in a way
that adds to the repository only the deltas of changes with respect to
the previous version (that is, committed over the previous one).
- Copy an imported package within a project (versioned copy)
- Upgrade/downgrade the copy of the imported package within a project,
*keeping* all the local modifications (commits in the copy of the
imported package).
- Implicit access to vendor packages by the means of their name (without
having to specify the full URL pointing to the imported version of the
package).
Implicit URLs
-------------
Personally, I'm fed up with typing all those long URLs on the command line,
and I would like the script to optionally "do the right thing" with
understanding the layout of a repository.
I understand that there is some genericity in SVN proper that needs to be
preserved, but I'd rather this kind of external tools to make things easier
for people using standard layouts of repository (like 99% of them are
doing).
Thus, for instance, I'll try my best to make so users can type
"svnvendor.py use libcomplex --version=1.1", and the script will
automatically know where is the vendor branch for the current
project/repository and go finding libcomplex in there.
Vendor URL
----------
There are two main layouts I want to be able to support:
1) vendor branches are stored within a directory called "vendor" or
"thirdparty" within the project root (at the same level of "trunk",
"branches", "tags"). Example:
project_A/
trunk/
branches/
tags/
vendor/
project_B/
trunk/
branches/
tags/
vendor/
2) vendor branches are stored in a global directory
(/vendor or /thirdparty) so to be shared among all projects in the same
repository.
vendor/
libcomplex/
libfoobar/
project_A/
trunk/
branches/
tags/
project_B/
trunk/
branches/
tags/
For each given project/repository, I'll thus assume that there is one
directory in which all the vendor packages are imported. This directory is
called the "vendor URL". Within the vendor URL, there is one directory for
each imported package (named after the official name of the package).
Within each package directory, there is one main directory called
"current", into which all the versions of a given product are effectively
committed. Then, there is one tag for each imported version (that is, one
directory copied from "current" at the time of the import, and named after
the version that was imported).
So for instance, the layout will be something like:
vendor/
libcomplex/
current/
1.0/
1.0a/
1.1a/
libfoobar/
current/
4.7.5/
4.8/
Storing vendor URL per project/repository
-----------------------------------------
Since it's too hard (and slow) to try and auto-detect each time where the
vendor ULR is (and it is out of question, IMO, asking the user to type it
everytime on the command line), I believe it makes sense to find out once
and use it forever.
There will be a local configuration file (eg. ".svnvendor" in the home
directory of each user) which will record which vendor branch to use for
each project/repository. I was thinking of a very easy syntax like:
{UUID1}=/vendor
{UUID2}/project-foo=/project-foo/thirdparty
[....]
where the left part is a (possibly empty) repository path relative to a
repository identified by its UUID; the right part is the
repository-relative path to the vendor directory. For instance, any
svnvendor.py command executed from within a working copy of (any branch of)
"project-foo" above, will automatically assume that the vendor branches are
located within /project-foo/thirdparty in the same repository.
Users will run "svnvendor.py init" (see below) to initialize this file in
an easier fashion (and with some auto-detection magic to speed up common
cases and standard layouts).
Upgrade/downgrade of copies of packages
---------------------------------------
One of the requirements is that it should be easy to upgrade/downgrade the
copy of a package used in a project, while maintaing local changes (that
is, changes to a package which are specific for the project).
To make this operation possible, after evaluating some alternatives
(including the usage of svnmerge.py, and/or complex parsing of svn log), I
decided that it is just easier to store the information within a property
of the directory containing the copy of the vendor branch. I plan to have a
couple of properties:
- svnvendor-name: stores the name of the library (which is the name of
the directory within the vendor URL).
- svnvendor-version: stores the current version of the library (which is
the name of the directory tag within the package directory within the
vendor URL).
So, for instance, if a directory hsa a property svnvendor-name with value
"libcomplex", and svnvendor-version with value "1.4", it means that the
directory is the local copy of (the equivalent of)
[VENDOR_URL]/libcomplex/1.4. When the user asks to upgrade to 1.6 (after
having imported it), svnvendor.py will run something like:
svn merge [VENDOR_URL]/libcomplex/1.4 [VENDOR_URL]/libcomplex/1.6 .
which should merge all the changes between 1.4 and 1.6, while keeping the
local modifications. I'm not sure how "svn merge" is going to handle
subsequent upgrades/downgrades in the same version, but this is another
problem. We will see if we have to make this merge operation harder.
**********************
COMMAND LINE INTERFACE
**********************
--------------------------------------------------------------------------
svnvendor.py init [VENDOR_URL] [--project=REPO_PATH]
Initialize vendor branch support. This will have to be executed once for
each user (for each project using vendor branch support). This command
will:
- Find out the URL of the vendor directory. If specified as an argument,
it's easy :) Otherwise, if the command is executed within a working copy,
it will try to be deduced by stripping parts of the repository path and
looking for a directory named either "vendor" or "thirdparty" within the
repository.
- Find out the project root. By default, it assumes that the project root
is the directory immediately above the vendor directory in the repository
path. It can be overridden with --project.
- Write/update an entry "{UUID}/PROJECT_PATH=VENDOR_PATH" in the .svnvendor
config file.
--------------------------------------------------------------------------
svnvendor.py ls [--project=URL]
Displays a list of all the vendor programs imported in the current
repository. URL is optional to understand what we're talking about (can
point anywhere within the vendor branches or within a project), otherwise
the information is deduced from the working copy.
--------------------------------------------------------------------------
svnvendor.py import FILE/DIR [--name=NAME] [--version=VER] [--project=URL]
Import a new version of the program inside its vendor branch. FILE/DIR
points to either a package (.tar.gz/.zip) or a directory with the extracted
package. The name of the program is deduced by the filename/dirname or
specified with --name. The version of the program is deduced by the
filename/dirname or specified with --version. The algorithm will be
something like this:
- Checkout the current version of the program from its vendor branch into a
temporary directory
- Remove all the files but keep the .svn directories
- Copy/unpack the new package into the directory
- Add/remove files as appropriate (future: detect renames and whatnot)
- Commit the new version
- Tag the new version
This requires two commits, though. I guess I will also add a way to split
it into separate steps, so that the user can do the manual first commit
after double-checking what the script did, and then execute another command
to do the tagging.
--------------------------------------------------------------------------
svnvendor.py copy NAME [--version=VER]
To be executed within a working copy. Copy the vendor program NAME within
the current directory of the current project with a remote copy->WC copy,
and set the special properties (svnvendor-name=NAME, svnvendor-version=VER)
in the WC.
--------------------------------------------------------------------------
svnvendor.py upgrade NAME [--version=VER]
Upgrade a vendor package used by the current project to the latest imported
version (or to the specified version). As explained above, this will make
good use of the svnvendor properties to understand the correct svn merge
operation to execute.
--------------------------------------------------------------------------
svnvendor.py info NAME [--project=URL]
Produces a list of information about the vendor program NAME (list of all
the available versions and maybe other information).
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Design of svnvendor.py
Posted by Giovanni Bajo <ra...@develer.com>.
Julian Foad <ju...@btopenworld.com> wrote:
> Certainly it is good to make a utility as free of unnecessary
> restrictions as possible, if it can still remain clean to use in the
> simple cases, so it is well worth considering John's points, but I
> think he is being too pessimistic in this case.
Sure, I'm keeping his comments well into account.
> I feel many users re-invent or wish for many scripts to facilitate
> recommended ways of working, and so I would like to see us gradually
> distribute more of them, as long as we try to maintain some level of
> consistency (in style, generality versus specificity, etc.) among
> them.
I was planning to reuse much of the existing svnmerge.py code. That would
provide a good level of consistency, I believe. It would also make svnvendor.py
dependent on svnmerge.py instead of being a standalone script, but the
alternatives (cut & paste?) look even worse.
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Design of svnvendor.py
Posted by Julian Foad <ju...@btopenworld.com>.
Giovanni Bajo wrote:
> Also, *exactly because* the Subversion core MUST not know anything more than
> directories and versioned copies, I believe that this kind of "heuristic"
> must be done on external, layered tools. Maybe these tools are not useful
> for *everybody* using Subversion, true. But if they meet common usage
> patterns, that's enough to justify their existence, in my opinion.
Yes, that's right, and I think your proposal has a reasonable level of support
for different repository layouts: it makes the common cases easy and the
unusual cases possible.
Certainly it is good to make a utility as free of unnecessary restrictions as
possible, if it can still remain clean to use in the simple cases, so it is
well worth considering John's points, but I think he is being too pessimistic
in this case.
I feel many users re-invent or wish for many scripts to facilitate recommended
ways of working, and so I would like to see us gradually distribute more of
them, as long as we try to maintain some level of consistency (in style,
generality versus specificity, etc.) among them. Well-written utility scripts
can be extremely useful as examples or starting points for those who need
greater or different functionality, so they don't need to be capable of
handling every scenario.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Design of svnvendor.py
Posted by Giovanni Bajo <ra...@develer.com>.
John Peacock wrote:
>> If you did not read the document, how can you know that the tool is
>> too specific? In my opinion, it allows to do all the common
>> operations needed to handle vendor branches. I would be pleased if
>> you could show me a specific usage case which the tool is not able
>> to cover. In fact, it automates the usage pattern of vendor branches
>> described in the SVN book too.
>
> I did read the document, just not at the level required to consider
> all of the implementation details. You can accuse me of a drive-by
> review, to which I would gladly admit to. I'll try to go through in
> more detail now, but my gut instinct is that you have already chosen
> the means that you want to use to solve your "problem" without having
> spent enough time defining the "problem" you want to solve.
The document contains a section called "requirements". That's what I'm
trying to obtain. Each of the requirement comes from a problem with the
current user interface.
> You are trying to hide the implementation details from the user, which
> very much goes against the grain of the Subversion core.
It does not necessarily mean Subversion did it right. There have been
recurring threads/flames on how to avoid typing those URLs on the command.
Irrespective of what you or I personally feel, there are people who strongly
believe that typing those URLs is totally unnecessary. For once, it totally
violates the "say it once" principle: I said the full URL once at checkout
time, and I never want to repeat it again; give me repo-relative paths on
the command line, thanks. SVK's "//" works very well here. For instance, CVS
was able to do "cvs diff -jMY_BRANCH foo.c". I understand why it's not
possible to do it in Subversion, but the problem is that it's impossible to
do it *even* if you play by all the rules/standard/defaults.
For instance, I have some small tools I have never contributed which I use
to avoid needless fingertypes. "createbranch BRANCHNAME" in a working copy.
"switchto BRANCHNAME" in a working copy. "diffto BRANCHNAME" in a working
copy. Ok, maybe they don't work with every possible layout in the world, but
I use them successfully in different projects and different repositories. I
have still to work in a project where the SVN repository does not follow the
/trunk, /branches, /tags arrangement. I'll keep the tools for me and leave
you to your wasteful fingertyping, but I think this might help to understand
where I'm coming from.
Also, *exactly because* the Subversion core MUST not know anything more than
directories and versioned copies, I believe that this kind of "heuristic"
must be done on external, layered tools. Maybe these tools are not useful
for *everybody* using Subversion, true. But if they meet common usage
patterns, that's enough to justify their existence, in my opinion.
> In
> particular "Implicit URLs" make some huge leaps of faith about the
> repository layout which just isn't true for many sites.
Browsable examples of repositories which would make the configuration file
useless and would force the user to always use URLs? Or, at least, can you
describe with words such repositories?
> You have chosen two common layouts and tried to hide the details in a new
> configuration file. Your proposal is not extensible, however.
This is incorrect. I think I made clear that the configuration file is used
so that people can refer to a vendor branch *only* by using its name. In
case it wasn't clear, it will still be possible to point to the vendor
branch with the full URL, in case you decided to put it in a place different
from all the other vendor branches in the same project.
> You've spent a fair amount of time coming up with the commandline
> invocations,
... which I believe to be a *crucial* point. I want to provide an easy
interface for the users (which include myself).
> but it doesn't seem like much time in considering the
> implementation details. For a simple example, some external library
> use versions ala 1.23 and others user 1.2.3; how are you going to
> determine which is the "latest" vendor branch?
Yes, that is something to be discussed. I believe a simple algorithm will
work in most cases (comparison of tuple(v1.split(".")), I can elaborate
further if you are interested), but note that this is absolutely not a
showstopper. Even if the heuristic is incorrect, it's possible to
explicitally specify the version on the command line. And I could add
something like --version=HEAD/LATEST to mean "the latest one that was
imported into the vendor branch".
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Design of svnvendor.py
Posted by John Peacock <jp...@rowman.com>.
Giovanni Bajo wrote:
> If you did not read the document, how can you know that the tool is too
> specific? In my opinion, it allows to do all the common operations needed to
> handle vendor branches. I would be pleased if you could show me a specific
> usage case which the tool is not able to cover. In fact, it automates the
> usage pattern of vendor branches described in the SVN book too.
I did read the document, just not at the level required to consider all
of the implementation details. You can accuse me of a drive-by review,
to which I would gladly admit to. I'll try to go through in more detail
now, but my gut instinct is that you have already chosen the means that
you want to use to solve your "problem" without having spent enough time
defining the "problem" you want to solve.
You are trying to hide the implementation details from the user, which
very much goes against the grain of the Subversion core. In particular
"Implicit URLs" make some huge leaps of faith about the repository
layout which just isn't true for many sites. You have chosen two common
layouts and tried to hide the details in a new configuration file. Your
proposal is not extensible, however.
You've spent a fair amount of time coming up with the commandline
invocations, but it doesn't seem like much time in considering the
implementation details. For a simple example, some external library use
versions ala 1.23 and others user 1.2.3; how are you going to determine
which is the "latest" vendor branch?
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
Re: [RFC] Design of svnvendor.py
Posted by Giovanni Bajo <ra...@develer.com>.
John Peacock wrote:
> I have no special interest in your tool, which is way too "this is the
> way *we* do things" specific for my taste. You want to add all sorts
> of syntactic sugar which makes your chosen tool easier for *your*
> developers to handle. In my opinion, and that very carries little
> weight in this project as I am only a peripheral developer, this tool
> is far too dedicated to one particular (and I would even say very
> narrow) methodology to belong in the Subversion distro. YMMV.
If you did not read the document, how can you know that the tool is too
specific? In my opinion, it allows to do all the common operations needed to
handle vendor branches. I would be pleased if you could show me a specific
usage case which the tool is not able to cover. In fact, it automates the
usage pattern of vendor branches described in the SVN book too.
> I'll assume that I am in a working copy that is anchored in the
> project root folder, e.g. //project, so we don't have to worry about
> paths, and run commands which will do what I think you mean.
I understand you are doing this for the sake of simplicity in the example,
but this example is ficticious. It absolutely uncommon and unlikley for
normal developers to have checkouts of the whole project tree, including
*all* the branches, *all* the tags, and all the vendor branches. Thus, in
your example, you're saving precious typing for URLs. Let me remember that
not having to type long URL and remember where vendor projects are stored is
another reason for which I think a specific tool is needed.
>> Now, how can I get back to version 1.1?
>
> $ svk smerge -c ./tags/libcomplex-1.1 ./local/trunk
>
> #if no conflicts
>
> $ svk smerge ./tags/libcomplex-1.1 ./local/trunk
OK, thanks for the explanation. It looks like SVK does everything I need,
minus the automatic management of vendor directory (so that I name vendor
packages by name + version and not by full URL). I still believe there is
value in abstracting from these details, plus I don't plan on using SVK at
the moment.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Design of svnvendor.py
Posted by John Peacock <jp...@rowman.com>.
Giovanni Bajo wrote:
> Did you read it the design document through?
No, I read your first paragraph about how difficult you find vendor
imports and that is what I am responding to. I was merely pointing out
that vendor imports don't have to be difficult.
I have no special interest in your tool, which is way too "this is the
way *we* do things" specific for my taste. You want to add all sorts of
syntactic sugar which makes your chosen tool easier for *your*
developers to handle. In my opinion, and that very carries little
weight in this project as I am only a peripheral developer, this tool is
far too dedicated to one particular (and I would even say very narrow)
methodology to belong in the Subversion distro. YMMV.
Now on to the specific comments you made:
> This does a new import of the vendor, so it's not answering my concern.
Actually, if you read the example on the elixus.org page, you'll see
that the command I cited was exactly the same for every single vendor
import. The import is targeted at the same "current" path every time
and SVK does the right thing.
> The problem I'm thinking of is the following:
I'll assume that I am in a working copy that is anchored in the project
root folder, e.g. //project, so we don't have to worry about paths, and
run commands which will do what I think you mean.
>
> 1) svk import of libcomplex 1.1
$ svk import -m 'libcomplex-1.1' ./current ~/path/to/libcomplex-1.1
$ svk cp -m 'libcomplex-1.1' ./current ./tags/libcomplex-1.1
> 2) svk cp: use 1.1 in my project
$ svk cp -p ./tags/libcomplex-1.1 ./local/trunk
(you could also copy from ./current, but this make a little more sense
from a history standpoint).
> 3) svk import of libcomplex 1.2
$ svk import -m 'libcomplex-1.2' ./current ~/path/to/libcomplex-1.2
$ svk cp -m 'libcomplex-1.2' ./current ./tags/libcomplex-1.2
> 4) svk smerge: upgrade to 1.2 in my project
$ svk smerge -C ./tags/libcomplex-1.2 ./local/trunk
#if no conflicts
$ svk smerge ./tags/libcomplex-1.2 ./local/trunk
>
> Now, how can I get back to version 1.1?
$ svk smerge -c ./tags/libcomplex-1.1 ./local/trunk
#if no conflicts
$ svk smerge ./tags/libcomplex-1.1 ./local/trunk
HTH
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
Re: [RFC] Design of svnvendor.py
Posted by Giovanni Bajo <ra...@develer.com>.
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
Re: [RFC] Design of svnvendor.py
Posted by John Peacock <jp...@rowman.com>.
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
Re: [RFC] Design of svnvendor.py
Posted by Giovanni Bajo <ra...@develer.com>.
John Peacock wrote:
>> I find inconvenient the way vendor branches "work" under SVN. The
>> book describes quite a few operations that need to be manually done,
>> and some of them are really annoying:
>
> Why reinvent the wheel when SVK does this already:
>
> 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.
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").
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Design of svnvendor.py
Posted by John Peacock <jp...@rowman.com>.
Giovanni Bajo wrote:
> I find inconvenient the way vendor branches "work" under SVN. The book
> describes quite a few operations that need to be manually done, and some of
> them are really annoying:
Why reinvent the wheel when SVK does this already:
http://svk.elixus.org/?SVKTutorial
See the section labeled "Painless import".
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