dolfin team mailing list archive

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

On 17/06/11 20:10, Marie E. Rognes wrote:
> On 06/17/2011 08:47 PM, Anders Logg wrote:
>> On Fri, Jun 17, 2011 at 08:21:34PM +0200, Marie E. Rognes wrote:
>>> On 06/17/2011 08:03 PM, Anders Logg wrote:
>>>> On Fri, Jun 17, 2011 at 03:37:50PM +0200, Marie E. Rognes wrote:
>>>>> On 06/17/2011 11:28 AM, Anders Logg wrote:
>>>>>> If Garth can't be bothered, maybe you could describe a specific
>>>>>> example that doesn't work?
>>>>>>
>>>>>
>>>>> Everything can be made to work one way or the other, so to say that
>>>>> it "doesn't work" is not my intention.
>>>>>
>>>>> However, I _seem to remember_ the following scenario from a couple
>>>>> of days ago.
>>>>>
>>>>> # Have
>>>>> bzr branch lp:dolfin trunk
>>>>
>>>> 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).
> 
>>
>> This is what let's you merge things into trunk, rather than push
>> merges to trunk (which will rewrite history).
>>
>>>>> bzr branch trunk rognes
>>>>
>>>> This is fine.
>>>>
>>>>> # Do work and push to test
>>>>> cd rognes
>>>>> <work and commit>
>>>>> bzr push lp:~dolfin-core/dolfin/rognes
>>>>
>>>> This is fine too.
>>>>
>>>> I did exactly this now and pushed to dolfin/logg with commit message
>>>>
>>>>    "Testing append_reivisons_only, commit by logg"
>>>>
>>>>> # Wait for buildbots.
>>>>> # Meanwhile, things happen in dolfin
>>>>> cd trunk
>>>>> bzr pull
>>>>
>>>> If you have done a checkout, you should instead do:
>>>>
>>>>    cd trunk
>>>>    bzr update
>>>>
>>>> Turns out the timing for this test was good. Garth had just pushed to
>>>> trunk with the commit message
>>>>
>>>>    "Clean up for removal of real."
>>>>
>>>>> # Want to check whether things still work in rognes
>>>>> # after additional stuff has happened in dolfin
>>>>> cd rognes
>>>>> bzr merge ../trunk (*)
>>>>> bzr push lp:̃~dolfin-core/dolfin/rognes
>>>>
>>>> This is almost correct. Before pushing, you need to do
>>>>
>>>>    bzr commit -m "merge with trunk"
>>>>
>>>> The merge command will change your local files so a commit is
>>>> necessary.
>>>
>>>
>>> Yes, I know. I let some commits be implicit in this text, somehow
>>> assuming that you knew that I know how to make a change and commit
>>> ;-)
>>>
>>>
>>>>
>>>> I did this just now (including the commit) and pushed to dolfin/logg.
>>>>
>>>>> # Now, I've messed things up, because of (*)
>>>>
>>>> No, nothing is messed up.
>>>>
>>>>> # Begin pain, especially since I have already done the above
>>>>
>>>> No pain. I just did this and it works fine fine fine:
>>>>
>>>>    cd trunk
>>>>    bzr merge ../work
>>>>    bzr commit -m "Merge some work in logg branch to trunk"
>>>>
>>>> Nothing is messed up and there's no pain. The only thing that you
>>>> people need to do to make this work is:
>>>>
>>>> 1. Keep a local bound copy of trunk.
>>>> 2. Merge your changes into trunk *from that directory*
>>>>
>>>> The workflow is the same as before: work in local branches, push/pull
>>>> to your personal lp branch as much as you want or to a multitude of
>>>> other branches that you have on different machines, share with your
>>>> aunt/sister whatever and then just merge that into trunk.
>>>>
>>>> The only thing you can't do is push merges made elsewhere into trunk.
>>>>
>>>
>>> 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.
> 
>> 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.
> 
> 
>> 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.
> 

I agree with the above. Can we all settle on just

  "try hard not to do 'bzr merge lp:dolfin'"

and end this thread?

Garth


> -- 
> Marie
>