[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5361 - trunk/subversion/mod_dav_svn

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-03-17 21:40:03 CET

Karl Fogel wrote:

>Branko Čibej <brane@xbc.nu> writes:
>
>
>>Risking a serious mauling, I'd like to revisit the idea of putting the
>>UUID into a file in the repo after all. The reason is issue 688. The
>>only reasonable solution I see for that issue is for the filesystem
>>layer to maintain a per-process table of open databases. One way to do
>>that is to remember the path to the repository, but in the presence of
>>hard and soft links and mount points, that's not foolproof. The other,
>>and IMHO easier and safer way, is to remember the UUID of the opened
>>repository.
>>
>>Now to do that, the server must be able to retrieve the UUID without
>>opening the FS. So I suggest we put the UUID in a file *in addition* to
>>its being stored in a table. There'd be some work involved in
>>maintaining that value (e.g., "svnadmin create" and "svnadmin load"
>>would have to copy it out of the table in the FS), but I think that's
>>not too hard.
>>
>>Thoughts?
>>
>>
>
>One or the other, but please not both. The same value stored in two
>places is just asking to get out of sync, no?
>
>

Yes, although we could make sure they don't. On the other hand, the UUID
in the file doesn't have to be the same as the UUID in the table -- it
would only be used to identify the repository to the svn_repos_open
function. Come to think of it, the two are entirely unrelated, duh.

Forget it then -- when I start fixing issue 688, I'll probably just
stuff any old UUID in there beside the format file.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 17 21:43:13 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.