dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Dec 03, 2012 at 11:12:02AM +0100, Martin Sandve Alnæs wrote:
>    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,

Yes, bzr init-repo is very useful.

>    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

I do the same.

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

But here I do

  cd trunk
  bzr update
  bzr merge ../work
  bzr commit

My trunk branch is bound to lp:dolfin.

This seems easier than having an extra scratch branch, but I assume
both are equivalent when it comes to changeset ordering in trunk?

--
Anders



>    Martin
>
>    On 3 December 2012 10:32, Anders Logg <[1]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 <[2]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.
>
>    _______________________________________________
>    Mailing list: [3]https://launchpad.net/~dolfin
>    Post to     : [4]dolfin@xxxxxxxxxxxxxxxxxxx
>    Unsubscribe : [5]https://launchpad.net/~dolfin
>    More help   : [6]https://help.launchpad.net/ListHelp
>
> Referenser
>
>    1. mailto:logg@xxxxxxxxx
>    2. mailto:logg@xxxxxxxxx
>    3. https://launchpad.net/~dolfin
>    4. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>    5. https://launchpad.net/~dolfin
>    6. https://help.launchpad.net/ListHelp