Re: [Gnu-arch-users] Re: tla import versus tla commit

[Thomas Lord]

    > Cameron Patrick wrote:

    > > > Creating a new directory and sticking some contents in it mean that
    > > > there's no possibility of reusing the name in the future.

    > > Only if someone else catches you :-) Otherwise rm -rf'ing it and
    > > removing any left-overs from the revision library works pretty well
    > > (even if changing history isn't officially encouraged).

    > There is a difference between changing history and undoing a mistake.
    > Arch archives are not autonomously collected chronologies.  They grow
    > at user initiated points.  Thus an undo is somewhat meaningful.  That
    > being said it would seem to entail significant issues with caching,
    > mirroring, etc.


I think that is an insightful description of why undo is meaningful.

As a practical matter, I think we can support it handsomely, albeit 
with a "timeout" limitation -- operations can be undone only up to 
some specific (and usually not *that* far away) future point in time.

For a single user, with an almost entirely "local" environment,
implementing undo (even of commits) is quite practical, although a tad
tedious.   Arch needs to keep a more detailed track of the revision
libraries it knows about, the mirrors, the timing of mirror updates,
and the location of project trees.   Matthew Dempsky has recently
started working on this problem, although his time is very limited (he
is a student) and so no particular rate of progress can be promised.

With that information, one can construct a distinction between
private, hour-to-hour working archives, purely local to a client, and
those archives which are shared in open-ended, unspecifiable ways.
Within the purely private archives, with enhancements to the database
in ~/.arch-params, undo is fairly trivial to implement (kill all
cached versions of undone revisions, undo the corresponding patch log
changes in project trees).

The net effect will be to give end-users a private sandbox in which
undo works perfectly well and from which, with a "push of a button",
they periodically set an un-undoable boundary while simultaneously
publishing from their private sandbox to the shared environment.

For extra points, we can leverage the revision locking mechanism so
that a particular sandbox can reliably "queue up" a bunch of changes
to it's shared doppleganger with some degree of confidence that when
the sandbox is finally published (after any series of undos/retrys) it
is assured those changes will migrate to the shared environment
cleanly.

-t