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. ---Roman > > -------- Original-Nachricht -------- > Datum: Fri, 06 May 2011 13:56:43 +0200 > Von: "Roman Kellner" <muzu...@gmx.net> > An: Julian Foad <julian.f...@wandisco.com>, sbut...@elego.de > CC: dev@subversion.apache.org, br...@e-reka.si > Betreff: Re: Feature wish/request: [--externals MODE] switch on update > > Please see in your text. > > ---Roman > > > > > -------- Original-Nachricht -------- > > Datum: Fri, 06 May 2011 12:13:30 +0100 > > Von: Julian Foad <julian.f...@wandisco.com> > > An: Stephen Butler <sbut...@elego.de> > > CC: Roman <muzu...@gmx.net>, "Branko Čibej" <br...@e-reka.si>, > > dev@subversion.apache.org > > 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 > update --externals=interactive-revisioned > update --externals=ignore-revisioned > update --externals=to-revision > update --externals=interactive-to-revision > > 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. > > --accept ACTION > --depth ARG > --diff3-cmd CMD > --editor-cmd CMD > --quiet (-q) > --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 > externals switches. > e.g. > > update --ignore-externals > update --interactive-revisioned-externals > update --ignore-revisioned-externals > update --to-revision-externals > update --interactive-to-revision-externals > > If or since I can update files one by one the > --externals=interactive-to-revision and > --externals=interactive-revisioned > are overkill. You are right. > > > Currently > > 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 > > so. > > > > 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 > > fine > > > >> on checkout (both formats <1.5 and >=1.5). But when updating the > > without > > > >> 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 > > client > > > I've tested), the following syntax pins the externals version as > > expected: > > > > > > http://example.com/svn/foo/bar@99 foobar > > > > > > Changes to the "bar" directory (in the repository) after version 99 > are > > not > > > 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 > > revision, > > > >> update would update to the head. At least that is what we > > experienced. > > > >> 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 > > how > > > > 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 > -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
