Re: [Gnu-arch-users] Re: Making --setup default in tag and import

[Tom Lord]

In your list of solutions you omitted the one that I think is probably
cleanest: extending the namespace.   For example, right now we can have
a revision called:

        patch-1

as a strawman to illustrate the idea, an archive might be allowed to contain:

        patch-1.del

which means that the `patch-1' commit is considered officially retracted.
A tree based on `patch-1' or any any descendent revision can be detected
as out-of-date.    A name like:

        patch-1.2

might be the name for a second revision, logically taking the `patch-1'
slot, replacing the orignal `patch-1'.

Such a scheme would retain the notion that an arch version is a single-threaded
development line but would add the notion that that development line 
can backtrack and try again if problems arise.

The sorts of ideas that you mention (permit archive edits for "an hour"
or "until the next mirroring operation" etc.) are already there in the
form of quasi-official "cheat" tactics.

The reason they are so-far kept at the level of "cheating" is because
it would add a lot of expense and bookkeeping and create some problems
regarding who has write access to what to implement them robustly, in
the general case.  Those costs would negatively impact use cases which
don't need or want this capability -- an important class of use cases,
I think.

For an important class of users, though -- I'm thinking especially of 
individual hackers working with their private, occaisionally mirrored
archives -- the cheats are very desirable.

/And/, in that scenario, the dreaded extra bookkeeping that I'm talking
about would not be excessive.

All of this is to say that I would be interested in changes which successfuly
build-in and sanction a limited form of archive-changing "cheating" provided
that it is an optional capability which user's must explicitly request 
(perhaps at archive creation time?  or perhaps it can be toggled by tweaking
something in `=meta-info')?

It would be a mistake, on the other hand, to try to make a rule like 
"retractions permitted up to one hour later" a universal property of 
Arch archives.

In implementing an acceptable form of a built-in retraction capability,
it might be beneficial to think about what *other* uses the required 
bookkeeping capabilities might have (I'm pretty sure there are some good 
ones) and to keep those other uses in mind when designing a solution.
To not do so risks bloat.

Incidentally, as always, be careful what assumptions you make about how
timestamps can be used.   (I almost added "in a distributed system" but,
really, distribution just makes the already present problems even worse.)

-t


   From: Mikhael Goikhman <address@hidden>

   > Actually, it *is* fundamentally impossible.  The arch model is that each 
   > revision name corresponds with one and only one changeset or import. 
   > Forever and ever.  Break that rule, and you get to keep both pieces.

   These two requirements do not really conflict in any fundamental way.
   You may redo the past if you also redo or remove all its dependencies.
   There are several solutions here with a different set of consequences.

   One naive (and inconvenient) solution is to only allow getting revision
   in one hour from its creation and give time to the creator to replace it.

   A better solution is to use timestamps of archive revisions and invalidate
   any trees or secondary branches that depend on the revisions with older
   timestamps. Note, that invalidation is what a user intends when he undoes.
   He does not intend for the previous (replaced) changeset to be ever valid.

   One easier-to-implement solution (the one I suggested) is to only make
   cache and mirror processes aware of the archive changes by revalidating
   stored data, either on request or just all recently created data, and not
   to perform any automatical invalidation. The user is then responsible to
   invalidate (remove) any affected trees or revisions if any. If he worries
   about external trees or branches, then he should not undo in the archive.

   Regards,
   Mikhael.