bzr-pipeline, installers and explorer
aaron at aaronbentley.com
Sat Nov 21 04:59:31 GMT 2009
Barry Warsaw wrote:
> Pipes improve this sense of working in "something different" because
> you're really not. Once I'm over the lightweight checkout thing, it's
> pretty natural to create a new pipe, diff between them, trunk-sync,
> etc. Pushing to Launchpad seems a bit weird in that it feels like I
> have to do that from the pipe branch, not from my working directory.
You never have to push from the branch-- you can always push from the
lightweight checkout of that branch, modulo the rare bug #189757.
> sync-pipeline is kind of magical and error prone. It certainly doesn't
> feel natural. It should be called 'push'
Even though it also pulls? Even though it's "magical and error prone"?
I think if I did that, people would feel like bzr-pipeline upset their
expectations of Bazaar's behaviour and got in the way of them doing work.
Loom overrides push behaviour so that you have to record or export-loom,
and look what you said about that:
> 'record' is a well-known [wart], but so is the requirement to 'export-loom' in order to publish the branches
> ...I've run into problems
> where sync-pipeline fails for mostly mysterious reasons (again,
> apologies for not having concrete examples).
sync-pipeline expects you to use it cradle-to-grave. If you start by
pushing the branches with "bzr push", their pipeline relationship will
not be preserved. If you then use sync-pipeline, it will try to create
the pipe that is missing from the remote branch, but since that branch
was already pushed separately, it will be unable to create it and will die.
I probably will make sync-pipeline more tolerant of in-the-way pipes.
> Pipes don't seem to
> integrate well with 'bzr send' and pqm-submit, as again I can't seem to
> do that from my working tree, and instead have to be in the pipe branch
> directory to have any hope.
You'll have to explain why. It should have exactly the same effect as
running it from the relevant branch.
> Pipes should have a
> way of saying "all my pipe branches go in ./.pipes"
They do. When you create a new pipe, it is created in the same
directory as the current pipe. So if you create your first pipe in
./.pipes, all the subsequent pipes will also go there.
> * Steal all of rockstar's aliases
> * first = switch-pipe :first
> * next = switch-pipe :next
> * prev = switch-pipe :prev
> * pipes = show-pipeline
pipes is the only one from that list which can be turned into an
official alias, and I stole it back in September. The remainder are
recommended in the help (except "first", which isn't mentioned here:
The remainder could only be done as stand-alone commands, and I'm not
eager to do that. For myself, I find it enough to alias "switch-pipe"
to "swp", and "swp" is now an official alias.
> * Make "diff" by default do "diff -r ancestor::prev"
I don't agree with this. I think it would break diff in more cases than
it would fix it. It really serves the same purpose as "bzr diff -r
ancestor::submit", and we certainly don't default to that in standard bzr.
I have a strong bias toward not changing the behaviour of existing
commands. I don't want to upset peoples' expectations. I don't want
people to feel like bzr-pipeline gets in their way. This is one reason
why there are switch-pipe and sync-pipeline commands instead of just
overriding "switch" and "push" like loom does.
> * Make "send" by default do "send -r ancestor::prev.."
For the purpose of submitting changes to Launchpad, "bzr send -r
ancestor::prev.." no longer does what you want. It was a hack-- it
displayed a diff that did not represent the merge that was proposed. It
doesn't work with the way people wanted diffs to work. Instead, we use
prerequisite branches, and I have recently introduced the "lp-submit" in
trunk for creating merge proposals on Launchpad, specifying the previous
pipe as the prerequisite branch.
Still care about send? I've already noted that ancestor::prev is
similar to ancestor::submit, and "send" already defaults to "-r
ancestor::submit..", so perhaps this would be a good change.
> * By default, put pipe branches in ~/.pipes instead of as a sibling to
> the l/w co branch
> * Make "push" Just Work and get rid of the need for sync-pipeline
Just Work is way too vague. Do you want it to push up the whole
pipeline? Looms change the meaning of "push", and I think that's a
major problem with them. Do you want it to push up an individual pipe
while preserving pipeline relationships? That's a tall order, because
if individual pipes are pushed, there's no guarantee that the next or
previous pipe does exist in the remote location.
> * Somehow reduce the need to push all the underlying branches when
> pushing the current pipe
When bzr introduces colocated branches, I will be eager for bzr-pipeline
to adopt them. Until then, I recommend using sync-pipeline.
It does its best to avoid unnecessary work. It reuses connections, and
it tries to avoid performing the revision-copying phase more than once.
If you have pumped since the last commit, then all of the revisions
referenced in the pipeline will be referenced by the last pipe, so
pushing bzr-pipeline pushes it first. This works when the remote
location is a shared repository, but not for Launchpad, because it uses
stacking instead of shared repositories.
More information about the bazaar