Autopack over dumb transports causes excess use of bandwidth.

[John Arbash Meinel]

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


...
>>   bzr init
>>   bzr commit
>>   for i in `seq 100`; do bzr commit --unchanged; done
>>   bzr pack
>>   bzr push
>>   bzr uncommit -r 1
>>   bzr push --overwrite
> 
> Would it also work to create a temporary junk branch?  That is,
> on the machine hosting the repo, do:
>     cd $repo
>     bzr init junk
>     bzr co junk  # if it's a no-trees repo
>     # commit 100 revs to branch "junk" as shown above
>     bzr pack
>     rm -r junk
> 
> Further, could one do this from the remote machine -- perhaps
> by including a suitable "bzr push"?
> 
> (These questions are not rhetorical; I'm trying to understand
> whether these things would in fact work...)
> 
>   - Eric


Well, for starters Gary's explicit request was that bzr was *not*
available on the remote server. (Otherwise he wouldn't have problems
with a dumb transport. :)

I believe creating a junk branch would have the same effect as doing
'commit --unchanged' 100 times in a real branch and then uncommitting it.

And actually, there is probably a slight benefit to using an independent
junk branch. When we do a pack, we sort roughly reverse topologically.
Which means that if you use a Junk branch, those revisions will be
separate, rather than slightly mixed with the real revisions. Though in
that initial pack file, they will probably end up in the same group
nonetheless. (Not enough data to trigger a new group to be formed. And
honestly, it will probably compress well, given the timestamps are
similar, and the revision ids/author/etc will be from the same user.)

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

iEYEARECAAYFAkqpG24ACgkQJdeBCYSNAAMwGwCfROHwH0M0OVJu2bS6nd+AoWXM
DGcAoMfpJC663Q/qhEnN9T89CRF5tLZp
=B/KO
-----END PGP SIGNATURE-----