Jörg Rebenstorf wrote:
> I have a suggestion for a solution of issue 2516 [...]
First, let me quote the summary line and URL of issue 2516, for easier
reference:
http://subversion.tigris.org/issues/show_bug.cgi?id=2516
"--revision option is not forwarded to svn:externals references"
[...]
> The new access option should update the working copy of the primary
> target "PATH..." and its externals to a certain inter-repository
> consistent state, that is, to update the primary target and all of its
> externals content to their appropriate version at a certain point in
> time.
> The new access method shall be an additional command-line option, for
> example "--sync-externals", for the svn client tool's update command
> like:
>
> svn update -r212 --sync-externals [PATH...]
> or
> svn update -r{2015-08-26} --sync-externals [PATH...]
>
> What this new option shall do is, that if an externals definition, that
> is involved in the update procedure as-is, does not specify a revision
> (or date) information then it shall use the corresponding revision
> number (or date) for updating the external so that the external
> repository matches the revision of the primary target in time, that is,
> the user will update the working copy to that specific state of the
> content what the involved repositories had stored at that point in time
> (i.e. their former HEAD revision of the past). This should work for
> linking via svn:externals inside the same repository as well as for
> externals to other repositories.
>
> I believe many users already have linked via svn:externals without a
> given revision number for that link definition. So currently these
> definitions can only be used to update to the *current* HEAD of these
> externals (as defined). But I believe many also want to use this setup
> to update via the externals to the HEAD of these linked repositories as
> they were at that certain point in time in the past, when updating the
> working copy of the repository, that includes the externals definitions,
> to a specific revision.
>
> So when an svn:externals definition states a specific revision number to
> use, than this specified revision number shall still be used no matter
> if --sync-externals is used or not, but else the new option should make
> a difference.
>
> I think my solution is better than the "-rPARENT" enhancement (suggested
> by Karl Fogel) and similar solutions because needing to specify
> something like "-rPARENT" in the externals definition implies to change
> existing repositories backward in time to use that feature for existing
> ones as these definitions are part of the repository in our situation.
>
> Best regards,
> Jörg Rebenstorf
Hello, Jörg. Thank you for this proposal. Let me summarize how I
understand your suggestion, and then ask you more about the details.
The proposal is:
'svn update' should have an optional new operating mode, enabled
by some switch (you suggest '--sync-externals'), and in this mode any
external definition that does not specify a revision shall be updated
to the same *revision* or *date* as its parent WC.
I agree, I think this is basically a good idea.
More thoughts:
How shall the implementation decide whether to use a revision number
or a date for each relevant external? If the user specifies a date for
the parent WC, then I think the only sensible option is to update the
external to this date. But if the user specifies a revision number,
then in what cases could the code update an external using this
revision number? When a client processes an external definition, it
does not necessarily know whether the target is in the same
repository. (The URL is not sufficiently unique. Maybe it can connect
to the repo and then check whether the UUID is the same.) If the
client does not know, it must send a date rather than a revnum.
Whenever we specify a date, that can lead to ambiguous operation the
commit date stamps are not strictly ordered in the repository. That is
OK normally, because users usually only specify a date in cases where
it works (where date stamps are strictly ordered). However, if this
feature would always convert a revnum to a date for updating an
external, it may run into problems.
So, do we need to check whether the external target repository has the
same UUID, and if so then don't change from a revnum to a date?
Should this new mode apply only to external definitions that do not
specify any revision, or also to those which explicitly specify
'HEAD'? An argument in favour of *not* affecting explicit 'head'
definitions is that then users can start making use of that
distinction in future. An argument in favour of also affecting
explicit 'head' definitions is that there has been no distinction
between implicit and explicit head in the past, and so there will be
repositories where some externals have it explicit and others don't,
arbitrarily, and it is better not to start making a distinction now
between forms that were considered identical in the past. I think the
latter argument wins: it should affect both explicit and implicit head
definitions.
The solution should be applied uniformly across all commands that can
read an old revision and can recurse into externals: checkout, update,
switch, export, diff (if and when it supports recursing into
externals), etc.
- Julian
Received on 2015-08-26 15:37:06 CEST