[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Feature wish/request: [--externals MODE] switch on update

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Sun, 8 May 2011 15:29:17 +0200

On Fri, May 6, 2011 at 3:03 PM, Roman Kellner <muzungu_at_gmx.net> wrote:
> Hi
>
> Did some more testing and found the following:
>
> Setup. folder "withexternals" has prop svn:externals with a number of
> revisioned and un-revisioned externals files.
>
> What happens:
>
> checkout folder "withexternals" -> all revisioned externals on external
> revision
> update file "revisioned-externals" -> revisioned externals file on HEAD
> update folder "withexternals" -> all revisioned externals files on external
> revision again.
> update file "revisioned-externals" to external revison -> not possible with
> simple switch but have to look up the 'external revision' in svn:externals
> of folder "withexternals" and then update filen with command line parameter
> -r 'external revision', this is rather cumbersome with a large number of
> external files.
>
> I found that the external revision and the external location is stated in
> the .svn/entries file.
>  I guess the info was available in the WC.

Yes, this corresponds to what others have already said in this thread,
and it is the correct behavior as currently designed:

 - If you update the folder that contains the svn:externals property,
it will update the externals exactly to what was specified in the
svn:externals property.

- If you target (something inside) the "external item" itself, you
will update it to whatever is specified in your update command (either
HEAD, or a specific revision).

That's normal, because the external item itself is just a separate,
embedded working copy. Once you're inside it, or targeting it
directly, it doesn't know anymore about the externals definition that
brought it in (the svn:externals property on the parent directory).

A way to make sure that your "external item" stays pinned, is to make
a tag first, and then point your external property to that tag (even
best with a peg revision pointing to the tag). Combined with a
pre-commit hook that makes sure tags cannot be modified, this will
have the desired effect of a "pinned external". When you want to
"move" the external to a new revision, just create a new tag, and
point the external definition to that tag.

Roman, if you want to discuss this further, I think it's best that you
take this to the users list. People there may have other strategies of
coping with this problem, or can help streamline your ideas into
something that fits for the general user-base ...

Cheers,

-- 
Johan
Received on 2011-05-08 15:30:08 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.