dolfin team mailing list archive

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

Right, your way gives the same end result. Some times I do that, although I
don't bind the trunk branch but push to lp:dolfin explicitly. My way is
just a habit after being burned on complex merges, usually not necessary,
but I like the extra control, in particular if new commits arrive in
lp:dolfin before I get to push.


On 3 December 2012 11:18, Anders Logg <logg@xxxxxxxxx> wrote:

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