[9fans] /n/dump and CVS/SCCS/etc.

[9fans] /n/dump and CVS/SCCS/etc.

[anothy]

rob's point is (as usual) dead on: these two tools cover different
problem spaces. the CVS type tools make no attempt at things
like backing up old mailboxes - nor should they. they're
designed to do a very specific set of tasks: source code control.
/n/dump, by contrast, is designed as a more general-purpose
archive. this cover many of the needs of source code control,
but not all, and many things outside that problem domain.
consider the following example:

i used to work on a project developing a messaging service using
Plan 9 (well, Inferno mainly, but running on Plan 9). we used the
dumps to provide a stable running version of the service while we
continued working on the same tree. basically, we defined an
environment variable "dumpdate", and did various things like:
	bind /n/dump/$dumpdate/dis /dis
and ran our service. it eliminated the need to do any sort of
check-out or maintain multiple trees. all we had to do was note,
in exactly one place, when we had a stable version. and since that
went into a file, we got, for free, a history of what dates we had
considered stable. had we needed finer granularity, we could
easialy have defined $bindate, $libdate, and so on.

it has been asked if one tool can cover both problem domains. i
don't believe it completely can. what _would_ be nice - and quite
practical, i think - is a source code control tool built on top of
what /n/dump provides. proto files indexing things in history
could make short work of building releases or milestone builds. i
don't have a clear idea how best to handle changelogs and such.

so... who wants to build it? ☺
ア

Re: [9fans] /n/dump and CVS/SCCS/etc.

[Boyd Roberts]

anothy@cosym.net wrote:
> it has been asked if one tool can cover both problem domains. i
> don't believe it completely can. what _would_ be nice - and quite
> practical, i think - is a source code control tool built on top of
> what /n/dump provides. proto files indexing things in history
> could make short work of building releases or milestone builds. i
> don't have a clear idea how best to handle changelogs and such.

No, I think that's too messy.  IIRC /n/dump does not fare well when
the magnetic cache fills up, but lets assume that it does or that
bind/mount could be used to build a namespace that was copy-on-write.

By virtue of writing you would get automatic versioning.  I think some
of the ideas of Venti could be used here to detect blocks that have not
been modified which would eliminate much wastage of space.  I think the
use of a cryptographic checksum on the block plus the fact that magnetic
disks are now cheaper than optical are two core ideas from Venti.

I'd manage releases by having a file that built a namespace that grabbed
the pieces that you needed.  The file in turn would be versioned by virtue
of /n/dump.

Perhaps another way to do it is with a thing like ramfs;  a caching
file-server that can be directed by a control message to commit the
current state of its world as version n + 1 (not that I'm advocating
VMS style version numbers).  Some mechanism for finer grained access
would be needed.

A simple solution would to extend /n/dump so that it was granular at
the minute or second level and have this stuff faked to pick the oldest
version, should the precise version not exist.  It may not exist in
reality, but at that moment in time the previous version was that
version.

The whole point of /n/dump is that it's a file-system, has no magic
files and all the usual tools work on it.  Departure from this model
would be a mistake.

I've been fighting with CVS a lot here while doing file-server style
work, so this stuff has been on my mind a lot.  The only thing CVS
does well is raise my blood pressure.

Re: [9fans] /n/dump and CVS/SCCS/etc.

[Boyd Roberts]

brucee had this cool limbo fs on his lapdog called dufus,
deep-undo filesystem.

That may be interesting.