ufl team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jun 10, 2011 at 10:33:41PM +0100, Florian Rathgeber wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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.

--
Anders


> Florian
>
> >>>   ~/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.
> >>
> >> So the trunk should always be a checkout?
> >>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~ufl
> > Post to     : ufl@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ufl
> > More help   : https://help.launchpad.net/ListHelp
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk3yjbIACgkQ8Z6llsctAxYQlwCeOtKhsiotjPPNdFaIOKlmiMeH
> mfMAoOEU3yFU5RfTB+MYogv6l1FNmBU+
> =JRK3
> -----END PGP SIGNATURE-----
>