[
https://issues.apache.org/jira/browse/SVN-4873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad closed SVN-4873.
----------------------------
Resolution: Duplicate
Duplicate of SVN-4874.
(What happened? On submit, Jira showed an error about a null project id and an
otherwise blank screen so I tried again, and again. After the third try I
checked and found three issues had been filed.)
> Avoid foreign repository merge if repository UUIDs match
> --------------------------------------------------------
>
> Key: SVN-4873
> URL: https://issues.apache.org/jira/browse/SVN-4873
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_client
> Affects Versions: 1.14.1, 1.10.7
> Reporter: Julian Foad
> Priority: Major
>
> 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)
