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. :-)
Cheers,
Daniel
Received on 2018-03-26 08:03:22 CEST