dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

I think we should make it possible to allow developer to push merged branches 
that screw up the revision numbers...

I will stick to the checked out (mirrored main) repository and merge into that 
one, as I think that workflow is cleaner and nicer. I do not consider that 
being cvs like.

If other think that is too big of a hassle, well then be it. I will just 
silently grunt inside when ever I see:

   35 revisions were removed from the branch.

The revisions are not lost, and one can access and look at them using 
--include-merges in the bzr log command.

Johan


On Friday June 17 2011 03:56:41 Garth N. Wells wrote:
> On 17/06/11 11:01, Martin Sandve Alnæs wrote:
> > On 17 June 2011 11:05, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> >> On 17/06/11 09:34, Anders Logg wrote:
> >>> On Fri, Jun 17, 2011 at 08:46:46AM +0100, Garth N. Wells wrote:
> >>>> On 17/06/11 08:35, Garth N. Wells wrote:
> >>>>> On 12/06/11 21:36, Anders Logg wrote:
> >>>>>> On Fri, Jun 10, 2011 at 10:33:41PM +0100, Florian Rathgeber wrote:
> >>>>>> 
> >>>>>> On 11/05/11 15:43, Anders Logg wrote:
> >>>>>>>>> On Wed, May 11, 2011 at 03:57:52PM +0200, Anders Logg wrote:
> >>>>>>>>>> On Tue, May 10, 2011 at 10:57:07PM +0200, Martin Sandve Alnæs 
wrote:
> >>>>>>>>>>> On 10 May 2011 17:52, Anders Logg <logg@xxxxxxxxx> wrote:
> >>>>>>>>>>>> On Tue, May 10, 2011 at 03:49:18PM +0200, Martin Sandve Alnæs 
wrote:
> >>>>>>>>>>>>> On 3 May 2011 18:25, Johannes Ring <johannr@xxxxxxxxx> wrote:
> >>>>>>>>>>>>>> On Tue, May 3, 2011 at 3:52 PM, Anders Logg <logg@xxxxxxxxx> 
wrote:
> >>>>>>>>>>>>>>> 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. :-)
> >>>>>>>>>>>>>> 
> >>>>>>>>>>>>>> I think I just bring up the following instructions (which I 
think looks good):
> >>>>>>>>>>>>>>  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.
> >>>>>>>>>>>> 
> >>>>>>>>>>>> So if I'm Bob and Alice has pushed some changes to the main
> >>>>>>>>>>>> branch 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
> >>>>>>>>>> 
> >>>>>>>>>> Is this a repository? Or is it just a directory named ufl inside
> >>>>>>>>>> which 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.
> >>>>>> 
> >>>>>> 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
> >>>>>> 
> >>>>>>> Thanks. I've fixed this now for DOLFIN, FFC, UFL, UFC, FIAT.
> >>>>> 
> >>>>> Could you please undo this. I can't push changes from my personal
> >>>>> branch to DOLFIN. I don't see that this change has any use. (If we
> >>>>> want cvs, then we should use cvs.)
> >>>>> 
> >>>>> I've tried to follow the instructions to undo the change, but can't
> >>>>> get it to work.
> >>>> 
> >>>> I've undone this for DOLFIN so I could push my changes.
> >>> 
> >>> You should have figured out how to do the merge properly instead. We
> >>> should add it back to force everyone to learn how to use bzr. ;-)
> >> 
> >> Merge is 'bzr merge xxx'. That's a proper merge.
> >> 
> >>> The point is to not rewrite history for the common repo. This is not
> >>> the same as cvs. It's still distributed but it means merges have to be
> >>> done more carefully.
> >> 
> >> There is no history re-writing. It's just adding changesets. Unique
> >> changeset numbering that bzr does will always be problematic with
> >> distributed version control. If you want a unique identifier, use the
> >> revision id.
> > 
> > That's just the point. Each time a 'revisions removed' email is sent,
> > revision ids have been rewritten. No commits are lost from the log
> > either way, but the revision ids that were on the server branch
> > are no longer valid.
> > 
> > The unique changeset numbering that bzr does is bazaar specific,
> > and not a problem with git or hg because they use checksums.
> 
> I've had a look, and bzr and hg are the same. 'hg log' gives something
> like:
> 
>   changeset:   177:11429e0ea211
>   user:        User
>   date:        Tue Jun 14 18:05:12 2011 +0100
>   summary:     Do something
> 
> The revision number is 177, and the id is 11429e0ea211. The revision
> number may change, but the id is unique.
> 
> Doing 'bzr log --show-ids':
> 
>   revno: 5944
>  revision-id: gnw20@xxxxxxxxx-20110617070912-hxk2utq5xtprs3nu
>   parent: gnw20@xxxxxxxxx-20110616232252-6h45lemz35m6hffp
>   committer: Garth N. Wells <gnw20@xxxxxxxxx>
>   branch nick: dolfin-wells
>   timestamp: Fri 2011-06-17 08:09:12 +0100
>   message:
>     Add missing include
> 
> The revision numbner is 5944, and the id is
> gnw20@xxxxxxxxx-20110617070912-hxk2utq5xtprs3nu. The revision number may
> change, but the id is unique.
> 
> Garth
> 
> > Martin
> > 
> >>> Just do this next time and it should work:
> >>> 
> >>> 1. Make sure you have a local bound dolfin branch:
> >>>   bzr checkout lp:dolfin trunk
> >>> 
> >>> 2. Merge *from* that branch, not push to it:
> >>>   cd trunk
> >>>   bzr merge <path to your local repo>
> >>>   bzr commit -m merge
> >> 
> >> It just worked before. It was simpler, and I could work against any
> >> branch, like by personal branch under dolfin-core.
> >> 
> >> Garth
> >> 
> >>> --
> >>> Anders
> >> 
> >> _______________________________________________
> >> Mailing list: https://launchpad.net/~dolfin
> >> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~dolfin
> >> More help   : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp