On Dec 6, 2005, at 11:07 AM, Garrett Rooney wrote:
> The original person who found this problem here had it in an existing
> working copy, but with trunk you can also get into this situation via
> switch on a newly checked out working copy.
"The original person" clarifies:
The problem was originally observed in a WC with history essentially
like this:
1. Using SVN 1.2.1, "svn co https://original.host.com/path/to/stuff"
2. Still using SVN 1.2.1, "cd stuff/dir; svn switch https://
dnsly.equivalent.host.com/path/to/different/stuff/dir"
3. fwiw, still using SVN 1.2.1, "svn up" seems quite happy
Note that at this point, .svn/entries does not contain any
"root" entries, since they weren't invented at 1.2.1
URL entries outside of the switched directory show URLs naming
"original.host.com"; the ones inside
the switched directory tree show "dnsly.equivalent.host.com"
4. build and install trunk
5. in the "stuff" directory, "svn up"
Some stuff in "stuff" (the unswitched stuff) behaves normally,
but when first the update encounters a switched dir,
we see the problems discussed here.
When the dust settles, .svn/entries contains the "mixed url/
root" content described elsewhere
The fact that step 2 involves "path/to/different/stuff", whether or
not the host part is "dnsly.equivalent," intrigues me: it seems to me
there is no information readily available to SVN client to know that
these two hostnames are dnsly.equivalent, and in fact no information
in "different/stuff/.svn/" to suggest that "original.host.com" is in
any way involved here. As it happens, "stuff" and "different/stuff"
are contained within the same repository, so an exchange of uuid's
might get us to this point, but other than that it seems like the
"fix up .svn/entries the first time you touch it" code is making a
switch-violating assumption, that the root of .. is necessarily also
the root of .
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: +1 650.228.2562
c: +1 408.835.8090
Received on Tue Dec 6 20:54:20 2005