On Fri, Jun 17, 2011 at 10:34:13AM +0200, 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 <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. > > >> > > > > > > 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. ;-)
I've changed it back now to help you debug your bzr commands. :-) -- Anders > 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. > > 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 > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
