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.
Received on 2018-07-26 15:46:13 CEST