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. ;-) -- 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 : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
