Am Fri, 20 Dec 2019 19:36:36 +0100 schrieb Stefan Sperling <s...@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
