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

Glenn A. Thompson wrote:

>>
>>
>> The on-disk slave copy isn't so awful, I guess, as long as it is
>> clearly marked as not the master. It ain't pretty, but as long as
>> there are automated protections against its getting out of date (plus
>> maybe a comment right in the file, explaining that it is not the
>> master), it's not so bad.
>>
>>
>>
> Ok, someone beat with the clue stick
>
>
> int DB_ENV->open(DB_ENV *, char *db_home, u_int32_t flags, int
> mode);
>
> This is the call in question. Why do me map Subversion ids onto
> this. The DB has to open something at db_home. How is that not
> unique enough to be the key?

db_home is the path to the BDB environment, and that's not a good unique
key.

> There is another issue at play here right?

ln, ln -s, mount --loopback, etc. etc. In general, neither the path to a
file, nor it's (devnum, inode) pair can be considered unique keys.

> Please, please clue me in.
>
> Programmatically speaking, if any BDB knowledge rises above the FS
> API. Let me go on record as being against it.

Yes, you've gone on record about that often. :-) And no, hopefully this
BDB knowledge would not poke its ugly head out of the BDB back-end layer.

-- 
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