svn add option to record replaced files as modified?

[Jens Restemeier]

I was wondering, would it be possible to add an option to “svn add” to
record deleted and then added files as “modified” instead of “replaced”?
Obviously this could be done with a script (backup the current file, svn
revert the file to remove the deleted status, copy the backup over the
restored file), but it may be safer to just update the metadata differently
inside the command. Or is this already possible with an option or command
that I’m not aware of?

[Jens Restemeier]

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.

P.S.: I am not subscribed, so please CC me in any responses.
---------------
From: Jens Restemeier <***@playtonicgames.com>
Sent: 25 July 2018 15:06
To: '***@subversion.apache.org' <***@subversion.apache.org>
Subject: svn add option to record replaced files as modified?

I was wondering, would it be possible to add an option to “svn add” to
record deleted and then added files as “modified” instead of “replaced”?
Obviously this could be done with a script (backup the current file, svn
revert the file to remove the deleted status, copy the backup over the
restored file), but it may be safer to just update the metadata differently
inside the command. Or is this already possible with an option or command
that I’m not aware of?

[Stefan Sperling]

Post by Jens Restemeier
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.

[Jens Restemeier]

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 <***@elego.de>
Sent: 26 July 2018 11:52
To: Jens Restemeier <***@playtonicgames.com>
Cc: ***@subversion.apache.org
Subject: Re: svn add option to record replaced files as modified?

Post by Jens Restemeier
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...

Post by Jens Restemeier
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.

[Stefan Sperling]

Post by Jens Restemeier
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.

Post by Jens Restemeier
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.

[Stefan Sperling]

Post by Stefan Sperling
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.

Sorry, I got confused between svn_client_revert and svn_wc_revert here.

The client layer already exposes this, so we could start directly
in svn_cl__revert() (subversion/svn/revert-cmd.c) and make the
meta-data only parameter configurable via a new flag in opt_state:

err = svn_client_revert4(targets, opt_state->depth,
opt_state->changelists,
FALSE /* clear_changelists */,
FALSE /* metadata_only */,
TRUE /*added_keep_local*/,
ctx, scratch_pool);

[Jens Restemeier]

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 <***@elego.de>
Sent: 26 July 2018 14:46
To: Jens Restemeier <***@playtonicgames.com>
Cc: ***@subversion.apache.org
Subject: Re: svn add option to record replaced files as modified?

Post by Jens Restemeier
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.

Post by Jens Restemeier
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.