feature request: replicate stripping of revisions

Georg-W. Koltermann gwk.rko at googlemail.com
Sat Dec 15 00:37:54 UTC 2007


Sounds interesting but what about usages in other repositories?  As far
as I know strip will throw away all children, grandchildren etc..  So
what if the revision I'm stripping is being used by further children in
other repositories that I don't know of.  Then later when I push my
stripping, will the unknown children in the other repositories be
discarded?  Seems surprising and dangerous to me.

Maybe the stripping propagation should only proceed if any children that
exist (recursively) also have an odd action count?

--
Regards,
Georg.

Am Freitag, den 14.12.2007, 13:17 -0500 schrieb Jesse Glick:
> Georg wrote:
> > [...] We can hide away the revs that we don't want to see any longer.
> > They are still there, nothing is lost if anyone has used them. They
> > just don't show (maybe unless a special flag is given to the hg
> > command line). [...]
> > 
> > The information which revs should be hidden can be pushed and pulled
> > similar to how we push and pull tags. It is completely 
> > non-destructive.
> 
> This seems like a good idea, though it does not address two issues: 
> removal of problematic content (e.g. blatant copyright violations), and 
> control of repository size bloat. A different idea, which I think is 
> closer to your original suggestion but safer and more automated:
> 
> Create on demand a file
> 
> ---%<--- .hg/store/stripped
> ab3679......dd7 1
> 788ccf......b30 2
> ....
> ---%<---
> 
> which would be copied-on-write as usual during a clone. Each line is a 
> changeset hash followed by an action count. Changesets not listed are 
> treated as implicitly listed with a count of zero.
> 
> When asked to strip a revision, verify that its count is even, then 
> increment the count (in most cases adding an entry to the file with a 
> count of 1), and physically delete its storage.
> 
> When pushing or pulling to another repository, check for any changesets 
> whose count in the source repo is greater than the count in the target 
> repo. In such a case, update the target repo's count to match, and if 
> the new count is odd, physically delete its storage unless an option 
> --archive is given to the command (or perhaps this should be a config 
> flag in the target repo). In other cases, do not pull in changesets 
> missing from the target repo if the (unchanged) count is odd.
> 
> Add an "unstrip" command taking a list of revisions, which can only be 
> run if their count is odd, yet the changesets are physically present. In 
> such a case, just increment the count of each changeset.
> 
> The upshot would be that you could strip an unwanted revision, which if 
> you had only ever used it locally would in effect permanently delete it, 
> leaving just an "orphaned" hash behind. You could even strip a publicly 
> available revision and push that deletion to other peers - a sort of 
> cooperative genie bottling brigade. But any peer could pull in archival 
> mode, which would record the fact that the revision is supposed to be 
> stripped but really keep it. If that cautious peer (with a big hard 
> disk) decided later that the stripping was a mistake and the revision 
> had real historical value, it could be undone (and the resurrected 
> revisions pushed back out to the public), that being a count of 2. It 
> would be possible to redelete revisions with a count of 3, ad nauseam.
> 




More information about the Mercurial mailing list