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

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" <muzungu_at_gmx.net>
> An: Julian Foad <julian.foad_at_wandisco.com>, sbutler_at_elego.de
> CC: dev_at_subversion.apache.org, brane_at_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.foad_at_wandisco.com>
> > An: Stephen Butler <sbutler_at_elego.de>
> > CC: Roman <muzungu_at_gmx.net>, "Branko Čibej" <brane_at_e-reka.si>,
> > dev_at_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