dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jun 17, 2011 at 10:57:15PM +0200, Martin Sandve Alnæs wrote:
> >> So your argument is that you should be able to push merges that will
> >> lead to removed revisions
> >
> > I don't see how this discussion can go anywhere if you insist that
> > revisions are being removed, which sounds drastic.

That's what both Launchpad and the bzr manual are claiming.

> > How can there be a merge to push if there has been no merge?

There can have been as many merges as you want downstream, as in back
and forth between your local repositories, your personal repository at
Launchpad and from lp:dolfin into any of your repositories.

Then what I'm asking is not to push those merges directly to
lp:dolfin, but instead merge all of that mess into lp:dolfin.

> I have two points to add, then I'm out of here.
> I say this because I think it is valuable that
> everybody knows how to use the tools effectively,
> not because I care if you want to do it otherwise.
> I'm fine with Garths suggestion to just do our best.
>
>
> First, you can _always_ merge into lp:dolfin the "right" direction. Always.
> If you first merge the "wrong" direction:
>   cd mybranch && bzr merge lp:dolfin && bzr commit
> then you can always:
>   cd ../trunk # assuming no local additions over lp:dolfin here
>   bzr up  OR  bzr pull  # checkout or unbound branch
>   bzr merge ../mybranch && bzr commit
>   bzr push # only if trunk is unbound branch (automatic for a checkout)

This is what I suggest (modulo the last push, see below).

> Second, I just want to repeat this again (for the third time in this thread),
> because both "sides" of the discussion seem to get it wrong:
>
> The use of a checkout of trunk vs an unbound branch of trunk
> has no relation whatsever to the direction of the merge in your
> workflow. These are two orthogonal workflow choices.

Thanks, I didn't know that.

Anyway, my point remains: we shouldn't push merges made into other
repositories to lp:dolfin. That repository should remain clean.

And let me repeat: it's not a hassle. The same number of commands as
usual (one less if using a bound trunk), just a different order in
another directory.

--
Anders