why is pipeline (and maybe colo) so localized?

[Aaron Bentley]

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

On 11-10-11 07:47 PM, Wichmann, Mats D wrote:
> But with a branch set up with pipelines, that doesn't work... if I
> copy it over, it's "not a branch".  Yes, there's an aspect that's
> immediately visible, .bzr/branch/location is (needlessly?) branded
> with an absolute path which is certainly going to be different for
> a different OS, since Windoze home directories are not in the same
> place as Linux ones.

That decision originates with lightweight checkouts, not with
pipelines.  Pipelines takes pains to be as compatible with
contemporary formats and processes as possible, so it uses lightweight
checkouts rather than following looms and introducing a new branch format.

This affects only the working tree.  The branches themselves are still
accessible, and "bzr switch --force" should make the checkout use the
new location.  If you used reconfigure-pipeline, they will be in
.bzr/branches/ or .bzr/pipes/

IIRC, the original rationale for lightweight checkouts was that
absolute locations make it more convenient to move the lightweight
checkout itself around.

> More importantly (I know /copying/ a branch elsewhere isn't really
> a supported scenario, even if I've gotten away with it for years)

Actually, being able to create a new branch using recursive copy was
part of Martin's original design, back before he joined Canonical and
started hacking on Bazaar, so it's no coincidence that it still works.
 Over the years, shared repositories, lightweight checkouts and
stacked branches have somewhat diluted that original vision.

> "Maintaining a series of patches against software from tarballs"
> is compelling, but if we use that model in the master, how do you
> create a working branch of that, say to add a new upstream
> revision?

I don't know.  It's not something that I'd do.

In order to have branching and merging of the state of the whole
pipeline, the state of the pipeline would need to be versioned data,
and it's not.  Pipes in a pipeline are peers, so there's no central
place to put such data.  If you need that, you should take a look at
looms, because their equivalent concept *is* versioned.

> bzr branch branches only the "current".

Right, but you should be able to use sync-pipeline instead.  It's
bidirectional.

> And if you have it in a working area, how do you push changes?
> bzr push doesn't push the whole pipeline, only the current stage.
> bzr sync-pipeline doesn't like seeing a similar structure already
> in place (File exists).

sync-pipeline will happily use an existing branch, if it is
compatible.  To be compatible, the target branch must not already be
part of a different pipeline, and its tip revision must be an ancestor
of the source branch.

> Honestly, that's NOT what I expect.

I'm sorry it's not what you expect, but having the behaviour of push
change depending on the source is also surprising.  Looms override
branch, push etc. be have radically different behaviour when used with
looms, and I found this got in the way of using the commands normally.
 I think it's better to have specialized commands, such as
sync-pipeline, for manipulating the pipeline, rather than making
existing commands behave differently.  But hey, if looms bring you
joy, then there's more joy in the world.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6VJc0ACgkQ0F+nu1YWqI0uVACfczOJTE+BQDehCh1g20w9v3wx
HPYAniTOLSysCwH4lQB8OHC2LfuWc9yC
=lDOv
-----END PGP SIGNATURE-----