dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 17 June 2011 22:04, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>
>
> On 17/06/11 20:51, Anders Logg wrote:
>> 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
>
> I don't see how this discussion can go anywhere if you insist that
> revisions are being removed, which sounds drastic. Nothing is being
> removed, and there are unique revision IDs.
>
>> 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.
>
> How can there be a merge to push if there has been no merge?
>
> Garth
>
>> The merge should happen *from trunk*, not be pushed
>> into it.
>>
>> --
>> Anders
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>

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)


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.

Martin