Branko ÄŒibej <brane@xbc.nu> writes:
> Philip Martin wrote:
>
>>It just works if the URLs refer to the same repository, no need to
>>check UUIDs. However, if the URLs refer to separate repositories then
>>the the current code
>>
>> common_url = get_longest_ancestor (source_url, target_url)
>> open_ra_session (common_url)
>>
>>is going to generate common_url that does not refer to a repository,
>>that's going to cause an error, isn't it? If the error really must be
>>"improved", then perhaps the solution is to check paths in the
>>repository, rather than UUIDs.
>>
>>
> "It ain't necessarily so."
>
> It's entirely possible to have two completely different URLs refer to
> the same repository. Through symlinks in the filesystem, interesting
> Apache configuration, etc. etc. So to make sure, you have to open both
> URLs and check the UUIDs.
I don't see how that is relevant.
Lets assume the URLs "http://server/foo/" and "http://server/bar/" are
repository roots that refer to the same repository, in which case
"http://server/" is not a repository. If you attempt to copy
something from a foo URL into a bar URL the current code will attempt
to use a single session opened on /. It will fail, and checking UUIDs
won't make it work.
Now I suppose we could add UUID checks, identify that the two URLs are
the same repository, and attempt to rewrite one URL in terms of the
other. Are you suggesting we try that? I don't see that doing it
would be particularly useful.
My original argument is that for cases where the copy works there is
no need to check UUIDs, and for cases where the the UUIDs don't match
the copy will already fail. Admittedly, when we support cross
repository copies things may change, but when that happens the whole
common_url stuff will need to be rewritten.
Apart from a "neater" error message, what does the UUID check achieve?
If the improved error message is deemed to be important then perhaps
the UUID check could be done after the copy attempt has failed.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 9 22:23:09 2003