On Fri, 29 Mar 2019, Johan Corveleyn wrote:
On Fri, Mar 29, 2019 at 7:25 PM <li...@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
