[ https://issues.apache.org/jira/browse/SVN-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Foad closed SVN-4872. ---------------------------- 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-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 > 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)