Yes, I'm using the SVN APIs directly. I must have missed the option in
svn_client_revert3, so I'll change the code to use it. Thanks for the
suggestion!
By the way, I'm already making use of the metadata_only option in
svn_client_move7, because I get the move callback after the application has
already moved the file. That doesn't seem to be exposed in the command line
client, either. Mercurial "hg move" has an option -A/--after to record moves
after they have already happened.
-----Original Message-----
From: Stefan Sperling <s...@elego.de>
Sent: 26 July 2018 14:46
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 12:55:29PM +0100, Jens Restemeier wrote:
> 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.
Are you relying on the svn command line interface to write your integration?
If so, have you considered using the SVN APIs directly?
This would generally be the preferred way of implementing such an
integration, and the API already provides the semantics you need.
A revert can already be performed as a meta-data only operation at the WC
API level, see svn_client_revert3(). This will allow you to revert the
deleted file to a 'normal' state without touching any of the user-visible
files in the working copy.
Of course, this suggestion only helps you if SVN bindings for your
programming language exist. If that is not the case, then maybe rather than
changing 'svn add', adding a corresponding option to 'svn revert' would help
you? ('svn revert --keep-local' might make sense, since a --keep-local
option already exists for 'svn delete')
Note that libsvn_client does not expose this functionality yet.
So the command line client would probably need a new wrapper API at the
client library layer as well in order to expose this feature to the command
line user. But this should be rather straightforward.
> 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.
The WC database is quite complex and I would refrain from bypassing the
already existing operations when manipulating it.
There is not just a simple flag in the WC database. There's a row in the
NODES tables which corresponds to the deleted layer.
What you'd need to do is remove that row and any potential additional rows
representing extra layers (i.e. replacements) on top.
Which is exactly what the 'revert' operation does. With that in mind, an
implementation inside 'svn add' seems out of place.
