Julian Foad <julianfoad_at_apache.org>:
> Hello Eric.
>
> TL;DR: I explain why I am convinced no-op changes don't belong in the
> Subversion versioning semantics. With your work on Subversion repository
> and dump stream semantics, is this something you can offer a view on? I
> have previously failed to convince the developer community [1].
>
>
> In examining the Subversion versioned data semantics and how the protocols
> and APIs represent them, I have come across a number of kinds of what could
> be called a "no-op change" or perhaps better described as "I touched this
> but did not change its value".
>
> Example:
> - I changed the text of file F from T1 to T1;
> - now "svn log -v" tells me the text of F was "modified";
> - some variants of "svn diff" show no output;
> - some variants of "svn diff" show a diff header with no body.
Initially I had to struggle with your presentation a bit. When I
first read that, I thought you were changing the file from the text
"T1" to the text "T1;" and wondered "How is that a no-op change?" But
never mind, that was just me not being awake enough yet.
I am in favor of not shipping or recording no-op changes. They don't
have a natural representation on DVCSes, which are essentially
changeset DAGs in the way that a Subversion history is essentially a
series of file-tree surgical operations.
(The difference can be painful. The one conversion bug I have left is
around copy-delete-copy sequences on tags and branches. What to do
with the dead segment between the first tag/branch creation and the
delete turns out to be a question that does not have an obvious right
answer in changest-DAG-land.)
No-op commits are specifically awkward for the internal representation
reposurgeon uses, which has the semantics of git fast-import stream
semantics with a bit of gingerbread added - notably, per-commit properties
including a legacy-ID field which is normally used to carry Subversion
revision-IDs.
Git streams don't even want to carry around empty directories, let
alone commits with no file operations or only no-ops. Thus, when reposurgeon
encounters these, the no-op commit is preserved as an annotation tag with a
genetated name so a human operator can decide what to do about the
comment text.
Usually the disposition is to toss out the comment - I don't think
I've ever seen an exception. That makes its own statement about the
calue of keeping these things in your representation.
So yeah, Eric sez nuke 'em. It'd be simpler all around.
(BTW, reposurgeon actually treats Subversion branch copies as no-op
changes in this exact way; the first change after the new branch
creation is what's recorded, and the commit metadata of the copy
operation is shuffled off to become a junk tag.)
--
Eric S. Raymond
Received on 2019-10-12 11:57:42 CEST