subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fuhrmann <stefan.fuhrm...@wandisco.com>
Subject Re: enable packing by default
Date Wed, 18 Jun 2014 16:22:28 GMT
On Wed, Jun 18, 2014 at 6:03 PM, Ivan Zhakov <ivan@visualsvn.com> wrote:

> On 16 June 2014 15:53, Stefan Sperling <stsp@elego.de> wrote:
> > Stefan2 pointed out that format 7 is less efficient if packing is
> disabled.
> > So to fully benefit from format 7 in the default configuration, users
> must
> > currently run 'svnadmin pack' or edit fsfs.conf to enable packing after
> commit.
> > Since format 7 adds locking support to pack, so it should be safe to
> trigger
> > packing at any time.
> >
> > It looks like it makes sense to enable packing after commit by default
> > for format 7 repositories. Any objections?
> >
> I strongly disagree with the proposed patch. With this patch every
> 1000th commit will take long time: because Subversion will have to
> combine 1000 revisions to one file. That's means with 1mb revisions
> Subversion will have to write 1gb to disk for the 1000th commit. This
> cannot be done fast and during this time svn client will hang.
>

Well, with 1M average revision sizes, f7 will not need
packing to be as fast or (much) faster than f6. It's the
<64kB revisions where the extra index file access
becomes noticeable.

FWIW, we can fork off the pack process instead of
letting the client wait (which you also mentioned below).


> We cannot broke one of the current fundamental characteristics of
> Subversion. The time of the commit should only depend on the size of
> the committed data. It shouldn't depend on the cumulative size of the
> previous 1000 commits!
>

That is not strictly true. The commit time is proportional
to the aggregated lengths of every modified node's history.
Until recently, that could mean O(#num_revs * #changes).


> The possible solutions are to pack incrementally after each commit or
> trigger packing to be performed asyncronously (i.e. in background),
> but I'm not sure if it's possible to implement easily.
>

We can simply fork() off as we do with post-commit scripts.
Even if it should fail for some reason, the next successful
pack run will catch up to HEAD.

-- Stefan^2.

Mime
View raw message