On Jan 17, 2006, at 15:58, Doyle, Patrick wrote:
> I've read the chapter in the book about vendor branches and I have
> a couple
> of questions...
>
> 1) The book says to import the vendor drop in to .../current and
> then to
> copy it to .../1.0. Without having read that, I would have naively
> imported
> a vendor drop into .../1.0 and then copied it to .../current. Is
> this just
> a case of "If everybody else in the world goes left, Patrick will
> inevitably
> choose to go right", or is there something more fundamental in the
> choice to
> import into "current" and then copy to "1.0"?
In the initial import, it's completely unimportant in which order you
do it.
Subsequently, when you update to a newer version of the vendor
project, the update will happen in "current" (because otherwise
svn_load_dirs would first have to figure out what the most recent tag
is; by using "current" that can all be avoided) and then be copied to
a new tag.
So perhaps the recommendation to initially import into "current",
then copy to the version tag, is to preserve consistency between
these two operations.
> 2) What do folks do when the vendor drop is some other SVN
> repository? I
> recognize that this can be something of a moving target --
> especially when
> one wants to track the trunk. My first attempt was to check out a
> working
> copy and to just import it into my repository according to the
> book. That
> worked fine (SVN cleverly ignored all of the .svn directories, as I
> hoped/thought I'd read/ it would). But when I checkout out the
> vendor drop
> into my own working copy, I found that none of the properties had been
> imported. (Not too surprising).
If the vendor project is already in Subversion and your repository
and theirs are using the same access method, then I believe you can
skip the whole vendor branch thing. If you want to use their project
as an external, without modifying their code, you can do that,
pointing your svn:external property directly at (a tag, a branch or
the trunk of) their repository. If you want to modify their code a
bit first, you can initially export a revision of their code and
import it into some place in your repository, then merge in changes
from their repository as you like. No need to keep your own duplicate
in /vendor.
If you use a different repository access method (they use http and
you use svn+ssh, perhaps), then (sometimes?) Subversion will show an
error that it doesn't support mixed access methods, when trying to do
a merge from their repository. I can't fathom why this should be a
problem for it, but apparently it is. You could try to use "svn diff"
to make a patch from their repository and apply it to your local
version, but that will fall down with added or removed (and therefore
moved) files, so that probably doesn't work. If you're just using
externals, though, and not modifying their project, then this mixed-
access-method issue isn't a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jan 17 23:02:01 2006