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 : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
