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])
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
--
Johan
Received on 2019-03-29 22:25:51 CET