Julian Foad created SVN-4872:
--------------------------------
Summary: Avoid foreign repository merge if repository UUIDs match
Key: SVN-4872
URL: https://issues.apache.org/jira/browse/SVN-4872
Project: Subversion
Issue Type: Bug
Components: libsvn_client
Affects Versions: 1.14.1, 1.10.7
Reporter: Julian Foad
SUMMARY
Subversion 1.14.1 and 1.10.7 determines a "foreign repository" case whenever
the source and target repository root URLs differ.
In some cases, different URLs legitimately point to the "same" repository,
whether that is the same resource or a different instance that behaves as
equivalent for the given purposes. Covering either case, 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, this
silently produces unexpected behaviour of the merge, for example turning copies
into plain adds. Getting a different result than expected 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.
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).
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)
