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

[anothy@cosym.net]

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? ☺
ア