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_at_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(?).
> >
> >
>
Received on 2011-05-06 11:07:17 CEST