On 17 June 2011 22:04, Garth N. Wells <[email protected]> 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 : [email protected] > 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 _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
