On 17/06/11 10:13, Anders Logg wrote: > On Fri, Jun 17, 2011 at 10:05:04AM +0100, Garth N. Wells 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 <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. ;-) >>> >> >> 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. >> >>> 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. > > I agree it was simpler before, but believe one can still accomplish > the same type of workflow (just with different commands). >
For what purpose? I can't see any. Garth > Can you sketch a specific example that I can try? > > -- > Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
