On Fri, Jun 17, 2011 at 11:37:02PM +0100, Garth N. Wells wrote: > > > On 17/06/11 23:26, Anders Logg wrote: > > Let me add to this that I don't think the removed revisions are a very > > big problem. I think it's cleaner without them, but it's a fairly > > small issue. > > > > But what I don't like are the false claims that it doesn't work to use > > a normal bzr workflow (which it obviously does) and that it's a big > > hassle to make it work (which it certainly isn't). > > > > Perhaps we can make the following compromise: > > > > 0. Admit that I'm right (it works and it's not a hassle) > > > > 1. Skip append_revisions_only for now > > > > 2. Try to avoid removed revisions > > > > 3. Maybe add back append_revisions_only at some point in the future > > when everyone has learned to do (2). > > > > Will that work? > > > > Point (0) is of particular importance. ;-) > > > > I'll concede (0) to you if we agree on (2) ;).
That's all I'm asking. As always, (0) is more important to me than (2). ;-) PS: append_revisions_only is currently set to True. I used it when testing Marie's merge scenario, but feel free to change it. -- Anders > Garth > > >> On Fri, Jun 17, 2011 at 10:57:15PM +0200, Martin Sandve Alnæs wrote: > >>>>> 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. > >> > >> That's what both Launchpad and the bzr manual are claiming. > >> > >>>> How can there be a merge to push if there has been no merge? > >> > >> There can have been as many merges as you want downstream, as in back > >> and forth between your local repositories, your personal repository at > >> Launchpad and from lp:dolfin into any of your repositories. > >> > >> Then what I'm asking is not to push those merges directly to > >> lp:dolfin, but instead merge all of that mess into lp:dolfin. > >> > >>> 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) > >> > >> This is what I suggest (modulo the last push, see below). > >> > >>> 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. > >> > >> Thanks, I didn't know that. > >> > >> Anyway, my point remains: we shouldn't push merges made into other > >> repositories to lp:dolfin. That repository should remain clean. > >> > >> And let me repeat: it's not a hassle. The same number of commands as > >> usual (one less if using a bound trunk), just a different order in > >> another directory. > >> _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
