"Dale Worley" <dworley@pingtel.com> writes:
> There appears to be a problem with "svn merge", namely that if it
> decides that a file needs to be added to the WC, it will "svn copy"
> the file from the other leg of the merge. This is the Right Thing in
> most cases, but if the other leg is from a different repository than
> the WC, it leaves the WC with a file that has been copied from another
> repository, and the WC cannot be committed.
>
> (This sequence of operations is not unusual when one is transporting a
> release of software from one organization's repository to a vendor
> branch in another organization's repository.)
I had thought we had an issue for this, but I can't seem to find it.
Does it still reproduce with the latest (trunk) client? If so, would
you be willing to file a bug report? Your description and
reproduction recipe are excellent. If you don't have time to file,
just let us know, and someone else will do it.
Thanks -- and sorry I don't have time to personally *fix* the dang bug
right now! :-)
The behavior you suggest as correct (at the end of your mail) seems
right to me, at least until issue #820 ("merge tracking") is resolved.
-Karl
> For example:
>
> # Check out an old version of a directory and import it into a
> # different repository.
> + svn checkout -q \
> -r 12944 http://svn.collab.net/repos/svn/trunk/notes/locking \
> A
> + svn import A https://example.org/rep/testproj/dworley/A
> Adding A/locking-ui.txt
> Adding A/TODO.txt
> Skipped 'A/.svn'
> Adding A/locking-implementation.txt
> Adding A/locking-functional-spec.txt
> Adding A/ra_dav_strategy.txt
>
> Committed revision 148.
>
> # Check out a WC of the test repository's copy.
> + svn checkout https://example.org/rep/testproj/dworley/A B
> A B/locking-ui.txt
> A B/TODO.txt
> A B/locking-implementation.txt
> A B/ra_dav_strategy.txt
> A B/locking-functional-spec.txt
> Checked out revision 148.
>
> # Merge changes between rev 12944 and HEAD of the original repository,
> # which include adding the file 'svn-needs-lock-impl.txt'.
> + svn merge https://svn.collab.net/repos/svn/trunk/notes/locking@12944 \
> https://svn.collab.net/repos/svn/trunk/notes/locking@HEAD \
> B
> A B/svn-needs-lock-impl.txt
>
> # "svn status" shows that the added file is copied from a repository.
> + svn status B
> A + B/svn-needs-lock-impl.txt
>
> # Attempting to commit the WC fails.
> + svn commit B
> Waiting for Emacs...Done
> Adding B/svn-needs-lock-impl.txt
> svn: Commit failed (details follow):
> svn: PROPFIND request failed on
> '/repos/svn/trunk/notes/locking/svn-needs-lock-impl.txt'
> svn: PROPFIND of '/repos/svn/trunk/notes/locking/svn-needs-lock-impl.txt':
> 405 Method Not Allowed (https://example.org)
>
> # Examining the .svn/entries file shows the copy operation:
>
> + cat B/.svn/entries
> [...]
> <entry
> name="svn-needs-lock-impl.txt"
> text-time="2005-02-15T00:23:39.000000Z"
> checksum="83f5a955b0d9411181b8f446b38e7f2f"
> copied="true"
> kind="file"
> copyfrom-rev="13018"
> schedule="add"
> prop-time="2005-02-15T00:23:39.000000Z"
> revision="0"
>
> copyfrom-url="https://svn.collab.net/repos/svn/trunk/notes/locking/svn-needs
> -lock-impl.txt"/>
> [...]
>
>
> It seems to me that the correct solution is for "svn merge" to check
> when it is copying a file from one leg of the merge to the WC to see
> whether the source and destination are in the same repository. It can
> do this straightforwardly because the repository UUIDs are in the
> .svn/entries files. If they are in the same repository, it should
> perform an "svn copy" to preserve history, and if they are not, it
> should just do an "svn add".
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 15 17:41:57 2005