dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

I might follow your example. The bound branch setup is giving me this
error every time I pull into it from a local branch:

  $ bzr pull  ../trunk-logg/
  Unable to obtain lock  held by logg@xxxxxxxxxxxxxxxxxxxx on taotie
  (process #29665), acquired 9 seconds ago.
  See "bzr help break-lock" for more.
  bzr: ERROR: Could not acquire lock "(remote lock)":
  bzr+ssh://bazaar.launchpad.net/%2Bbranch/dolfin/

Strangely, it always works fine in spite of this error message.

--
Anders


On Mon, Dec 03, 2012 at 11:30:37AM +0100, Martin Sandve Alnæs wrote:
>    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 <[1]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?
>
>    >
>    >    On 3 December 2012 10:32, Anders Logg <[1][2]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][3]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][4]https://launchpad.net/~dolfin
>      >    Post to     : [4][5]dolfin@xxxxxxxxxxxxxxxxxxx
>      >    Unsubscribe : [5][6]https://launchpad.net/~dolfin
>      >    More help   : [6][7]https://help.launchpad.net/ListHelp
>      >
>      > Referenser
>      >
>      >    1. mailto:[8]logg@xxxxxxxxx
>      >    2. mailto:[9]logg@xxxxxxxxx
>      >    3. [10]https://launchpad.net/~dolfin
>      >    4. mailto:[11]dolfin@xxxxxxxxxxxxxxxxxxx
>      >    5. [12]https://launchpad.net/~dolfin
>      >    6. [13]https://help.launchpad.net/ListHelp
>
> Referenser
>
>    1. mailto:logg@xxxxxxxxx
>    2. mailto:logg@xxxxxxxxx
>    3. mailto:logg@xxxxxxxxx
>    4. https://launchpad.net/~dolfin
>    5. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>    6. https://launchpad.net/~dolfin
>    7. https://help.launchpad.net/ListHelp
>    8. mailto:logg@xxxxxxxxx
>    9. mailto:logg@xxxxxxxxx
>   10. https://launchpad.net/~dolfin
>   11. mailto:dolfin@xxxxxxxxxxxxxxxxxxx
>   12. https://launchpad.net/~dolfin
>   13. https://help.launchpad.net/ListHelp