On 17.08.2014 00:53, Evgeny Kotkov wrote: > It looks like we have another misunderstanding here with the "major FS > feature" part. From my point of view, this is a *fix* for an existing > FSFS feature (ability to share data and cache filesystem data),
I'm perfectly aware of what your change is for and which issues it is intended to fix. That does not change the fact that adding another repository identifier affects visible behaviour of FSFS, therefore it is a major change in functionality. Furthermore, while there has been some discussion on this topic, I have not yet seen an a list of all side effects this new ID may have (or that we may want it to have). I certainly do not expect the addition to only affect caching, but also svnadmin (create, dump, load, hotcopy, ...), probably svnlook, and we may certainly find other changes we'd want to make now that we have this second ID. In short, while the secondary ID in itself is a good idea, I'm missing some discussion (e.g., in a design doc on our Wiki) about its side effects, and an implementation of these side effects. While it's clearly possible to make all the code changes in small steps on trunk, it's much harder for people to review and asses the total effect than if it were done on a branch. Yes, we often make such changes on trunk, and we should stop doing that, especially for changes that affect the FS. Note that the above does not imply that such a branch would have to be maintained for the next six months, nor does it imply that your change would not make it into 1.9. But I would like it to be (a) documented and (b) rather more complete. -- Brane -- Branko Čibej | Director of Subversion WANdisco | Realising the impossibilities of Big Data e. br...@wandisco.com
