Re: svn commit: r1618138 - in /subversion/trunk/subversion: libsvn_fs_fs/caching.c libsvn_fs_fs/fs.c libsvn_fs_fs/fs.h libsvn_fs_fs/fs_fs.c libsvn_fs_fs/fs_fs.h libsvn_fs_fs/hotcopy.c libsvn_fs_fs/structure tests/cmdline/svnadmin_tests.py

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. brane_at_wandisco.com