Julian Foad created SVN-4874:
--------------------------------
Summary: Avoid foreign repository merge if repository UUIDs match
Key: SVN-4874
URL: https://issues.apache.org/jira/browse/SVN-4874
Project: Subversion
Issue Type: Improvement
Components: libsvn_client
Affects Versions: 1.14.1, 1.10.7
Reporter: Julian Foad
Assignee: Julian Foad
SUMMARY
Subversion determines a "foreign repository merge" case whenever the source and
target repository root URLs differ.
Different repository root URLs legitimately can point to the same repository in
some cases, and in other cases can point to mirrored or replicated repository
instances that behave as equivalent for the given purposes. In any of these
cases let's call these "equivalent" repositories.
It has been observed in practice, and seems likely in other cases, that a user
will sometimes use a different URL for an equivalent repository
unintentionally, or unaware that it makes a difference. In these cases, if
Subversion considers this a foreign repository merge, this silently produces
unexpected behaviour of the merge, for example turning copies into plain adds.
Unexpected behaviour can be harmful.
We propose to resolve this problem by making Subversion raise an error if the
repository root URLs differ but their UUIDs match. This seems the best
solution, considering the pros and cons and the history of the current
behaviour.
A fuller description follows.
FOREIGN REPOSITORY OR EQUIVALENT REPOSITORY
There are two scenarios where repository root URLs may legitimately differ
while pointing to an equivalent repository:
* different URLs pointing to the same resource, e.g. "http:" and "https:"
variants
* replicated/mirrored repositories
(Throughout this text, in talking about whether URLs differ we are always
talking about the repository root URL, ignoring the path-within-repository at
the end of the URL.)
In the first case, different URLs point to the same repository instance and so
the repository UUIDs are necessarily identical. In the second case, the URLs
point to different repository instances that are assumed to logically
equivalent and interchangeable, at least for the purpose at hand of reading the
merge source diff from them. Their repository UUIDs should be identical.
(As well as the repository UUID, it should be noted that each repository may
also have a per-instance UUID. Very old repository versions didn't have these.
The per-instance UUIDs should differ between equivalent instances of a
repository. In the context of merging these per-instance UUIDs are not
examined, and are not relevant to the discussion.)
Subversion determines whether the merge source is a "foreign" repository
relative to the target WC's repository, according to checks that have in past
versions been based on URL and/or UUID comparisons. (See HISTORY.)
A merge behaves differently if Subversion considers the source is a "foreign"
repository: at least merge tracking is disabled and "copy" operations in the
source are turned into plain "add" operations in the target.
RATIONALE
In a scenario where different URLs point to an equivalent repository, a user
might check out a working copy using one URL and then give a different
repository root URL in the merge source. There is no single "correct" URL to
represent the single logical repository in these scenarios, so it is not
reasonable to put the responsibility on the user always to be consistent or
else face silently unexpected behaviour.
Therefore we do not want Subversion to choose "foreign repository" merge
behaviour when the merge source and target URLs differ but UUIDs match.
We could resolve this problem by making Subversion consider the merge source
and target repositories as being equivalent if their URLs differ and UUIDs
match. This was the case in Subversion 1.6 and 1.7 (see HISTORY section).
However, changing this again now would itself be a silent behaviour change.
Any users intentionally or unintentionally relying on the current behaviour
would be affected.
This scenario of giving a different URL for an equivalent repository is
expected to be a rare case. There is no known good reason for it to be
supported, since it should always be feasible for the user to use a source
repository root URL that matches that of the target WC.
Instead, we propose Subversion raise an error if the repository root URLs
differ but their UUIDs match.
Advantages of erroring out in this case:
* prevents the bad behaviour
* does not introduce a silent behavioural change
* still allows usual same-repository merge cases (same URL)
* still allows usual foreign-repository merge cases (different URL, different
UUID)
Possible down-sides are addressed in their own section, POSSIBLE DOWN-SIDES.
TWO-URL MERGE SOURCE URLs
In the "two-URL" form of merge, two source URLs are given. Subversion (since
1.6.2) checks the UUIDs of the repositories accessed by these to determine
whether they point to the same repository, and errors out if they do not.
This proposal does not seek to change this behaviour.
HISTORY
The history of checking for "foreign repository" merge (source repository is
not the target repository) in any merge.
Since Subversion 1.0.0: URL comparison.
Since Subversion 1.6.0: UUID comparison ( [https://svn.apache.org/r875700] ,
2009-02-02).
Since Subversion 1.8.0: URL comparison (UUID comparison accidentally broken by
[https://svn.apache.org/r1199840] , 2011-11-09).
In carefully reviewing the history of the existing checks, I was embarrassed to
discover I broke the previously intended behaviour in r1199840, in the lead-up
to 1.8.0. It has remained that way since. There are no regression tests
involving unequal URLs pointing to equivalent repositories, as far as I can see.
The history of checking that the two source URLs in a two-URL merge point to
the same repository (given for context; no change is proposed):
Since Subversion 1.0.0: no explicit check for the two source URLs in 2-URL
merge (and possible wrong behaviour if pointing to different repositories).
Since Subversion 1.6.2: UUID comparison used for the two source URLs in 2-URL
merge ( [https://svn.apache.org/r877593] ); error out if the UUIDs differ.
POSSIBLE DOWN-SIDES
Possible down-sides with this proposed change in certain cases include:
* Case: equivalent repositories; the given source repository URL is faster to
access than the repository associated with the target WC.
** The user will be unable to use the faster source URL for the merge, without
a work-around.
** Work-around: first "svn relocate" the WC URL to match the desired URL, then
merge with this source URL, then relocate the WC back again if desired.
* Case: equivalent repositories; the given source URL is accessible and the
URL associated with the target WC is (for the time being) not accessible.
** The user will be unable to perform the merge without a work-around.
** The "relocate" work-around can be used.
* Case: user expects a foreign-repository merge, but the other repository
erroneously has the same UUID.
** This UUID misconfiguration can reasonably be expected to occur in real
life. For example, if an administrator creates a new repository by copying an
empty repository instead of "svnadmin create".
** After the proposed change, the attempted foreign-repository merge would
error out, where before it would have proceeded.
** As foreign repository merges are not well supported in Subversion, they are
relatively uncommon, and so the combination with UUID misconfiguration is
expected to be rare. If the error message is clear and is seen by the user,
this should alert them to the misconfiguration. An admin would need to fix it.
* Case: user attempts a merge using a different source URL of an equivalent
repository that erroneously has a different UUID:
** This UUID misconfiguration can reasonably be expected to occur in real life.
** Both before and after the proposed change, the attempted merge would be
treated as a foreign repository merge.
** This case is unaffected by the proposal.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
