dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

The most important reason in my opinion is to preserve the ordering of
states the trunk has been in, such that bugs can be tracked down more
easily when they're discovered a while after they were introduced, with
nontrivial merging in between. I had this problem in the summer once:
because of several large merges which destroyed trunk ordering I had no way
to know which changes happened in which order in trunk between a known good
and a known bad revision with several weeks between.

As for network overhead, there is no such thing when branching locally, and
it doesn't have to change your workflow apart from the final merge+push.

Personally I have local branches trunk, work, scratch with a shared
repository.

While working I can merge from trunk into my work or have whatever workflow
I want:
  cd work
  bzr pull ../trunk
  work and commit however you want
  bzr merge ../trunk
  work and commit some more

but before pushing I can merge the two in scratch to get the right ordering:
  cd scratch
  bzr pull ../trunk  # with --overwrite if necessary
  bzr merge ../work
  bzr commit -m'merge'
  bzr push lp:dolfin
this preserves the trunk numbering of commits.

Martin


On 3 December 2012 10:32, Anders Logg <logg@xxxxxxxxx> wrote:

> On Mon, Dec 03, 2012 at 09:22:55AM +0000, Garth N. Wells wrote:
> > On Mon, Dec 3, 2012 at 9:14 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> > > On Mon, Dec 03, 2012 at 10:08:00AM +0100, Johan Hake wrote:
> > >> In principle I do not have any objections. Also if you mess up your
> > >> commands it is fairly simple to just branch a new lp:dolfin and merge
> > >> from that, before it is pushed back.
> > >
> > > The problem is that the thing I messed up was the push to
> > > trunk. So there was no need or any opportunity to branch a new
> > > lp:dolfin. The damage was already done.
> > >
> >
> > Branching a new lp:dolfin is a problem on slow connections.
> >
> > >> However, I see this mainly as a big short coming of bzr and/or
> buildbot.
> > >> Comparing if one revision is newer than another one in a distributed
> > >> version control system should be a solved problem...
> > >
> > > It's a solved problem if we set that flag.
> >
> > So the buildbot determines an individual developer's work flow?
>
> Yes, as long as there's no simple fix for the buildbot.
>
> I don't really care about the numbering issue anymore, as long as it
> works. Right now, it seems that doing `cd trunk && bzr merge ../dev`
> instead of `cd dev && bzr merge ../trunk && bzr push trunk` is an
> easier fix than figuring out how to get the buildbot (or bzr?) to use
> timestamps instead of changeset numbers.
>
> --
> Anders
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>