C. Michael Pilato wrote: > On 09/20/2014 03:56 AM, Branko Čibej wrote: >> We should do exactly the opposite! We should make sure that even no-op >> changes >> always get recorded and reported consistently. [...] > > FWIW, this line of thought is consistent with the original FS > backend and dump/load design goals. The guiding principle was about > preserving as much information as we could rather than presuming > that we knew what information did and didn't matter to an > administrator.
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 > svn_fs_contents_changed() never bothered to compare the respective > prop/text content, but merely noticed that the DAG had or hadn't > been adjusted. 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.
