Daniel Shahaf wrote:
>> svn: Commit failed (details follow):
>> svn: Repository UUID '314aa19e-ec00-11dd-9c11-f1d07231084f' doesn't
>> match expected UUID '314d93e0-ec00-11dd-9ddd-77ee003c9ea6'
>>
> Doesn't look good. If these are your two UUIDs, then they are too similar
> (they are supposed to be pseudo-random); and if these aren't, then why
> does the error message display UUIDs different from the actual ones?
These UUIDs came from my demo script. It created temporary repositories
that I've since deleted, but I just ran it again and confirmed that the
UUIDs in the error message are the actual repository UUIDs. Here is the
error message from my most recent test:
svn: Repository UUID 'e40135b0-eca9-11dd-8f8c-67b736ccdd63' doesn't
match expected UUID 'e406bd5a-eca9-11dd-aa7d-c5631cc2443a'
On casual inspection, these look about as similar as the original UUIDs.
If a timestamp goes into the construction of the UUID, should some
similarity be expected for repositories created within seconds of one
another?
> The error message you see was added (in r30684) to fix an unrelated bug
> (that occurred when a repository changed its UUID but not its URL). It
> didn't intend to change the behaviour of externals.
>
> In other words, *if* the change in behaviour you see was a result of
> that change, then it was an unintentional result.
Well, all I know is that the change in behavior happened somewhere
between versions 1.4.2 and 1.5.2. I'd have to back out r30684 and
rebuild Subversion to be sure that fix was responsible. But it doesn't
seem too surprising that Subversion might get confused when it descends
into an external and notices that the external UUID doesn't match the
parent. I'm not sure why that should happen with two externals and not
with one.
--
Warren Jones
Fluke Corporation
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1060083
Received on 2009-01-27 21:11:17 CET