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 <stsp_at_elego.de>
Sent: 26 July 2018 11:52
To: Jens Restemeier <jens_at_playtonicgames.com>
Cc: users_at_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.
Received on 2018-07-26 13:55:40 CEST