You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by mu...@gmx.net on 2011/05/05 09:42:08 UTC
Feature wish/request: [--externals MODE] switch on update
Normal 0 false false false
MicrosoftInternetExplorer4
Hello all
Reading the email
From: Karl Fogel <kf...@collab.net>
Subject: Please ask on the list before filing a new issue.
I file my wish/request to this maillist and hope it has not already
been discussed.
Content
1. Feature update [--externals MODE] switch
2. Feature update-externals default configuration
3. Motivation/Use-case
1. Feature update [--externals MODE] switch:
The update command shall be extended by the following switch and modes:
update [-r rev] [-N] [--externals MODE]
MODE: ignore:
same as [--ignore-externals] which shall be deprecated but remain for
backward compatibility
MODE: interactive-revisioned:
externals set to a fixed revision will not automatically updated to the
HEAD or the command line revision -r rev but asks per external entry: [yes]
[no] [yes to all],[no to all]
MODE: ignore-revisioned:
externals set to a fixed revision will not get updated. Only externals
working on the head (no –rNNNN entry) will be updated to the HEAD or
the command line revision –r rev
MODE: to-revision:
updates externals to the fixed revision stated in the svn:exterals
property, all others to the HEAD or the command line revison -r rev
MODE: interactive-to-revision:
updates externals to the fixed revision stated in the svn:exterals
property, all others to the HEAD or the command line revison -r rev, but
asks per external entry: [yes] [no] [yes to all],[no to all]
2. Feature update-externals default configuration
The SVN client(s) shall have a mean to set one --externals mode as
its default e.g. in the SVN command line clients config file.
update-externals-mode = MODE It shall be possible to
overrule configuration from the file by the command line.
Motivation/Use-case:
We want use the svn:externals to retrieve common resources in defined
versions/revisions into various project. That the resources for the
particular project keep their revision is very important. They may not
change by accident. An "standard" update has easily and unwillingly
happened, as also other user report in the net. If one is lucky the
compilation fails and one has a indication that sonething is wrong. In the
worst case everything compiles and works fine, but for a rarely used
functionality under very unlikely conditions.
We would like to have update modes that not simple automatically update
everything to the HEAD or -r rev, but can distingush between "internals",
externals and revisioned exterals and issue a waring (interactive)
I assume that this is not a server but a pure client feature(?).
Kind regards
Roman
--
Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Roman Kellner <mu...@gmx.net>.
We used those two below but not the PEG (@NNN),
basically because I understood the PEG as something different.
-rNNNN http://svn.example.com/example-path/example-file.ext
example-file.ext
example-file.ext -rNNNN
http://svn.example.com/example-path/example-file.ext
I guess I have to reread the PEG section.
Both behaviours would be fine for me:
1. As it is or seems to be:
svn checkout -> to externals revision,
svn update (without --ignore-externals)-> HEAD or command line revision
-r N
But then I would like to have means to:
1) prevent the update for pinned externals
2) get warned or asked if I really want to update, since it seems to
easy to update such externals to the HEAD without recognising
3) update the pinned externals back to the stated externals revision,
without having to checkout everything
4) possibly have 3) in an interactive mode.
2. The externals revsions -r or ev. @N pins the external absolutely and
unconditionally to the revision what ever update command I run.
This would imply that I first have to un-pin it in svn:externals, which
is much enough a conscious action to me, not to be done by accident.
---Roman
> -------- Original-Nachricht --------
> Datum: Fri, 06 May 2011 12:39:53 +0200
> Von: "Branko Čibej" <br...@e-reka.si>
> An: Philip Martin <ph...@wandisco.com>
> CC: Roman Kellner <mu...@gmx.net>, Bert Huijben <be...@qqmail.nl>,
> julian.foad@wandisco.com, dev@subversion.apache.org
> Betreff: Re: Feature wish/request: [--externals MODE] switch on update
>
> On 06.05.2011 12:25, Philip Martin wrote:
> > Branko Čibej <br...@e-reka.si> writes:
> >
> >> On 06.05.2011 12:08, Philip Martin wrote:
> >>> "Roman Kellner" <mu...@gmx.net> writes:
> >>>
> >>>> But what about the features I wish/request. Do they somehow exist,
> are they
> >>>> in the pipeline or do you consider them rubbish?
> >>> You didn't answer the question about why using '-r N' or '@N' in an
> >>> external does not do what you need. If your client doesn't respect
> the
> >>> revision in an external then your client has a bug.
> >> Yes he did answer that question. It's because, when you're inside the
> >> part of the WC that was created by the external, and you do an "svn
> up",
> >> the client doesn't see the external definition and updates to HEAD.
> Even
> >> the book says so.
> > How would his feature request fix that?
>
> His feature request is basically to fix that, although I don't agree
> with the request itself. It'd be quite enough to just fix that
> behaviour, there's no new UI required, IMO.
>
> -- Brane
>
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Branko Čibej <br...@e-reka.si>.
On 06.05.2011 12:25, Philip Martin wrote:
> Branko Čibej <br...@e-reka.si> writes:
>
>> On 06.05.2011 12:08, Philip Martin wrote:
>>> "Roman Kellner" <mu...@gmx.net> writes:
>>>
>>>> But what about the features I wish/request. Do they somehow exist, are they
>>>> in the pipeline or do you consider them rubbish?
>>> You didn't answer the question about why using '-r N' or '@N' in an
>>> external does not do what you need. If your client doesn't respect the
>>> revision in an external then your client has a bug.
>> Yes he did answer that question. It's because, when you're inside the
>> part of the WC that was created by the external, and you do an "svn up",
>> the client doesn't see the external definition and updates to HEAD. Even
>> the book says so.
> How would his feature request fix that?
His feature request is basically to fix that, although I don't agree
with the request itself. It'd be quite enough to just fix that
behaviour, there's no new UI required, IMO.
-- Brane
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@e-reka.si> writes:
> On 06.05.2011 12:08, Philip Martin wrote:
>> "Roman Kellner" <mu...@gmx.net> writes:
>>
>>> But what about the features I wish/request. Do they somehow exist, are they
>>> in the pipeline or do you consider them rubbish?
>> You didn't answer the question about why using '-r N' or '@N' in an
>> external does not do what you need. If your client doesn't respect the
>> revision in an external then your client has a bug.
>
> Yes he did answer that question. It's because, when you're inside the
> part of the WC that was created by the external, and you do an "svn up",
> the client doesn't see the external definition and updates to HEAD. Even
> the book says so.
How would his feature request fix that?
--
Philip
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Branko Čibej <br...@e-reka.si>.
On 06.05.2011 12:08, Philip Martin wrote:
> "Roman Kellner" <mu...@gmx.net> writes:
>
>> But what about the features I wish/request. Do they somehow exist, are they
>> in the pipeline or do you consider them rubbish?
> You didn't answer the question about why using '-r N' or '@N' in an
> external does not do what you need. If your client doesn't respect the
> revision in an external then your client has a bug.
Yes he did answer that question. It's because, when you're inside the
part of the WC that was created by the external, and you do an "svn up",
the client doesn't see the external definition and updates to HEAD. Even
the book says so.
-- Brane
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Philip Martin <ph...@wandisco.com>.
"Roman Kellner" <mu...@gmx.net> writes:
> But what about the features I wish/request. Do they somehow exist, are they
> in the pipeline or do you consider them rubbish?
You didn't answer the question about why using '-r N' or '@N' in an
external does not do what you need. If your client doesn't respect the
revision in an external then your client has a bug.
--
Philip
Re: RE: Feature wish/request: [--externals MODE] switch on update
Posted by Roman Kellner <mu...@gmx.net>.
We are running the following version(s) below and have not yet reached
1.7.
svn windows client:
svn, Version 1.6.6 (r40053)
übersetzt Oct 26 2009, 20:14:36
Copyright (C) 2000-2009 CollabNet.
Subversion ist Open-Source-Software, siehe http://subversion.tigris.org/
Dieses Produkt enthält Software, die von CollabNet
(http://www.Collab.Net/) entwickelt wurde.
svn server on SLES 11:
svn, version 1.5.2 (r32768)
compiled Feb 25 2009, 16:12:21
CollabNet too.
But what about the features I wish/request. Do they somehow exist, are they
in the pipeline or do you consider them rubbish?
Shall I fill them to the issue tracker?
Other bug fixes will not help me/us in the particular case. And I would not
consider the current behaviour buggy.
---Roman
>
> -------- Original-Nachricht --------
> Datum: Fri, 6 May 2011 01:45:17 +0200
> Von: "Bert Huijben" <be...@qqmail.nl>
> An: "'Branko Čibej'" <br...@e-reka.si>, "'Roman'" <mu...@gmx.net>
> CC: "'Julian Foad'" <ju...@wandisco.com>, dev@subversion.apache.org
> Betreff: RE: Feature wish/request: [--externals MODE] switch on update
>
>
>
> > -----Original Message-----
> > From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> > Sent: donderdag 5 mei 2011 23:40
> > To: Roman
> > Cc: Julian Foad; dev@subversion.apache.org
> > Subject: Re: Feature wish/request: [--externals MODE] switch on update
> >
> > Ha. That quote from SVNbook is relevant.
> > I would assume that this "feature" could be fixed in 1.7, since there
> is
> > no longer a separate, disjoint "external working copy"?
>
> In 1.7 directory externals are still in their own working copy (with it's
> own .svn/wc.db and pristine store)
>
> Making them share a database and pristine store isn't that hard. But
> making it a single working copy requires a lot of work.
>
> (Currently almost all code outside the lowest layers of wc_db assumes
> that a node and its children are always from the same repository. If you
> void that assumption...)
>
>
> There are some other changes/fixes around externals: E.g. you can commit
> from two workingcopies of the same repository in a single commit.
>
> Bert
>
>
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
RE: Feature wish/request: [--externals MODE] switch on update
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@xbc.nu] On Behalf Of Branko Cibej
> Sent: donderdag 5 mei 2011 23:40
> To: Roman
> Cc: Julian Foad; dev@subversion.apache.org
> Subject: Re: Feature wish/request: [--externals MODE] switch on update
>
> Ha. That quote from SVNbook is relevant.
> I would assume that this "feature" could be fixed in 1.7, since there is
> no longer a separate, disjoint "external working copy"?
In 1.7 directory externals are still in their own working copy (with it's own .svn/wc.db and pristine store)
Making them share a database and pristine store isn't that hard. But making it a single working copy requires a lot of work.
(Currently almost all code outside the lowest layers of wc_db assumes that a node and its children are always from the same repository. If you void that assumption...)
There are some other changes/fixes around externals: E.g. you can commit from two workingcopies of the same repository in a single commit.
Bert
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Branko Čibej <br...@e-reka.si>.
Ha. That quote from SVNbook is relevant.
I would assume that this "feature" could be fixed in 1.7, since there is
no longer a separate, disjoint "external working copy"?
-- Brane
On 05.05.2011 23:18, 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.
> 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?
> I can not tell now which version of tortoise and PuskOk it was since I
> am at home now. I can tell you tomorrow from work. But since we did
> not test with the native svn client they might not be of too much
> interest any way. I can verify tomorrow with the command line client.
> The behaviour is not exactly wrong. But it is too easy to update and
> ending up with the head when you expect it to be pinned and possibly
> not recognising it. We would like to have the option to really pin it
> or the option to at least be asked if one really want to leave the
> pinned revision. Furthermore would it be nice to update to the pinned
> revisions in the externals without having to checkout everything from
> scratch.
>
> But there is the --ignore-externals switch. Would that only ignore the
> non-pinned since the pinned should be ignore anyway?
>
> What is the behaviour you would expect? Or where can I read it.
>
> I just found the following at the bottom of chapter:
>
> -------------------- Externals Definitions" in
> http://svnbook.red-bean.com/nightly/en/svn-book.htm
> -------------------------
>
> Warning
>
> External working copies are still completely self-sufficient working
> copies. You can operate directly on them as you would any other
> working copy. This can be a handy feature, allowing you to examine an
> external working copy independently of any primary working copy whose
> |svn:externals| property caused its instantiation. Be careful, though,
> that you don't inadvertently modify your external working copy in
> subtle ways that cause problems. /For example, while an externals
> definition might specify that the external working copy should be held
> at a particular revision number, if you run *svn update* directly on
> the external working copy, Subversion will oblige, and now your
> external working copy is out of sync with its declaration in the
> primary working copy/. Using *svn switch* to directly switch the
> external working copy (or some portion thereof) to another URL could
> cause similar problems if the contents of the primary working copy are
> expecting particular contents in the external content.
>
> Besides the *svn checkout*, *svn update*, *svn switch*, and *svn
> export* commands which actually manage the /disjoint/ (or
> disconnected) subdirectories into which externals are checked out, the
> *svn status* command also recognizes externals definitions. It
> displays a status code of |X| for the disjoint external
> subdirectories, and then recurses into those subdirectories to display
> the status of the external items themselves. You can pass the
> |--ignore-externals| option to any of these subcommands to disable
> externals definition processing.
>
> -------------------- {End} Externals Definitions" in
> http://svnbook.red-bean.com/nightly/en/svn-book.htm {End}
> -------------------------
>
> I feel the requests are not obsolete yet.
>
> What do you think?
>
> Greets
>
> Roman
>
>
> Am 05.05.2011 14:41, schrieb Julian Foad:
>> Hi Roman.
>>
>> Branko Čibej wrote:
>>> You can already pin an external to a particular version by adding a -r
>>> parameter to the definition in svn:externals.
>>>
>>> -- Brane
>>>
>>> On 05.05.2011 09:42, muzungu@gmx.net wrote:
>>>> 1. Feature update [--externals MODE] switch:
>>>>
>>>> The update command shall be extended by the following switch and modes:
>>>>
>>>> update [-r rev] [-N] [--externals MODE]
>>>>
>>>> MODE: ignore:
>>>> same as [--ignore-externals] which shall be deprecated but remain for
>>>> backward compatibility
>>>>
>>>> MODE: interactive-revisioned:
>>>> externals set to a fixed revision will not automatically updated to the
>>>> HEAD or the command line revision -r rev but asks per external entry: [yes]
>>>> [no] [yes to all],[no to all]
>>>>
>>>> MODE: ignore-revisioned:
>>>> externals set to a fixed revision will not get updated. Only externals
>>>> working on the head (no –rNNNN entry) will be updated to the HEAD or
>>>> the command line revision –r rev
>>>>
>>>> MODE: to-revision:
>>>> updates externals to the fixed revision stated in the svn:exterals
>>>> property, all others to the HEAD or the command line revison -r rev
>>>>
>>>> MODE: interactive-to-revision:
>>>> updates externals to the fixed revision stated in the svn:exterals
>>>> property, all others to the HEAD or the command line revison -r rev, but
>>>> asks per external entry: [yes] [no] [yes to all],[no to all]
>> [...]
>>>> Motivation/Use-case:
>>>> We want use the svn:externals to retrieve common resources in defined
>>>> versions/revisions into various project. That the resources for the
>>>> particular project keep their revision is very important. They may not
>>>> change by accident. An "standard" update has easily and unwillingly
>>>> happened, as also other user report in the net. If one is lucky the
>>>> compilation fails and one has a indication that sonething is wrong. In the
>>>> worst case everything compiles and works fine, but for a rarely used
>>>> functionality under very unlikely conditions.
>>>> We would like to have update modes that not simple automatically update
>>>> everything to the HEAD or -r rev, but can distingush between "internals",
>>>> externals and revisioned exterals and issue a waring (interactive)
>> What exactly is wrong with the standard "update" command in your use
>> cases? Are you saying the standard update command ignores the "-r"
>> setting in the externals definitions? In what commands, exactly, and
>> what version of svn?
>>
>> - Julian
>>
>>
>>>> I assume that this is not a server but a pure client feature(?).
>>
>
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Roman Kellner <mu...@gmx.net>.
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@subversion.apache.org any some further
first.
Cheers.
>
> -------- Original-Nachricht --------
> Datum: Sun, 8 May 2011 15:29:17 +0200
> Von: Johan Corveleyn <jc...@gmail.com>
> An: Roman Kellner <mu...@gmx.net>
> CC: sbutler@elego.de, julian.foad@wandisco.com, brane@e-reka.si,
> dev@subversion.apache.org
> Betreff: Re: Feature wish/request: [--externals MODE] switch on update
>
> On Fri, May 6, 2011 at 3:03 PM, Roman Kellner
> <mu...@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
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Johan Corveleyn <jc...@gmail.com>.
On Fri, May 6, 2011 at 3:03 PM, Roman Kellner <mu...@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
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Roman Kellner <mu...@gmx.net>.
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" <mu...@gmx.net>
> An: Julian Foad <ju...@wandisco.com>, sbutler@elego.de
> CC: dev@subversion.apache.org, brane@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 <ju...@wandisco.com>
> > An: Stephen Butler <sb...@elego.de>
> > CC: Roman <mu...@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
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Roman Kellner <mu...@gmx.net>.
Please see in your text.
---Roman
>
> -------- Original-Nachricht --------
> Datum: Fri, 06 May 2011 12:13:30 +0100
> Von: Julian Foad <ju...@wandisco.com>
> An: Stephen Butler <sb...@elego.de>
> CC: Roman <mu...@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
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Julian Foad <ju...@wandisco.com>.
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.
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. 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
>
>
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Stephen Butler <sb...@elego.de>.
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
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Julian Foad <ju...@wandisco.com>.
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.
> 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
> I can not tell now which version of tortoise and PuskOk it was since I
> am at home now. I can tell you tomorrow from work. But since we did not
> test with the native svn client they might not be of too much interest
> any way. I can verify tomorrow with the command line client.
> The behaviour is not exactly wrong. But it is too easy to update and
> ending up with the head when you expect it to be pinned and possibly not
> recognising it. We would like to have the option to really pin it or the
> option to at least be asked if one really want to leave the pinned
> revision. Furthermore would it be nice to update to the pinned revisions
> in the externals without having to checkout everything from scratch.
>
> But there is the --ignore-externals switch. Would that only ignore the
> non-pinned since the pinned should be ignore anyway?
>
> What is the behaviour you would expect? Or where can I read it.
>
> I just found the following at the bottom of chapter:
>
> -------------------- Externals Definitions" in
> http://svnbook.red-bean.com/nightly/en/svn-book.htm
> -------------------------
>
> Warning
>
> External working copies are still completely self-sufficient working
> copies. You can operate directly on them as you would any other working
> copy. This can be a handy feature, allowing you to examine an external
> working copy independently of any primary working copy whose
> |svn:externals| property caused its instantiation. Be careful, though,
> that you don't inadvertently modify your external working copy in subtle
> ways that cause problems. /For example, while an externals definition
> might specify that the external working copy should be held at a
> particular revision number, if you run *svn update* directly on the
> external working copy, Subversion will oblige, and now your external
> working copy is out of sync with its declaration in the primary working
> copy/. Using *svn switch* to directly switch the external working copy
> (or some portion thereof) to another URL could cause similar problems if
> the contents of the primary working copy are expecting particular
> contents in the external content.
>
> Besides the *svn checkout*, *svn update*, *svn switch*, and *svn export*
> commands which actually manage the /disjoint/ (or disconnected)
> subdirectories into which externals are checked out, the *svn status*
> command also recognizes externals definitions. It displays a status code
> of |X| for the disjoint external subdirectories, and then recurses into
> those subdirectories to display the status of the external items
> themselves. You can pass the |--ignore-externals| option to any of these
> subcommands to disable externals definition processing.
>
> -------------------- {End} Externals Definitions" in
> http://svnbook.red-bean.com/nightly/en/svn-book.htm {End}
> -------------------------
>
> I feel the requests are not obsolete yet.
>
> What do you think?
>
> Greets
>
> Roman
>
>
> Am 05.05.2011 14:41, schrieb Julian Foad:
> > Hi Roman.
> >
> > Branko Čibej wrote:
> >> You can already pin an external to a particular version by adding a -r
> >> parameter to the definition in svn:externals.
> >>
> >> -- Brane
> >>
> >> On 05.05.2011 09:42, muzungu@gmx.net wrote:
> >>> 1. Feature update [--externals MODE] switch:
> >>>
> >>> The update command shall be extended by the following switch and modes:
> >>>
> >>> update [-r rev] [-N] [--externals MODE]
> >>>
> >>> MODE: ignore:
> >>> same as [--ignore-externals] which shall be deprecated but remain for
> >>> backward compatibility
> >>>
> >>> MODE: interactive-revisioned:
> >>> externals set to a fixed revision will not automatically updated to the
> >>> HEAD or the command line revision -r rev but asks per external entry: [yes]
> >>> [no] [yes to all],[no to all]
> >>>
> >>> MODE: ignore-revisioned:
> >>> externals set to a fixed revision will not get updated. Only externals
> >>> working on the head (no–rNNNN entry) will be updated to the HEAD or
> >>> the command line revision–r rev
> >>>
> >>> MODE: to-revision:
> >>> updates externals to the fixed revision stated in the svn:exterals
> >>> property, all others to the HEAD or the command line revison -r rev
> >>>
> >>> MODE: interactive-to-revision:
> >>> updates externals to the fixed revision stated in the svn:exterals
> >>> property, all others to the HEAD or the command line revison -r rev, but
> >>> asks per external entry: [yes] [no] [yes to all],[no to all]
> > [...]
> >>> Motivation/Use-case:
> >>> We want use the svn:externals to retrieve common resources in defined
> >>> versions/revisions into various project. That the resources for the
> >>> particular project keep their revision is very important. They may not
> >>> change by accident. An "standard" update has easily and unwillingly
> >>> happened, as also other user report in the net. If one is lucky the
> >>> compilation fails and one has a indication that sonething is wrong. In the
> >>> worst case everything compiles and works fine, but for a rarely used
> >>> functionality under very unlikely conditions.
> >>> We would like to have update modes that not simple automatically update
> >>> everything to the HEAD or -r rev, but can distingush between "internals",
> >>> externals and revisioned exterals and issue a waring (interactive)
> > What exactly is wrong with the standard "update" command in your use
> > cases? Are you saying the standard update command ignores the "-r"
> > setting in the externals definitions? In what commands, exactly, and
> > what version of svn?
> >
> > - Julian
> >
> >
> >>> I assume that this is not a server but a pure client feature(?).
> >
> >
>
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Roman <mu...@gmx.net>.
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.
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?
I can not tell now which version of tortoise and PuskOk it was since I
am at home now. I can tell you tomorrow from work. But since we did not
test with the native svn client they might not be of too much interest
any way. I can verify tomorrow with the command line client.
The behaviour is not exactly wrong. But it is too easy to update and
ending up with the head when you expect it to be pinned and possibly not
recognising it. We would like to have the option to really pin it or the
option to at least be asked if one really want to leave the pinned
revision. Furthermore would it be nice to update to the pinned revisions
in the externals without having to checkout everything from scratch.
But there is the --ignore-externals switch. Would that only ignore the
non-pinned since the pinned should be ignore anyway?
What is the behaviour you would expect? Or where can I read it.
I just found the following at the bottom of chapter:
-------------------- Externals Definitions" in
http://svnbook.red-bean.com/nightly/en/svn-book.htm
-------------------------
Warning
External working copies are still completely self-sufficient working
copies. You can operate directly on them as you would any other working
copy. This can be a handy feature, allowing you to examine an external
working copy independently of any primary working copy whose
|svn:externals| property caused its instantiation. Be careful, though,
that you don't inadvertently modify your external working copy in subtle
ways that cause problems. /For example, while an externals definition
might specify that the external working copy should be held at a
particular revision number, if you run *svn update* directly on the
external working copy, Subversion will oblige, and now your external
working copy is out of sync with its declaration in the primary working
copy/. Using *svn switch* to directly switch the external working copy
(or some portion thereof) to another URL could cause similar problems if
the contents of the primary working copy are expecting particular
contents in the external content.
Besides the *svn checkout*, *svn update*, *svn switch*, and *svn export*
commands which actually manage the /disjoint/ (or disconnected)
subdirectories into which externals are checked out, the *svn status*
command also recognizes externals definitions. It displays a status code
of |X| for the disjoint external subdirectories, and then recurses into
those subdirectories to display the status of the external items
themselves. You can pass the |--ignore-externals| option to any of these
subcommands to disable externals definition processing.
-------------------- {End} Externals Definitions" in
http://svnbook.red-bean.com/nightly/en/svn-book.htm {End}
-------------------------
I feel the requests are not obsolete yet.
What do you think?
Greets
Roman
Am 05.05.2011 14:41, schrieb Julian Foad:
> Hi Roman.
>
> Branko Čibej wrote:
>> You can already pin an external to a particular version by adding a -r
>> parameter to the definition in svn:externals.
>>
>> -- Brane
>>
>> On 05.05.2011 09:42, muzungu@gmx.net wrote:
>>> 1. Feature update [--externals MODE] switch:
>>>
>>> The update command shall be extended by the following switch and modes:
>>>
>>> update [-r rev] [-N] [--externals MODE]
>>>
>>> MODE: ignore:
>>> same as [--ignore-externals] which shall be deprecated but remain for
>>> backward compatibility
>>>
>>> MODE: interactive-revisioned:
>>> externals set to a fixed revision will not automatically updated to the
>>> HEAD or the command line revision -r rev but asks per external entry: [yes]
>>> [no] [yes to all],[no to all]
>>>
>>> MODE: ignore-revisioned:
>>> externals set to a fixed revision will not get updated. Only externals
>>> working on the head (no–rNNNN entry) will be updated to the HEAD or
>>> the command line revision–r rev
>>>
>>> MODE: to-revision:
>>> updates externals to the fixed revision stated in the svn:exterals
>>> property, all others to the HEAD or the command line revison -r rev
>>>
>>> MODE: interactive-to-revision:
>>> updates externals to the fixed revision stated in the svn:exterals
>>> property, all others to the HEAD or the command line revison -r rev, but
>>> asks per external entry: [yes] [no] [yes to all],[no to all]
> [...]
>>> Motivation/Use-case:
>>> We want use the svn:externals to retrieve common resources in defined
>>> versions/revisions into various project. That the resources for the
>>> particular project keep their revision is very important. They may not
>>> change by accident. An "standard" update has easily and unwillingly
>>> happened, as also other user report in the net. If one is lucky the
>>> compilation fails and one has a indication that sonething is wrong. In the
>>> worst case everything compiles and works fine, but for a rarely used
>>> functionality under very unlikely conditions.
>>> We would like to have update modes that not simple automatically update
>>> everything to the HEAD or -r rev, but can distingush between "internals",
>>> externals and revisioned exterals and issue a waring (interactive)
> What exactly is wrong with the standard "update" command in your use
> cases? Are you saying the standard update command ignores the "-r"
> setting in the externals definitions? In what commands, exactly, and
> what version of svn?
>
> - Julian
>
>
>>> I assume that this is not a server but a pure client feature(?).
>
>
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Julian Foad <ju...@wandisco.com>.
Hi Roman.
Branko Čibej wrote:
> You can already pin an external to a particular version by adding a -r
> parameter to the definition in svn:externals.
>
> -- Brane
>
> On 05.05.2011 09:42, muzungu@gmx.net wrote:
> > 1. Feature update [--externals MODE] switch:
> >
> > The update command shall be extended by the following switch and modes:
> >
> > update [-r rev] [-N] [--externals MODE]
> >
> > MODE: ignore:
> > same as [--ignore-externals] which shall be deprecated but remain for
> > backward compatibility
> >
> > MODE: interactive-revisioned:
> > externals set to a fixed revision will not automatically updated to the
> > HEAD or the command line revision -r rev but asks per external entry: [yes]
> > [no] [yes to all],[no to all]
> >
> > MODE: ignore-revisioned:
> > externals set to a fixed revision will not get updated. Only externals
> > working on the head (no –rNNNN entry) will be updated to the HEAD or
> > the command line revision –r rev
> >
> > MODE: to-revision:
> > updates externals to the fixed revision stated in the svn:exterals
> > property, all others to the HEAD or the command line revison -r rev
> >
> > MODE: interactive-to-revision:
> > updates externals to the fixed revision stated in the svn:exterals
> > property, all others to the HEAD or the command line revison -r rev, but
> > asks per external entry: [yes] [no] [yes to all],[no to all]
[...]
> > Motivation/Use-case:
> > We want use the svn:externals to retrieve common resources in defined
> > versions/revisions into various project. That the resources for the
> > particular project keep their revision is very important. They may not
> > change by accident. An "standard" update has easily and unwillingly
> > happened, as also other user report in the net. If one is lucky the
> > compilation fails and one has a indication that sonething is wrong. In the
> > worst case everything compiles and works fine, but for a rarely used
> > functionality under very unlikely conditions.
> > We would like to have update modes that not simple automatically update
> > everything to the HEAD or -r rev, but can distingush between "internals",
> > externals and revisioned exterals and issue a waring (interactive)
What exactly is wrong with the standard "update" command in your use
cases? Are you saying the standard update command ignores the "-r"
setting in the externals definitions? In what commands, exactly, and
what version of svn?
- Julian
> > I assume that this is not a server but a pure client feature(?).
Re: Feature wish/request: [--externals MODE] switch on update
Posted by Branko Čibej <br...@e-reka.si>.
You can already pin an external to a particular version by adding a -r
parameter to the definition in svn:externals.
-- Brane
On 05.05.2011 09:42, muzungu@gmx.net wrote:
> Normal 0 false false false
>
> MicrosoftInternetExplorer4
>
>
> Hello all
>
> Reading the email
> From: Karl Fogel <kf...@collab.net>
> Subject: Please ask on the list before filing a new issue.
>
> I file my wish/request to this maillist and hope it has not already
> been discussed.
>
> Content
>
> 1. Feature update [--externals MODE] switch
>
> 2. Feature update-externals default configuration
>
> 3. Motivation/Use-case
>
> 1. Feature update [--externals MODE] switch:
>
>
>
>
> The update command shall be extended by the following switch and modes:
>
> update [-r rev] [-N] [--externals MODE]
>
>
>
>
> MODE: ignore:
> same as [--ignore-externals] which shall be deprecated but remain for
> backward compatibility
>
>
> MODE: interactive-revisioned:
> externals set to a fixed revision will not automatically updated to the
> HEAD or the command line revision -r rev but asks per external entry: [yes]
> [no] [yes to all],[no to all]
>
>
> MODE: ignore-revisioned:
> externals set to a fixed revision will not get updated. Only externals
> working on the head (no –rNNNN entry) will be updated to the HEAD or
> the command line revision –r rev
>
> MODE: to-revision:
> updates externals to the fixed revision stated in the svn:exterals
> property, all others to the HEAD or the command line revison -r rev
>
>
> MODE: interactive-to-revision:
> updates externals to the fixed revision stated in the svn:exterals
> property, all others to the HEAD or the command line revison -r rev, but
> asks per external entry: [yes] [no] [yes to all],[no to all]
>
> 2. Feature update-externals default configuration
>
> The SVN client(s) shall have a mean to set one --externals mode as
> its default e.g. in the SVN command line clients config file.
>
> update-externals-mode = MODE It shall be possible to
> overrule configuration from the file by the command line.
>
> Motivation/Use-case:
> We want use the svn:externals to retrieve common resources in defined
> versions/revisions into various project. That the resources for the
> particular project keep their revision is very important. They may not
> change by accident. An "standard" update has easily and unwillingly
> happened, as also other user report in the net. If one is lucky the
> compilation fails and one has a indication that sonething is wrong. In the
> worst case everything compiles and works fine, but for a rarely used
> functionality under very unlikely conditions.
> We would like to have update modes that not simple automatically update
> everything to the HEAD or -r rev, but can distingush between "internals",
> externals and revisioned exterals and issue a waring (interactive)
>
> I assume that this is not a server but a pure client feature(?).
>
> Kind regards
>
> Roman
>
>
>