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 <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.
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.
