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 <l...@simula.no> wrote: > >>>> On Tue, May 10, 2011 at 03:49:18PM +0200, Martin Sandve Alnæs wrote: > >>>>> On 3 May 2011 18:25, Johannes Ring <joha...@simula.no> wrote: > >>>>>> On Tue, May 3, 2011 at 3:52 PM, Anders Logg <l...@simula.no> 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 : u...@lists.launchpad.net > > 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----- > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
