On Fri, Jun 17, 2011 at 11:17:24AM +0100, Garth N. Wells wrote: > > > On 17/06/11 11:04, Anders Logg wrote: > > 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" <[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. > >>> > >> > >> 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). > > > > Which I don't support. I also disagree with the technical point of > history changes. > > A common branch is a centralised concept. I support developers using > separate feature branches, and using personal branches on Launchpad, and > the merging this into lp:dolfin.
So do I, but I claim this is all still possible. I may be wrong but haven't yet seen an example that fails. -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
