The decision to delete and recreate the file is done outside the svn integration, and I only get messages when a file is deleted or has been saved. I could keep track which files are added or deleted and collapse events for the same file, but there is a risk that this information is lost when the plugin is reloaded, and I can't guarantee that I get a message when the application quits. Both the case of missing a file delete and file add can cause problems, so it is safer to update the svn workspace right away.
The advantage of handling it inside "svn add" is that it doesn't require changes to files in the workspace - when moving files there is always the risk of errors from filename collisions or file locks by the OS, while the client just needs to set a different flag in the internal database. If you delete and add a file you want to end the history of the previous file and start a new history for the new file - that is perfectly fine and the expected behaviour. In the same way normally the application just overwrites a file with a new version - which works fine as well. In some cases the application deletes the existing file and writes a new file. I still want the history of the file to be connected, though. Yes, in an ideal case it would just overwrite the file, but that is outside of my control. Showing a "diff" of a replaced file, for example in TortoiseSvn, shows a new file with a blank previous file. Reverting the "replace" shows the actual difference, and allows me to judge if I want to commit the new version. In some cases the new and old file are identical, so don't need to be committed at all. -----Original Message----- From: Stefan Sperling <s...@elego.de> Sent: 26 July 2018 11:52 To: Jens Restemeier <j...@playtonicgames.com> Cc: users@subversion.apache.org Subject: Re: svn add option to record replaced files as modified? On Thu, Jul 26, 2018 at 11:01:59AM +0100, Jens Restemeier wrote: > I just added a script to the svn integration in my project using the > backup/revert/overwrite solution, so my use case is covered for now. > An "svn add --restore" option to do this in the client would still be useful... > maybe I'll try to hack it in when I have some time. Why can't your svn integration just overwrite an existing versioned file without using 'svn rm' and 'svn add' in the first place? Is the decision to delete a file uncoupled from the decision to re-add the file? If so, why? If the file is already deleted and you want to restore and overwrite it without causing a replacement, then using 'svn revert' to undo the deletion and overwriting the file is a good solution. Which advantage would a new option to 'svn add' provide here? Why are replacements bad in your use case? I know many of reasons why they could be bad. I am asking anyway because you are not explaining your actual problem, you are explaining your solution to a problem which is unknown to readers of your messages. Which makes it hard for others to properly reason about your approach and provide good advice.
