On Fri, Jun 17, 2011 at 10:33:23AM +0100, Garth N. Wells wrote: > > > On 17/06/11 10:28, Anders Logg wrote: > > On Fri, Jun 17, 2011 at 11:24:21AM +0200, Marie E. Rognes wrote: > >> > >> On 17. juni 2011, at 11:05, "Garth N. Wells" <[email protected]> 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 <[email protected]> wrote: > >>>>>>>>>>>>> On Tue, May 10, 2011 at 03:49:18PM +0200, Martin Sandve Alnæs > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> On 3 May 2011 18:25, Johannes Ring <[email protected]> wrote: > >>>>>>>>>>>>>>> On Tue, May 3, 2011 at 3:52 PM, Anders Logg <[email protected]> > >>>>>>>>>>>>>>> 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. > >>> > >> > >> After trying the no-revisions-removed approach for a while, I also find it > >> significantly more cumbersome, especially with the main vs personal > >> branches. > >> > >> Although I see the point, I never encountered a problem with the changing > >> revision numbers before. > > > > If Garth can't be bothered, maybe you could describe a specific > > example that doesn't work? > > > > Why would I bother with something that I think is pointless and > cumbersome? Like Marie, I have never had a problem with the present > approach.
I disagree. I think there is a point to it and that it's not cumbersome. I'm just asking for a simple example that I can try. Otherwise it's just handwaving. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
