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) ;). Garth > -- > Anders > > > On Fri, Jun 17, 2011 at 11:21:34PM +0200, Anders Logg wrote: >> 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 : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
