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_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-05 23:40:43 CEST