Karl Fogel wrote:
>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.
>
Well, yes and no; this UUID would be completely hidden to anyone outside
the repos/fs code.
>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.
>
>
But we had this discussion before, and decided that we _need_ the uuids
table in the long run. Ripping it out at this point would be sheer
folly. What we _can_ do is decide that the copy in the FS is the master,
and make sure that the on-disk copy is always in sync with the master.
That shouldn't be hard to do.
--
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 23:02:04 2003