[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: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-03-17 22:11:56 CET

cmpilato@collab.net writes:
> Right. One is the UUID of the underlying filesystem, one the UUID of
> the repository which houses that filesystem. I think this distinction
> is a good one, for what it's worth.

Hold up a sec:

I really don't think this distinction is useful. To a user of the
repository, the fact that there are internal layers to the repository
implemention should be emphasized as little as possible.

Having two UUIDs is bound to cause confusion. (We already get this a
little bit with BDB transactions vs Subversion txns, but at least
those two really do serve two distinct purposes.) Worse, it doesn't
have anything to do with the real problem here.

For Brane's change, the *fs* UUID is, in fact, the one he wants. He's
trying to protect against opening the same Berkeley DB twice. Sure,
he could achieve this by checking a repos UUID that is separate from
the fs UUID, but then there's already semantic bleed going on --
because the underlying technical issue isn't whether the same repos
got opened twice, but whether the same fs got opened twice. It just
happens that, in order to _get_ the UUID, he currently has to open
BDB, which is causing a chicken-and-egg problem. Solution? Make it
so he doesn't have to open BDB, and the problem goes away. Splitting
the repository into two UUIDs creates a semantic fissure that has
nothing to do with this problem or our long-term needs.

I have no objection to the UUID being moved out of a table and into a
file, but having two UUIDs, when our real need is for exactly one, is
a major lose. Call me -0.5, leaning toward -1 but wanting to hear
more discussion first.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 17 22:50:37 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.