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, muzu...@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(?). >> >
