[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI

[John Arbash Meinel]

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

Robert Collins wrote:
> On Thu, 2009-04-16 at 00:40 +1000, Ian Clatworthy wrote:
> 
> I do like the docs. However I have some concerns too.
> 
>> 1. checkouts should be lightweight by default (ala svn)
> 
> There are serious performance implications in this. For starters, right
> now this scales with tree size * latency. E.g. its about as slow as its
> possible to be. Is it something we could aim for? Yes, but then we'll
> have to download data over the network for every diff operation.
> lightweight checkouts are really only suitable for high bandwidth low
> latency environments. Fixing them to have a local cache is ~= to using a
> stacked bound branch with sufficient fixes to allow disconnected use. I
> don't think we have the manpower to achieve those fixes in the sort of
> time frame we'd like to have a 2.0 happening in.
> 

I would agree that a "better" lightweight checkout is a "stacked"
checkout, where we've put a little bit of history in the repo.

Specifically, you can download the minimum to get your working tree
(which by my tests with --dev6 is *very* close to a tarball size), push
that data into the local repository, stack on the old one, and generate
the working tree.

At that point, you have enough data for diff, and technically even
enough data for offline commit. Though with something like this, I would
tend to *not* allow you to unbind/commit --local. (Personally, I feel
that commit --local adds more to confusion than benefit, perhaps because
of how it interacts with 'update', and no short-form for pushing the
local commits to remote.)

This falls into what we called "shallow", which has a few different
definitions. One of them was that when we fetch data, we save it, but
otherwise we don't request more data than we need *right now*.

I tried a bit on implementing it, but the big problem is that fetch is
done inside of otherwise read-only operations (bzr log, for example),
and then you need to figure out when to promote the local object to a
write-operation, etc. You could have "ShallowBranch.lock_read()" always
write-lock its own repository, and read lock the fallbacks. It isn't
great, but it is *possible* (there is also the issue of
start/commit_write_group, etc....).

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

iEYEARECAAYFAknnO3kACgkQJdeBCYSNAAMbXACbBKX7W+KxjsvPMAejM56OKzfD
ZN0AnRDH31Fs2y+oFqikM0VJD07vABGb
=tMXO
-----END PGP SIGNATURE-----