[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Script to obliterate the most recent revision(s)

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Mon, 26 Mar 2018 06:03:12 +0000

Johan Corveleyn wrote on Mon, 26 Mar 2018 00:32 +0200:
> During the Aachen hackathon we brainstormed a bit about obliterate,
> and figured it would be wonderful if a client, acting on a working
> copy, could detect that "history has been changed". Even if only to
> give an fatal error message "your working copy is broken, please check
> out a new one".

Should the current behaviour be available as well as the behaviour you describe?

> So, how to detect that a working copy and the repository have a
> different idea of history, so we can error out loudly and clearly?

How about:

1. Repository-global change counter. Every time 'rollback' runs and
   succeeds, it increments the counter before releasing the write lock.

2. Per-revision change counter. Every time 'rollback' runs and
   succeeds, for each revision in R+1..OLD_R (in Julian's terminology),
   it increments a counter (that's initialized to 0; presumably it'd be
   stored in a sparse fashion, e.g., an svn:fsfs:* revprop that's
   present only when its value is non-zero and (following
   svn:mergeinfo's lesson) is stripped from the set of revprops
   reported to higher layers).

In either case, clients check that counter like they check the UUID.

Strictly speaking, the counter doesn't have to be strictly incrementing;
it can simply be set to a new random value each time. The security
model (what a honest-but-curious (that's a technical term) user can
learn about the the rollbacks that have taken place) is a bit different.

> Can it be done with current svn features?
> If not, what would we need? An idea that surfaced was "Merkle trees",
> or something built around it (i.e. client and server should be able to
> cheaply generate a hash representing the "tree in scope" or something
> like that). I have no more concrete ideas unfortunately ...

That's of independent interest. :-)


Received on 2018-03-26 08:03:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.