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

Re: svn commit: r34588 - trunk/subversion/libsvn_fs_fs

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 8 Dec 2008 09:59:30 -0800

Well, txns do already have a next-ids file with temporary node and
copy ids. You could use that. I think it would have the right
properties.

--dave

On Mon, Dec 8, 2008 at 6:44 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> David Glasser wrote:
>> OK, sure, so this prevents "two files with the same brand-new
>> contents", but does this really prevent "two files with the same
>> contents, which already existed in a previous revision"? ie, both
>> files have the same rep as a *previously-cached* third rep.
>
> Oh, good point. So we need some kind of intra-txn uniquifier as well. You had
> mentioned a 'next-id' file in the txn directory, but I'm wondering if we can't
> just use a in-memory counter of some kind, perhaps something. The counter
> doesn't need to be per-transaction, so we could through it in
> fs_fs_sharded_data_t, but that would require protecting it with a mutex. Still
> better than the I/O to go update a file on disk, I'd think.
>
> But this is where my knowledge of the FSFS internals gets a bit rusty. Any
> suggestions?
>
> -Hyrum
>
>

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981209
Received on 2008-12-08 19:33:04 CET

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.