[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: Roman Kellner <muzungu_at_gmx.net>
Date: Mon, 09 May 2011 14:52:42 +0200

Ok, the tagging and referencing the tags is a solution, but...

...governing approx. 400 common files with in their wanted revisions for
approx 4 -6 similar projects would have been challenging enough in the
svn:externals. At least one could write a tool on top if necessary.
If I imagine the repo tree with all the tags of ~400 resources and keeping
it under control in the externals especially since the file name have the
tool-dependent, very "self-explaining" format e.g.
18f8d8ca-6caf-4daf-afc7-732d765a9846.mtx, somehow scares me. But could also
be a chance to organise at least the tags in a more human readable manner.

By observing the /.svn/entries file after and before checkout / update, I
found that the two revisions per file seem to be the requsted / pristine
and the actual in WC. I also found that --ignore-externals has not effects
once one is inside the the "external item".

Do I get it right, that such feature requested would imply format
changes/extensions to the WCs entires file and is not as easily to
introduced as I expected?

I will have to think things over and will, if I still see the need, discuss
the feature requests in the user_at_subversion.apache.org any some further


> -------- Original-Nachricht --------
> Datum: Sun, 8 May 2011 15:29:17 +0200
> Von: Johan Corveleyn <jcorvel_at_gmail.com>
> An: Roman Kellner <muzungu_at_gmx.net>
> CC: sbutler_at_elego.de, julian.foad_at_wandisco.com, brane_at_e-reka.si,
> dev_at_subversion.apache.org
> Betreff: Re: Feature wish/request: [--externals MODE] switch on update
> 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

NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone
Received on 2011-05-09 14:53:14 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.