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.
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?
> 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.
> 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'.
(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.)
> Are you aware of 'asvn'?
> https://svn.apache.org/viewvc/subversion/trunk/contrib/client-side/asvn?revision=1295006&view=markup
I was not. It's not what I remember, but something to look at. Thanks
for the pointer. Would help if it'd be contained in standard installs of
svn, but I could roll it out on the servers. It reminds me of these
idle ideas to have signed commits via added svn properties …
Alrighty then,
Thomas
--
Dr. Thomas Orgis
HPC @ Universität Hamburg
Received on 2019-12-23 14:04:01 CET