bzr repository structure...

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...
>> a. The strange behavior is that running `bzr pack` on the branch in
>> question takes a very long time... ( I should probably say the machine
>> 'hang'... but every couple of hours, - repacking ... string is making
>> a click...)...
>> Is there any way to verify that is going on during the packing?
>>

This seems kind of odd. It sounds like you are hitting swap during the
repack. One thing to check is if your extensions are compiled. (If you
are running an installed bzr, they most likely are.)

>> (  I have a few branches on my machine, approximately the same size of
>> initial files/tree. But for some reason, this particular branch is
>> giving a headache quite often:
>> periodically, the 'bzr branch ...' is going into the long
>> re-transmissions of particular packs... . I used to run 'bzr pack' to
>> recover from such situation. But it seems that right now  something
>> else happened,
>> and even bzr pack is working extremely slow...)
> 
> bzr normally repacks on power-of-ten boundaries, so after 10 commits
> those ten will be repacked, after 100 commits all of them are
> repacked, etc.  So you should only see a substantial repack delay only
> say every thousand or ten thousand commits.
> 
> If you're often noticing this then I would suspect: your tree is
> really enormous; you have something automatically making many commits;
> or something is broken in bzr or your environment.
> 
> A good way to find out what's happening would be to run
> 
>  bzr pack log+file:///home/mbp/bzr  (or whatever the path is)
> 
> Repacks over ftp/sftp are going to be kind of slow and you would be
> better off using bzr+ssh or similar.


The other thing to note, is that issuing 'bzr pack' manually puts
everything into one big pack file. Which could easily be why you are
seeing 1 100MB pack file, and a bunch of small ones. The small ones are
new commits, the large one is everything you had when you last ran 'bzr
pack'.

Note that it is really only in extreme circumstances that you should
need to be running that command manually.

> 
>>
>> b. While looking into the ../repository directory, I've noticed some
>> unusually long file :
>>
>> -rw-rw-rw-  1 mike  bazaar  106766418 Jan 24 11:54
>> 9575cb746896b22713dca82aebb5d85d.pack
>>
>> First, the difference is within permissions, and second  -- the size.
>> See the whole ../repository listing below:
>>
>> I'm wondering, if it is normal?
> 
> It's one pack of 100MB.  If you have >100MB of history then yes, it's
> normal.  If you have a small tree or few commits something may be
> wrong: perhaps you are accidentally committing binaries?
> 
> Normally bzr tries to match the existing permissions.  What OS,
> filesystem, and bzr transport protocol (ie ssh, sftp, etc) are you
> using?
> 
>> Also, I was looking for some  doc, describing what the repository/
>> structure is about, and what should be inside.
>> Is any document like this exists?
>> At which point the pack from this directory will be moved to obsolete packs?
>>

When we autopack or you issue 'bzr pack', files currently in obsolete
get deleted, the files being repacked get moved into obsolete packs, and
new files get put into packs.

As for the permission thing. My guess is that when you connect to this
machine from remote, you have a umask of 002, but when you connect
locally you have a umask of 000. Do you have something set in your
~/.bashrc or ~/.bash_profile? (or whatever shell you use.)

Note that bzr+ssh does *not* trigger ~/.bashrc to get loaded. I think it
does load some of the /etc/ files. Just how ssh works when you run in
non-interactive mode.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1akIsACgkQJdeBCYSNAAM/pwCbBWoLH45aWwznglSfQG54+Ple
XCAAoNhj/Zo6E/vFDLQ2w0Q3E7qx3t6b
=6FnL
-----END PGP SIGNATURE-----