On Mon, Dec 23, 2019 at 8:04 AM Dr. Thomas Orgis
<thomas.orgis_at_uni-hamburg.de> wrote:
>
> Am Fri, 20 Dec 2019 19:36:36 +0100
> schrieb Stefan Sperling <stsp_at_elego.de>:
>
> > There is a work-in-progress branch for such a feature:
> > https://svn.apache.org/viewvc/subversion/branches/addremove/
> > Would you be interested in working on this?
>
> > At present it doesn't implement much more than a wrapper around
> > 'svn status' could do, mapping '!' to 'D' and '?' to 'A' status.
>
> … but safer, I presume. Would that command be called 'svn addremove'?
> Somehow I prefer some wording involving the term 'sync', meaning to
> bring the mental state of subversion back into sync with the actual
> state of the tree. But that's the bike shed's colour.
>
> Indeed, existence of such a branch is a welcomed surprise.
>
> > I intended to work on an ad-hoc rename detection feature for this
> > branch, like Git would do it. But I ran out of time.
>
> Hm. I believe git is rather smart about detecting the content in the
> files, even if bits changed, right? You were just thinking about
> finding the same file under a different name, strictly for cases where
> one file vanished and another appeared?
>
> Actually, I have doubts that adding such smarts to subversion is
> beneficial. First, you won't outsmart git on content tracking, second:
> For me, Subversion is the system that does what it is told, not more.
> No magic. When I say that I derived a file from another via 'svn copy',
> even if I replace all contents, I want that fact recorded. Any magic
> behind the scenes, any guessing of relationships, would hit me
> unexpectedly.
I haven't looked at the addremove branch yet. But I've had some
thoughts about out-of-band move/renames over the years, so just to get
them out there...
Currently:
$ mv foo bar
$ svn status
! foo
? bar
$ svn mv foo bar
svn: E155010: Path '/path/to/bar' is not a directory
You have to do the two-step dance:
$ mv bar foo
$ svn mv foo bar
TortoiseSVN has a "Repair Move" command.
The 'is not a directory' error is consistent with the behavior of the
system move command. But maybe we can do a little better. Some ideas:
(1) Add a '--repair' option to 'svn mv'. With this option, only moving
a !foo to a ?bar is possible:
$ mv foo bar
$ svn status
! foo
? bar
$ svn mv foo bar --repair
$ svn st
A + bar
> moved from foo
D foo
> moved to bar
(2) Don't add a '--repair' option, but automatically detect the !foo
?bar case and allow 'svn mv foo bar' to "repair" the move. I'm sure
this one is fraught with peril, but I mention it for completeness:
$ mv foo bar
$ svn status
! foo
? bar
$ svn mv foo bar
$ svn st
A + bar
> moved from foo
D foo
> moved to bar
(3) If someone really wants to get fancy, do either (1) or (2) and
then create a 'svn mv --automatic' with no other arguments. This
searches for all ! and ? in the wc, does git-style "similar content"
magic, and repairs the moves. But unlike git, this never runs unless
you ask for it.
$ mv foo bar
$ svn status
! foo
? bar
$ svn mv --automatic
$ svn st
A + bar
> moved from foo
D foo
> moved to bar
Note that svn_client_move7(), added in 1.8, has a 'metadata_only'
parameter: "If metadata_only is TRUE and moving a file in a working
copy, everything in the metadata is updated as if the node is moved,
but the actual disk move operation is not performed. This feature is
useful for clients that want to keep the working copy in sync while
the actual working copy is updated by some other task."
But svn_cl__move() in subversion/svn/move-cmd.c always passes FALSE
for metadata_only and there is no other invocation of
svn_client_move7() with metadata_only TRUE (at least not in trunk).
There don't appear to be any tests for metadata_only == TRUE.
Nathan
Received on 2019-12-23 16:17:14 CET