On Fri, 29 Mar 2019, Johan Corveleyn wrote:
> On Fri, Mar 29, 2019 at 7:25 PM <lists_at_m8y.org> wrote:
> ...
>> Now, when I run into an hg feature that I particularly find useful, I ask #svn if there's an equivalent for use at work.
>> In this case it was hg censor which allows easy removal of a change from the history.
>> Intended for fixing issues with licensing or accidentally uploaded keys or passwords.
>>
>> I asked what svn had along those lines and following conversation ensued:
>> https://m8y.org/chats/svn_obliterate.xhtml
>> ^^^ Link to IRC chatlog of mostly danielsh explaining complexities with amending history in svn ^^^
>>
>> danielsh suggested I move this to the list. So I did.
>> Is he right in that it might be easier to implement with this new filesystem? Are there still gotchas due to svn's design?
>
> Hi Nemo, thanks for bringing this to the list :-).
>
> I can't comment on the feasibility of implementing this in the
> filesystem, and whether FSFS f7 (with logical addressing enabled -- it
> is the default for f7, but is optional) makes it easier than f6.
> Perhaps Stefan Fuhrman, who wrote most of the FSFS7 code, can share
> some insight ...
>
> However, at the Aachen 2017 hackathon we ended up discussing
> obliterate a bit [1] ("What hackathon is complete without a discussion
> of obliterate?"). We focused on another hairy part of the problem:
> what (should) happen(s) with existing working copies? How should
> clients handle the rewritten history?
>
> Some options:
> (-1) Client doesn't notice the history change. Existing working
> copies may or may not break at any time, in unpredictable ways.
>
> (0) Client detects the changed history, and errors out with: "your
> working copy has become unusable, check out a new one". This is
> already possible today, by changing the UUID of the repository.
>
> (1) Only working copies which are affected by the history change get
> invalidated.
>
> (2) Working copies which are affected automatically adjust / rebase
> / remove the obliterated content.
>
> See also this thread from last year [2] where some ideas were bounced
> around (including a bit about "what should clients do with existing
> working copies?" [3])
Eh, I don't feel it's a hijack, I'm curious if it's technically feasible, but
it's good to know people are actually thinking about implementation issues.
FWIW, I tried mercurial DVCS' censor and it worked pretty much as I expected.
That is, there's no attempt to alter the history of remote clones (good IMO).
So, if you cloned prior to the censor, you get the unmodified copy. Further updates do not change this.
If you clone after the censor you get the modified copy.
I don't know how well this maps to SVN's centralised approach, but treating the working copy similarly makes sense to me...
Possibly related, what happens to working copies now, if I use svndumpfilter or authz to hide/remove a file from the repository?
>
> Anyway, I didn't want to hijack this thread, feel free to ignore this
> and focus on the filesystem-rewrite issue.
>
> [1] https://cwiki.apache.org/confluence/display/SVN/Aachen2017#Aachen2017-Obliterate
> [2] https://svn.haxx.se/dev/archive-2018-03/0155.shtml (Script to
> obliterate the most recent revision(s))
> [3] https://svn.haxx.se/dev/archive-2018-03/0171.shtml
--
----------------------------------------
Free Mickey!
http://randomfoo.net/oscon/2002/lessig/
http://www.law.duke.edu/cspd/comics/zoomcomic.html
My key: https://m8y.org/keys.html
Received on 2019-04-01 16:03:53 CEST