post 0.8 development

David Allouche david at allouche.net
Wed May 10 16:59:55 BST 2006


On Mon, 2006-05-08 at 12:44 -0700, John A Meinel wrote:
> You're thinking something like 'bzr browse', right?
> I could see a tool that just does a recursive transport.list_dir(), and 
> looks for '.bzr' directories. That would actually work for both 
> repositories, and collections of standalone branches.
> 
> The problem is that the round-trip overhead is probably murderous. You 
> have a 'list_dir()' call for each directory, and then a 'stat' call for 
> every entry (to determine if it is a file or a directory).

For local filesystem, latency is not a big problem.

For SFTP, the listdir protocol actually gives the stat information too.
You just need to use the right paramiko API that does not discard this
information.

For HTTP, we're screwed anyway. _Maybe_ it would be possible to support
the directory listing functionality of specific http servers provided
that such listings come with a distinguishing header (to avoid
downloading actual files). Then it _might_ be possible to infer the
directory/file stat information from the form of the hyperlinks
(directory links conventionally end with a trailing slash).

For FTP, I do not know.

> Because of that overhead, I believe there was a little bit of discussion 
> about making repositories more directly aware of what branches they 
> contained. (.bzr/repository/branch-list type of thing).
> Then it would also work over http.
> But it has some of the same issues as Arch's .listing files (easy to 
> become out of date)

Bzr should not get out if its way to support that. For example we should
not recommand "bzr mv" to rename branches and maintain the repository
manifest, or make bzr push slower by requiring it to traverse the target
repository and update the manifest.

I think the "enable WebDAV or install that little CGI on your webserver
to support repository manifests via HTTP" approach is a good trade-off.

-- 
                                                            -- ddaa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060510/7c3f5892/attachment.pgp 


More information about the bazaar mailing list