Split revfiles?

[Martin Pool]

On 20 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> John Arbash Meinel wrote:
> > You could also keep the rev-file in the index, but I'm guessing that
> > wouldn't work really well at keeping the index file chunks small and
> > fixed in size.
> > I suppose you could use either a sequential number (32-bit = 4byte), or
> > something like a UUID (16-bytes). And then the associated revfile would be:
> > index-filename.rev.0
> > or
> > index-filename.rev.uuidid-uuid-uuid-uuid-uuiduuid
> 
> Yes, storing the revfile sequence number in the revfile index was what I
> had in mind.

That sounds good.

> > The tricky part as I see it, is figuring out what file to append to,
> > when you are adding a new revision. Right now, you need to lock the
> > revfile, append to it, fsync it, unlock revfile, lock index file, append
> > to it, fsync, unlock, fill out inventory, close, fill out revision,
> > close, atomic append to revision_history.
> 
> Here's how I'd handle the locking:
> lock-index, lock-revfile, write revfile, write index, unlock revfile,
> unlock index.

I'm not sure it's necessary to lock the revfile at all is it?  Why not
guard the whole thing by locking the index?

One possible reason is that we might have the text file hardlinked
between two directories, but the index file is not.  Frankly that's a
bit scary and such scenarios seem to lead to unavoidable corruption.
We might try to detect them by insisting the link count be the same.

-- 
Martin