dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jun 17, 2011 at 08:20:42PM +0100, Garth N. Wells wrote:

> On 17/06/11 20:10, Marie E. Rognes wrote:
> >>>>
> >>>> I suggest that instead you do:
> >>>>
> >>>>    bzr checkout lp:dolfin trunk
> >>>>
> >>>
> >>> No thanks.
> >>
> >> Why not?
> >
> > Because I like to have control of when things will be committed to
> > lp:dolfin (by doing push explictly rather than that suddenly happening
> > if I commit in the wrong directory).

You have full control! It only happens if you do

  cd trunk
  bzr merge ../work

It seems to me that's highly unlikely to happen by accident...

> >>> But isn't that exactly what happens in (*) above?
> >>
> >> I don't understand. Do you mean that (*) is this?
> >>
> >>    bzr merge ../trunk (*)
> >>
> >> That merges stuff from trunk into your local branch. It doesn't push
> >> anything to trunk.
> >>
> >
> > Yes. But then later when one does
> >
> >      cd trunk
> >      bzr merge ../rognes
> >
> > I'm imagining that the previous merge in (*) (cf "merges made
> > elsewhere") will be pushed into trunk. But that might just be my
> > imagination.

Yes, it's your imagination. The merge made elsewhere will be *merged
from trunk*, not *pushed into trunk*. I tried the exact scenario you
described and it worked *perfectly* fine.

> >> I sounds to me like you (and Garth) try to ignore the simple
> >> instructions for how to use bzr and then claim it doesn't work.
> >>
> >
> > I'm having a hard time understanding how my previous statement "to say
> > that it "doesn't work" is not my intention" can be interpreted as
> > that. Anyhow, what I'm saying is that I have been following the
> >
> >       cd trunk
> >       bzr merge ../elsewhere
> >
> > recipe: in most cases it works beautifully, in some more complicated
> > cases (which I cannot easily reproduce), it has not.

Let me know next time and I might be able to help. :-)

> >> Here are the *very simple* instructions again:
> >>
> >>    bzr init-repo dolfin
> >>    cd dolfin
> >>    bzr checkout lp:dolfin trunk
> >>    bzr branch trunk work
> >>
> >> Then do your work in work/ (or any other local branch), push and pull
> >> as much as you want to your personal lp branch and finally, do
> >>
> >>    cd trunk
> >>    bzr update
> >>    bzr merge ../work
> >>
> >> Very easy, no pain, fast and small local storage (as a result of bzr
> >> init-repo).
> >
> > You prefer that way. I prefer a slightly different way. There should
> > be room for both.

So your argument is that you should be able to push merges that will
lead to removed revisions since for some reason you prefer not to
write the commands

  cd trunk
  bzr merge ../work

?

I think it's important that since lp:dolfin is a common repository for
many developers, we agree on how to merge changes into lp:dolfin. My
point of view is that

1. merging from trunk is cleaner as it avoids removed revisions
2. the overhead is virtually zero:

   bzr merge lp:dolfin && bzr commit -m merge && bzr push lp:dolfin

vs

  cd trunk && bzr merge ../work && bzr commit -m merge

The second option is even shorter!

> I agree with the above. Can we all settle on just
>
>   "try hard not to do 'bzr merge lp:dolfin'"

This is incorrect. One should be able to do

  bzr merge lp:dolfin

anytime. That's not the problem. The thing we should avoid is doing

  bzr push lp:dolfin

if that push contains a merge with trunk (fine if it doesn't contain
such a merge). The merge itself is not the problem. The problem is the
push of the merge. The merge should happen *from trunk*, not be pushed
into it.

--
Anders