Re: [9fans] fossil woe

[rog@vitanuova.com]

> Fossil needs some notion of being close to full, at which point
> its behavior would change.  Automatic snapshots would stop,
> as would mtime updates and any other source of automatic
> dirtying of blocks.  There should be a few blocks reserved for
> snapshots taken in response to manual console commands.
> Then when fossil fills, you can remove recently written data
> (if some runaway program has filled the disk) or connect to
> the console and delete old snapshots or take an archival
> snapshot.

this seems fine, but... it still seems somewhat arduous when all
one really wants to do is copy a load of data to venti.

one idea:

why not make it possible to directly insert vac archives into
a fossil filesystem?

e.g. with a new fossilcons command:

	createvac path score uid gid perm

fossil could remap the (possibly spurious) usernames in the
vac archive, for instance by mapping all user and group ids to
the given uid and gid.

then a large quantity of new data could be "vac"ed directly
onto venti, and then made available within fossil.

in combination with the "vac" console command, this could make
other previously hard things straightforward; for example replicating
or moving huge directories from place to place without
copying all the data.

would this be very hard within the current fossil structure?