On Fri, Jun 17, 2011 at 10:49:47AM +0100, Garth N. Wells wrote: > > > On 17/06/11 10:43, Anders Logg wrote: > > 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" <gn...@cam.ac.uk> 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. > >>>>> > >>>> > >>>> 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. > > > > You made the change, so the onus is on you to make a case, not the other > way around. I'm changing it back because I don't have any inclination to > change unless someone can make a case why. The status quo rules until > there is a consensus. > > What I don't want is to work in a CVS way. See: > > http://wiki.bazaar.canonical.com/BzrForCVSUsers > > It advocates checkout for those who want to keep their CVS work flow, > and says of the approach: > > "This section explains how to perform common CVS behaviours in a Bazaar > world. Unfortunately, this means that I won't be able to teach you many > of the things that are unique to decentralized revision control systems. > > This section covers how to use Bazaar in checkout mode. Reading section > 3, which covers standard Bazaar methods, is highly encouraged." > > Section 3 describes what we've been doing all along.
I think you still need to make the case that it doesn't work. I claim it does and if you say that it fails so badly, it should be easy to come up with a single example of where it doesn't work. I've already made the case for the change: to not change history of the common branch (which append_revisions_only prevents). -- 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
