Jörg Rebenstorf wrote:
> On 08/26/2015 03:36 PM, Julian Foad wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2516
>> 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)?
No, I am not saying it is not possible. I am saying that the only way
to convert a revnum in the parent repository to a matching revnum in
an external repository is first to convert it to a date and then ask
the external repository to convert that date to a revnum.
Thus the procedure looks like this (pseudo-code):
update_recursively(PARENT_URL, REV):
svn up $PARENT_URL -r $REV
DATE = `svn propget svn:date $PARENT_URL@$REV`
for EXTERNAL_URL in find_non_pegged_externals():
svn up -r{$DATE} $EXTERNAL_URL
Whenever we pass a date in the svn UI, or in an API, Subversion will
always convert it back to a revnum before using it. It does this by a
binary search of the svn:date properties.
So whether we talk about converting to a date or converting to a
foreign-repository revnum, it means the same thing, because Subversion
always converts a date to a revnum before using it.
My concern is that converting a date to a revnum isn't well defined if
the svn:date properties are not completely ordered. However, in most
repositories they probably are completely ordered. This concern is not
specific to this issue of updating externals. So that is just an edge
case we will have to accept. As far as I know, there is no other way
to do it.
> 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.
No, we can just do the conversion. The conversion is not that
dangerous -- see above.
> 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.
So I think (if we have been using a revnum for the parent WC) we
should check the UUID and convert to a date if the UUID is different.
>> 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.
I agree.
>> 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.
OK, we agree.
>> 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.
OK, good.
Thank you.
Do you have any interest in implementing this feature, or do you know
of anyone who could do so? We would help, of course. Writing a test
case, marking it as XFail ("expected fail"), would be one good way to
start. (Even if not, it is still useful to discuss and define how the
feature should or could work, so that it will be easier for someone to
start working on it later.)
- Julian
Received on 2015-08-27 10:58:52 CEST