[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: Branko Čibej <brane_at_apache.org>
Date: Tue, 27 Mar 2018 13:08:01 +0200

On 26.03.2018 00:32, Johan Corveleyn wrote:
> Interesting stuff ...
> On Sat, Mar 24, 2018 at 8:38 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
>> C. Michael Pilato wrote on Fri, Mar 23, 2018 at 08:46:16 -0400:
>>> On 03/23/2018 02:04 AM, Daniel Shahaf wrote:
>>>> Julian Foad wrote on Thu, 22 Mar 2018 22:24 +0000:
>>>>> This question keeps coming up and I feel we should provide an accurate
>>>>> answer, even if the procedure is not "supported".
>>>>> Any corrections to my current best effort, below?
>>>> As a first step:
>>>> Check $REPOS/format, $REPOS/db/fs-type, $REPOS/db/format.
>>> [...]
>>> Sure sounds like you guys are well on your way to implementing 'svnadmin
>>> rollback', a specific subset of what a "perfect" obliterate feature
>>> would offer that also probably meets 75% of admin users' needs. Just
>>> sayin'...
>> How would 'svnadmin rollback' handle the "restart all reader processes" step?
>> I'm concerned that users (admins) won't downdate all wc's ...
> 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".

The solution to that has been known a long time: you have to invent
another number besides the revision ID — call it "data generation ID" —
that gets changed every time anything externally visible happens to the
repository data that isn't also tracked by a change in the revision ID.
Such would include:

  * revprop changes
  * any kind of obliterate-ish operation

The client would have to tell the server the generation ID(s) when it
describes the working copy, and the server would then have to have a way
to force the client to perform the equivalent of a full checkout instead
of just an update.

-- Brane
Received on 2018-03-27 13:08:08 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.