Split revfiles?

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

> With multiple possible revfiles, one process might append to the
> original revfile, another might think that a new file needs to be
> created. I don't know that it really hurts anything, but something to
> think about.

I think by locking the index first, that problem's taken care of.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCtucA0F+nu1YWqI0RAjjeAJ0TVBeTFLzPWk5/oaZ5PAUH2bjeFwCaAhpB
9d6GHvaiAMMOAl9uI9/+KoU=
=J8pi
-----END PGP SIGNATURE-----