pack command...

[Michael Andronov]

John -

Thanks a lot for information provided.
It is much clear now.

One more question, if I may -

Is it possible - and how? (if it is) - to invoke 'pack' using bzrlib & python.

Thanks.
Michael.

On Wed, Sep 15, 2010 at 2:16 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 9/15/2010 11:24 AM, Michael Andronov wrote:
>> I have a question about the pack command.
>>
>> The manual says that  usually it should not be run manually.
>> At the same time, it has helped me already a couple times to recover
>> from unnecessary long times during bzr transfer operation.
>
> We do trigger automatic repacking of some of the content based on some
> heuristics. Approximately to keep ~log(N_revs) pack files around,
> without having to touch all the data all the time.
>
> The specific is to have pack files distributed roughly like the decimal
> count. So if you have 2384 revisions, we would try to have 2 1000
> revision packs, 3 100 revs, 8 10-revs and 4 1-rev. When you hit 2390,
> then we pack the 10 1-rev packs into a single 10-rev pack, etc.
>
> Running 'bzr pack' takes all 2390 and puts it into a single pack file.
> Also, push + pull will transfer many revisions into a single pack on the
> other side, so it isn't 100% clear cut. But that at least gives you the
> approximation.
>
>>
>> I'm wondering if there is a way to detect the point, when running pack
>> will really help? In order to run the pack automatically on some of
>> the nodes which are keeping repositories.
>
> We do have the above heuristic, though it isn't necessarily optimal for
> all cases. The goal is to trade off the effort of recombining everything
> with the benefit of having it repacked.
>
>>
>> Also, is pack command locking the repository ? Is it safe to run pack
>> on repository from one process, and to make bzr push/pull attempts
>> with the same repository from the other process?
>>
>> Thanks.
>>
>>
>
> Repositories are generally multi-writer safe. We lock for the one
> operation which makes the update atomic. (do the work in a temporary
> pack file, rename it into place, update the registry to include it.)
>
> The one effect for pushing and pulling is that the pull may need to
> restart if you move the files out from underneath it. The client should
> be capable of coping, but it may do extra work. Though if you only
> access the content via the 'smart' protocols (bzr+ssh, etc) then the
> server should hide the effect (it should start reading from the new
> content, and streaming it without interrupting the stream).
>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkyRDYIACgkQJdeBCYSNAAMZCwCgz/MPQwFz9lf23lk3pbquWdIv
> TbkAn2BB856kAYvbwuIORdG+XYVoO8aI
> =QRTI
> -----END PGP SIGNATURE-----
>