[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:12:37 CET

mbk@tigris.org wrote:

>Author: mbk
>Date: Mon Mar 17 12:59:59 2003
>New Revision: 5361
>
>Modified:
> trunk/subversion/mod_dav_svn/update.c
>Log:
>It is with great joy that I present what will hopefully be the last
>in a series of commits related to issue 1037 (repository uuids).
>
>This one removes the sending of UUIDs as part of the update report.
>It is semantically equivalent to the change made in rev 5245 as part
>of the release of 0.19. However, this change excises the evil code
>rather than simply ifdef-ing a portion of it out.
>
>This is a reversion of a portion of rev 4916.
>
>

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?

-- 
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:15:33 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.