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