Subject: Re: [Ufl] [Branch ~ufl-core/ufl/main] 2 revisions removed

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 3 May 2011 15:24:00 +0200

I don't like this history rewriting, what are we doing wrong (I'm not
the only one producing this)?

This means the commit numbers in the central repository are
changing... I don't think this is how it's supposed to be done.

Martin

On 3 May 2011 15:19,  <[email-masked]> wrote:
> 2 revisions were removed from the branch.
>
> --
> lp:ufl
> https://code.launchpad.net/~ufl-core/ufl/main
>
> Your team UFL Core Team is subscribed to branch lp:ufl.
> To unsubscribe from this branch go to https://code.launchpad.net/~ufl-core/ufl/main/+edit-subscription
>

---

From: Anders Logg <[email-masked]>
Date: Tue, 3 May 2011 15:52:50 +0200

It happens to me a lot. Johannes has tried to explain to me why it
happens a number of times but I still don't understand why.

Maybe he can try to explain it again to you and then I might also
understand. :-)

--
Anders

On Tue, May 03, 2011 at 03:24:00PM +0200, Martin Sandve Alnæs wrote:
> _______________________________________________
> Mailing list: https://launchpad.net/~ufl
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~ufl
> More help   : https://help.launchpad.net/ListHelp

---

From: Johannes Ring <[email-masked]>
Date: Tue, 3 May 2011 18:25:19 +0200

> Maybe he can try to explain it again to you and then I might also

I think I just bring up the following instructions (which I think looks good):

  http://wiki.squid-cache.org/BzrInstructions

Johannes

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 10 May 2011 15:49:18 +0200

>  http://wiki.squid-cache.org/BzrInstructions

Thanks Johannes.

Basically the problem is that bazaar numbers commits with contiguous
integers, and when Bob and Alice works locally they will get the same
commit ids for different commits. When you stand in branch Alice and
merge from branch Bob, the commit numbers of branch Alice are
conserved and a single new merge commit is recorded on top there. The
commit numbers from branch Bob are lost in the merge. Therefore, to
conserve the commit ids in the central branch, you have to merge from
your own branch into the server branch, not the other way around.
Otherwise we can never safely use the commit revisions from the
central branch, since they may change every time somebody merges the
'wrong way'.

This problem does not occur with hg or git, because they use a hash
value to identify a each commit.

Martin

---

From: Anders Logg <[email-masked]>
Date: Tue, 10 May 2011 17:52:44 +0200

> value to identify a each commit.

So if I'm Bob and Alice has pushed some changes to the main branch
before me, which exact commands should I write?

--
Anders

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Tue, 10 May 2011 22:57:07 +0200

> before me, which exact commands should I write?

Depends on how you set up your repositories, where your branches are
located, etc...

You really have to read up on it and try it out a bit to understand
it, and I doubt I can write it better than what Johannes linked to +
the bazaar docs.

I plan to keep a local repository with multiple branches like this:
  ~/dev/fenics/ufl/ - local ufl repository
  ~/dev/fenics/ufl/trunk/ - local checkout of central ufl branch lp:ufl
  ~/dev/fenics/ufl/work/ - local branch where I usually do my work
(  ~/dev/fenics/ufl/somefeature/ - local branch with some half
finished feature if needed)

One branch locally for normal work, one checkout locally mirroring the
central trunk, and any number of branches locally and on launchpad for
alternative half-finished work.

Then I do:

cd .../ufl/work/
<work work work>
bzr push lp:ufl # fails because Bob has pushed stuff
cd ../trunk # should have no local changes now
bzr update # gets the latest version of lp:ufl
bzr merge ../work # merge my work into trunk
bzr commit -m'Merge my work on <superfeature>.' # Commit merge into trunk

If trunk is a _checkout_ and not just a _branch_, the last commit here
will actually both commit and push the merge to lp:ufl directly.

To use bazaar correctly, everybody really needs to read up on it and
understand the differences beteween e.g. a checkout and branch.
Otherwise nobody can ever trust FEniCS revision numbers to mean
anything... I'm a bit surprised on this bazaar 'feature'.

Martin

---

From: Johan Hake <[email-masked]>
Date: Tue, 10 May 2011 14:22:38 -0700

> bzr commit -m'Merge my work on <superfeature>.' # Commit merge into trunk

Thanks for the nice walkthrough. What you are writing make sense.

Keeping the habit from hg and git I think both I and others have followed:

 bzr pull
 bzr merge
 bzr commit -'merge'
 bzr push lp:ufl

But as you says that will erase commits from the main branch. We have this 
situation in the main DOLFIN branch where the last push erased 29 commits... 
Is there anyway to redo that last merge/commit?

Johan

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Wed, 11 May 2011 12:48:28 +0200

> Is there anyway to redo that last merge/commit?

Not sure. If you have the original 29 commits in one of your existing
branches, you could possibly merge trunk into that one and push to get
back to the original numbering.

But probably not worth it. I assume you dont actually mean erased, but
"removed" as bazaar calls it. Then they are just moved to under the
relevant merge commit. You can see them with "bzr log -n0 | less".

---

From: Anders Logg <[email-masked]>
Date: Wed, 11 May 2011 15:57:52 +0200

>   ~/dev/fenics/ufl/ - local ufl repository

Is this a repository? Or is it just a directory named ufl inside which
you keep a number of different repositories?

> will actually both commit and push the merge to lp:ufl directly.

So the trunk should always be a checkout?

--
Anders

---

From: Anders Logg <[email-masked]>
Date: Wed, 11 May 2011 16:43:50 +0200

> you keep a number of different repositories?

Talked to Martin during lunch. Here's a simple summary of what needs
to be done to set things up correctly (Cc to dolfin-dev so everyone else
sees this):

  bzr init-repo foo
  cd foo
  bzr checkout lp:foo trunk
  bzr branch trunk work

We should add this to the developer page in the documentation.

Everyone should adopt this and we should pick on anyone that pushes
removed changesets.

--
Anders

---

From: Florian Rathgeber <[email-masked]>
Date: Fri, 10 Jun 2011 22:33:41 +0100

> Everyone should adopt this and we should pick on anyone that pushes

There's an effective way to make these pushes impossible and disable the
bzr "feature" of renumbering revisions: set the option
append_revisions_only=True in <yourbranch>/.bzr/branch/branch.conf

For branches on launchpad this works as follows:
1) sftp bazaar.launchpad.net
     cd ~user/project/branch/.bzr/branch
     get branch.conf
2) edit the downloaded file, adding append_revisions_only = True
3)   put branch.conf

I suggest doing this for all branches on launchpad to enforce consistent
revision numbers.

More background: http://stackoverflow.com/questions/5413602

Florian

---

From: Anders Logg <[email-masked]>
Date: Sun, 12 Jun 2011 22:36:42 +0200

On Fri, Jun 10, 2011 at 10:33:41PM +0100, Florian Rathgeber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Thanks. I've fixed this now for DOLFIN, FFC, UFL, UFC, FIAT.

--
Anders

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk3yjbIACgkQ8Z6llsctAxYQlwCeOtKhsiotjPPNdFaIOKlmiMeH
> mfMAoOEU3yFU5RfTB+MYogv6l1FNmBU+
> =JRK3
> -----END PGP SIGNATURE-----
>