Re: [Gnu-arch-users] Removing the last changeset(s) from the archive

[John Meinel]

Charles Duffy wrote:
> On Sun, 2004-11-14 at 11:14 -0600, Karl O. Pinc wrote:
>
> > Arch is designed so each developer can have his own tree,
> > why not be able to correct mistakes?  I'm not asking
> > to be able to remove any patches but the latest.  If
> > there's worry about concurrency in the case of shared
> > archives there could always be an option (in the
> > archive/category/branch?) to dis-allow uncommit operations.
>
>
> If you have your own private archive and then use push-mirror to make
> your changes public, you can do this a bit more safely for changes that
> haven't been push-mirrored yet, simply by manually altering your archive
> and then killing all revision library entries, pristines, working trees,
> etc. related to the dead revision. Failing to kill everything can lead
> to archive corruption (as diffs may be made off the old version of the
> revision rather than the new one).
>
> I think the wiki discusses this.
>
>
> > As a final argument, after a cursory glance at the archive
> > data struture it seems this would be trivial to impliment.
>
>
> A not-so-trivial issue: How do you handle the cases where someone has
> already checked out / branched a version you're deleting?
>
>
>
> That said, I believe Tom has fairly recently said that he agrees that
> this kind of feature is worth having. It's not something that can be
> implemented trivially, though, for the reasons above.

IIRC, what Tom proposed is something to do all the steps it can to the 
local system. Meaning go to all revlibs and delete the revision, go to 
the archive and delete the revision, etc.

It wouldn't guarantee that you prevent things from getting corrupted, as 
 if anyone else sees your changes, you have corruption. But if you are 
careful and do it quickly, it should work.

To truly do what you want to do, we would need to add some indicator to 
the archive that this is the "true" value for this revision. There isn't 
any support for this, and adding it would probably make things ugly.

For instance, if you change your archive after I have mirrored it, you 
need some way to tell me that it has changed. In general, arch doesn't 
modify history, so my arch won't look at old patches, it just assumes 
they are correct.

There is a way that I can think of. And that is to add a file that says 
"this revision has been altered." And to keep things reasonable, we 
could only allow altering the *end* of a development line. So when arch 
connects to the tree, it first checks its last known revision to see if 
it was ever changed. If it was, it then searches the tree to find any 
other changes, and starts updating it's own information.

The idea is it should only add 1 extra lookup when it connects to the 
archive. It could probably be done with a file called "changenum" which 
just contains a number indicating which change this is. If the number is 
greater than the local number, a change has occurred, and we need to 
play fixup.

I still think it is a bad idea. Arch is founded on the "past doesn't 
change".

I'm okay with a script that will clean up an accidental local change as 
best it can, letting the user know they may have corrupted things. But I 
really don't think it should be part of the arch protocol.

I mean, do any other revctrl software let you truly change history 
(without hacking the archive itself)?

If it's just something like summary comments, etc, this could be handled 
in a different way (revision controlled comments.) But revision 
controlled revisions seem a little redundant for little gain.

John
=:->

signature.asc
Description: OpenPGP digital signature