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