On Mon, Dec 23, 2019 at 02:03:46PM +0100, Dr. Thomas Orgis 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.
I think it makes sense to use that name since it is also used by Mercurial.
Mercurial put a lot of thought into their UI so I'm happy to use naming
they have come up with, rather than duplicating effort.
> > 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.
>
> But then, if this is a feature I explicitly ask for … 'svn
> rename-find-copies-magic', then it fits, I guess. Could even involve
> some threshold for amount of matching content, or how much value is put
> on the same file name appearing at a different place. Then it's a tool
> again, employed by the user. Was that the plan?
There was no finalized plan. This is an experimental branch.
I tend to work towards a certain goal but given limited time existing
contraints in the implementation have to be accounted for.
The simple case where file are 100% identical already works, anything
further can be discussed and evaluated. It only has to be as smart as
we can reasonably make it.
> > Regardless, if this feature branch also solved the symlink issue you
> > describe below, the branch might already be worth merging to trunk.
>
> Seems to be a simple addition, just have to add the cases of changed
> kind and treat them accordingly as removes/adds.
>
> Maybe I have some time to look at this branch and cargo-code from its
> diff to add the symlink thing. After getting that other important work
> done. Probably in the new year.
Great :) Let me know if you have any questions.
And I could rebase the branch to trunk for you if needed.
> > Technically, SVN expects tree modifications to be made with
> > Subversion commands like 'svn add', 'svn rm' etc. Modifying
> > the working copy's tree structure with external commands is
> > actually somewhat "out of spec".
>
> Sure, it is. But expecially when more people are used to the git way of
> just doing things, having a 'just figure it out' command to at least
> get the changes tracked, even if not with optimal metadata, would be
> helpful for those who forget to use 'svn mv' instead of 'mv'.
It makes no sense to "record a move" which won't be recognized as such
by the conflict resolver. A move must have copyfrom + delete recorded
within the same revision. Otherwise it is not a move.
> (The rename/copy detection probably should be an --option, or set of
> those with thresholds, to the man sync/addremove command. Having your
> initial design plan spelled out would help.)
It has been a while. I'm afraid I didn't keep notes beyond those recorded
in log messages on the branch.
Received on 2019-12-26 11:56:02 CET