dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

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