On 14.10.2019 10:07, Johan Corveleyn wrote:
> On Fri, Oct 11, 2019 at 4:56 PM Julian Foad <julianfoad_at_apache.org> wrote:
> ...
>> Some of the existing svn protocols and APIs explicitly preserve certain
>> no-op changes. For example, one user reported [2] that in their svn
>> history (converted from CVS) they would "hate to lose" the historical
>> record that "svn log -v" reports "file text changed" for a certain no-op
>> file change. When I eliminated this no-op change from "dump", without
>> due care to backward compatibility, it was considered a regression and
>> reverted [#4598]. There are valid arguments for preserving backward
>> compatibility in some places. However, I propose such behaviour should
>> be considered obsolete and broken, and a migration path should be
>> planned to get away from it.
> Hi Julian,
>
> As the user in question, who reported this loss of history at $company
> while dumping/loading our repo: at the time, I was mainly concerned
> with backwards compatibility, wanting to preserve our existing history
> as close to 100% as possible. I was also very much surprised by this
> change in behaviour. Another couple of years have passed, and now I
> think: meh, it's probably not such a big deal.
Well actually it is. And here's why:
If you have a repository with such no-op changes; and you want to do a
dump/load cycle in order to, I don't know, optimize the repo or make new
features available. Then, if the dump or the load step drops no-op
changes, all existing working copies suddenly are no longer compatible
with the new repository, even if you preserver the UUID. You can't just
'svn relocate' any more (or replace the repo on the server), you have to
do a fresh checkout, or expect possibly corrupting side effects.
-- Brane
Received on 2019-10-14 23:14:27 CEST