-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/26/2015 03:36 PM, Julian Foad wrote:
> 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?
I think that you question is an implementation issue. I have already
read in other mail threads that there are some obstacles with this.
> 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.
Right, this seems to be straight forward.
> 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.
I did not want to suggest to convert a revnum to a revdate.
Do you say that converting a revnum to a matching revnum in the
external repository is not possible by any implementation (with
reasonable effort)? If you are right, then the new option may simply
support revnum on the command line only in case of externals to the
same repository and otherwise return an error. If the command involves
externals to different repositories the user would have to use a
revdate on the command line if he wants to use this new option so that
no possibly dangerous implicit conversion from revnum to revdate does
occur during processing.
I think checking the UUID to know if the svn:externals definition
leads to the same repository is sufficient.
> 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?
See above.
> 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.
If someone will really need such a feature, that you speak about, just
add a new keyword (instead of HEAD) to be used in external
definitions. You can then define that this new keyword means that the
current head is referenced no matter if --sync-externals is given or not.
But I think that noone needs such a feature urgently as this
requirement would only derive as an additional feature to be used with
the suggested option in the future. Noone would have forcasted that a
distinction between -rHEAD and no revnum in externals would be usable
with a --sync-externals option that was not defined, so noone can use
such a distinction using the new --sync-externals option in existing
repositories.
> 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.
Yes, I think so and agree that the latter argument wins. As I said,
the new feature shall not be incompatible, that is, shall not redefine
current behavior.
> 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.
That would be fine.
Best regards,
Jörg Rebenstorf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAlXd92gACgkQcakT0GqLJ9nGFQCg5lJfQuUNSczfaqRKdQDXxwXm
030AoNdLVE44qyWRTI7VLIFsMwnONZd3
=o7KV
-----END PGP SIGNATURE-----
Received on 2015-08-26 19:29:38 CEST