post 0.8 development

[John A Meinel]

Matthieu Moy wrote:
> Martin Pool wrote:
>> I've just uploaded a tarball and sent a release announcement for bzr 0.8.
> 
> Congratulation to all the team !
> 
>> I think there are a number of things already written & discussed that 
>> were not merged for 0.8, and now would be a good time to pick them 
>> up.  I'll do a pass through the bug database & mail; if you have 
>> something that should go in speak up now.  So let's pick up the easy 
>> patches first that might otherwise languish, and then get into new 
>> development.
> 
> I feel bad posting my wishlist since I have no time to really 
> contribute, but the things I'd like to see are :
> 
> * A better UI for repositories :
> 
>   - a single command to push a complete repository (with Arch, I had 
> roughly a public and a private archive, and archive-mirror allowed me to 
> publish all my public branches easily).

Well, I have my 'update-mirrors' plugin:
http://bzr.arbash-meinel.com/plugins/update-mirrors

However, it was designed around 'pull' mirrors, not push mirrors.

I can see a situation where we might have an entire repository bound, 
rather than just individual branches. Or maybe just if the repository is 
bound, the branches default to being bound, but are not required to be.

(One of the flexibility benefits of bzr, is that I can have a repository 
whose branches are bound to lots of different external locations. Which 
is why my personal mirror is a repository, but points to Aaron's 
branches, Robert's branches, bzr.dev, etc)

> 
>   - Something to help me to deal with a relatively large number of 
> branches in a repository. Arch had this c--b--v which I (and others) 
> didn't like, but I think bzr can provide something useful. It's already 
> possible to have a directory structure inside a repository :
> --repo/
>    +--projectA/
>    |    +--> main-branch/
>    |    +--> old-stable-branch/
>    |    `--> short-life-branch/
>    `--Other-project/
>        ...
> I don't know exactly what bzr should provide more. At least, browsing 
> the list of branches, and perhaps a regexp filter could be useful. I 
> mean the kind of thing doable with a few lines of shell, find and grep 
> on a local filesystem, but through the bzr transport layer (at least on 
> transports supporting directory listing).

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).

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)

> 
> * updating remote working tree with push (discussed many times here, but 
> it's much less crucial now that we have the metadir format. Still, it 
> can be usefull to maintain a website with bzr, or to push to a backup 
> location - I'm paranoid enough to backup my history _and_ my working 
> trees).

The rsync plugins (bzrtools and my rsync plugin) both support updating 
remote directories. Mine is special cased to *not* work for new format 
branches (because of repositories my repository might not have all the 
revisions that the public repository needs). Though technically it 
should work for any standalone branch.

> 
> * there's also my old "how to get the diff between two remote 
> revisions", but nobody seems interested, so I'll have to do it myself 
> when I have time ;-).
> 

There is a bug report for "bzr diff -r 1..2 http://path/to/branch" not 
working. And I do think we are interested in fixing that one. (I am, at 
least). I looked into it, but the cmd_diff code is a little tricky, 
because it does a lot of different things based on what the arguments 
are. (If it is 2 branches it does something different than 2 files, 
different from no files, etc).

I don't think we've settled down on our URL scheme to support
http://path/to/branch;revision=foo
But I think if someone actually implemented a parser for that, we would 
consider merging it. (The one who actually implements it will get a lot 
of say as to how the syntax will actually work).

John
=:->