[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: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 26 Mar 2018 01:00:26 +0200

On Mon, Mar 26, 2018 at 12:53 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>
>>> 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".
>>
>> 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?
>>
>> Can it be done with current svn features?
>
> Assuming a repository admin is concerned about this, wouldn't they just use svnadmin setuuid to give the repository a new UUID? Technically that is what that is for and would immediately accomplish this goal.
>

Yes, but that breaks *all* working copies, whether they are affected
by the changed history or not. What would be vastly better, I think,
would be that only "working copies containing traces of the changed
history" would be broken. Thus salvaging "working copies with only
non-affected subtrees" and "working copies at an older working
revision".

Especially in the case where you're obliterating the most recent
revision(s) only, that could be a big deal.

-- 
Johan
Received on 2018-03-26 01:00:56 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.