On Wed, Jul 6, 2011 at 2:55 PM, Ivan Zhakov <i...@visualsvn.com> wrote: > On Wed, Jul 6, 2011 at 23:30, Hyrum K Wright <hy...@hyrumwright.org> wrote: >> On Wed, Jul 6, 2011 at 11:47 AM, Daniel Shahaf <danie...@elego.de> wrote: >>> This thread is now the only non-FSFS release blocker (filed as #3944). >>> Last I checked there were at least three solutions suggested, but no >>> consensus on which solution to implement. >>> >>> Some suggestions were >>> >>> >>> 0. Leave things as they are >>> >>> 1. Allow packing revisions without packing revprops. >>> (revprops/ remains as in 1.6/f4) >>> >>> 2. Have all revprops in the DB all the time, never in plain files. >>> >>> 3. Swap the DB for some other "A thousand revision's revprops in one >>> file" solution. [several suggestions as to that file's format] >>> >>> >>> Can we decide on what to do here? >>> >>> Thanks, >>> >>> Daniel >>> >>> >>> --------- >>> >>> My opinion: >>> >>> * (1) is orthogonal to the others, but may be a good idea if we refactor >>> the FS so shortly before the release >>> >>> * (2) simplifies things, doesn't solve the problems with having an >>> SQLite db authoritative for parts of the FS storage >>> (read: cp(1) unsafe) >>> >>> * (3) has my +1, assuming it's sufficiently performant and the concrete >>> design is reasonable >>> >>> * (0) would mean that if we refactor revprop storage later, 1.8 servers >>> will have to try and read revprops from *three* places; and lots of >>> headache in the upgrade (and read-from-a-being-upgraded-FS) codepaths. >>> So, if f5 should be improved, I'd rather do that /before/ it's >>> released (and has to be indefinitely supported). >> >> After a bit of thinking and discussion, Daniel and I have come up with >> what we think is an acceptable solution, and I'm posting it here for >> validation. (Daniel, please correct me if I've gotten something >> wrong.) >> >> Revision properties will *not* be packed in an sqlite database, but >> will instead be packed in a single packfile, much like revision are to >> today. > Are you suggesting to create single packfile for whole repository or > packfile for each shard? Per shard packfile looks more reasonable for > me.
Packfile-per-shard. >> The key difference is that instead of having a separate >> manifest file, the manifest will be prepended to the packfile, meaning >> the two can be atomically replaced in the case of a propedit. >> This solution has at least of couple of advantages: >> * No need to check a separate "edited" file before reading the packfile >> * The repo maintains consistency in the case of a filesystem copy >> (helpful for backups) >> >> Revprops wouldn't be packed until explicitly asked to do so by >> 'svnadmin pack' which means the frequent post-commit revprop editing >> wouldn't pose a performance problem. In addition, the revprop >> packfile manifest information won't be cached, since the manifest may >> change. We don't anticipate this to be a problem, since it only adds >> an extra seek() to the revprop lookup process (rather than the open() >> + seek() in the rev packing world). >> >> Comments? >> > > > -- > Ivan Zhakov >
