Re: No no-op changes
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 22 Sep 2014 16:04:03 +0100
C. Michael Pilato wrote:
Hi, C-Mike. Thank you for that bit of background context. To be clear, I take it that you are merely pointing out that there was a thought process that led to this present behaviour and it was not just a coding mistake. That's fine. It's good to know a bit about how the present state came to be.
> This is why svn_fs_props_changed() and
That's as may be, but the undocumented behaviour of those two functions, and some records in the dump file output, seem to be the only trace that a "no-op change" concept ever existed. Neither of those functions is called directly by any test code, and their doc strings never hinted (until r1572363 this year) at any such intention. In fact, as far as I can see there is no mention of this concept in any of our documentation anywhere. Nothing describes what kind of committed "changes" might or might not be recorded as a change. Nothing describes what no-op edits an svn_delta_editor_t implementation must pass on. And as I mentioned elsethread this FS information is not preserved [1] by a dump and load.
In fact, as we have long tried to avoid committing no-op changes, we would never have encountered those use cases except if third parties were writing code directly against the low level APIs.
Would you accept that it now makes more sense to make the overall system behaviour more consistent by moving towards the majority direction (not preserving no-ops)? At least at some layers -- repos layer or RA layer? Or do you first need more information?
I want to get some agreement in principle before going on to discuss exactly what behaviours should be changed at what layers, with due consideration for backward compatibility of APIs etc.
- Julian
[1] I just noticed that different versions of Subversion do not all preserve the same set of no-op "change" evidence through dump and load.
|
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.