Please see in your text.
> -------- Original-Nachricht --------
> Datum: Fri, 06 May 2011 12:13:30 +0100
> Von: Julian Foad <julian.foad_at_wandisco.com>
> An: Stephen Butler <sbutler_at_elego.de>
> CC: Roman <muzungu_at_gmx.net>, "Branko Čibej" <brane_at_e-reka.si>,
> Betreff: Re: Feature wish/request: [--externals MODE] switch on update
> OK, now we understand. At first I assumed you were running
> "update" on
> the root of the main working copy. When you run "update" on the
> external directory itself, then I expect it to update to head. This is
> because, as the book says, the external directory behaves as a separate
> working copy.
We have a non-external directory with a number of non-external files and
external revisioned files in it.
The revisioned externals generally serve as source libraries. But if the
"library" file needs new features or bugfixes, the external file will be
unpinned, changed, commited and pinned to the commited revision again.
> You suggest that the behaviour of:
> update --externals=ignore
> should be the same as "--ignore-externals". But I don't think you want
> the same behaviour that "--ignore-externals" currently has.
update --externals [MODE]
update --externals=ignore substituting update --ignore-externals
I defined update --externals=ignore only to have the format consistent.
I guess program command --switch switchValue is a rather common syntax and
was derived from the same svn commands switches.
--revision (-r) REV
I found and find it rather logical to have a switch that
addresses the externals behaviour and different modes that N specific
If or since I can update files one by one the
--externals=interactive-to-revision and --externals=interactive-revisioned
are overkill. You are right.
> it only ignores external definitions that it finds inside the target WC;
> it doesn't check whether this target WC that it starts looking at is
> already an external within some outer WC.
> I think you want Subversion to notice if the target being updated is an
> external inside another working copy, and to ignore this whole update if
> The idea that the external should not behave like a completely separate
> WC but more like it is part of the same working copy is a good idea, in
> concept. The implementation could be difficult, and backward
> compatibility is a concern, but this is certainly an idea that is worth
> thinking about.
> I think your set of "--externals=..." options is too complex. The UI
> should be much simpler, something like just one option that says whether
> the revision specified on the update command should override the
> revision specified by the external definition. The idea of invoking an
> interactive prompt is overkill.
> - Julian
> On Fri, 2011-05-06 at 11:36 +0200, Stephen Butler wrote:
> > On May 6, 2011, at 11:06 , Julian Foad wrote:
> > > On Thu, 2011-05-05 at 23:18 +0200, Roman wrote:
> > >> Hi Branko, hi Julian
> > >>
> > >> @Branko: I know the -r feature of the svn:externals and it worked
> > >> on checkout (both formats <1.5 and >=1.5). But when updating the
> > >> special switches it did update to the head regardless whether the
> > >> external was pinned to a revision or not.
> > Hi Roman,
> > What is your svn:externals value? Using TortoiseSVN (or any other
> > I've tested), the following syntax pins the externals version as
> > http://example.com/svn/foo/bar@99 foobar
> > Changes to the "bar" directory (in the repository) after version 99 are
> > sent to the local "foobar" directory when I update it.
> > Regards,
> > Steve
> > >> To be honest, we did not test with the command line client but with
> > >> TortoiseSVN and PushOk. Both behaved the same, which lead me to the
> > >> conclusion, that it is a normal svn behaviour.
> > >>
> > >> @Julian:Yes, I guess so. checkout would retrieve the pinned
> > >> update would update to the head. At least that is what we
> > >> Would you consider this a wrong behaviour?
> > >
> > > Yes, I would consider that wrong behaviour.
> > >
> > > I haven't tested to see what 'svn' actually does and I am not sure
> > > it was originally designed to work.
> > >
> > > - Julian
> > >
> > --
> > Stephen Butler | Senior Consultant
> > elego Software Solutions GmbH
> > Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
> > tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
> > fax: +49 30 2345 8695 | http://www.elegosoft.com
> > Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
> > Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Received on 2011-05-06 13:57:14 CEST