dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

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