dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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.
> >>