On 17/06/11 14:05, Martin Sandve Alnæs wrote: > On 17 June 2011 12:17, Garth N. Wells <[email protected]> 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 > > I work that way all the time, pushing and pulling branches > between different computers and launchpad branches. > >> the merging this into lp:dolfin. >> >> Garth > > The only difference between the approaches is to merge > your work _into_ lp:dolfin instead of merging lp:dolfin into your work. >
I can follow that for simple usage, but I'm often merging between, for example, lp:dolfin and lp:~dolfin-core/dolfin/wells and something in between. > You have educated me on the difference between revision number > and revision id. I thought there was no such thing after some reading. > > I have now tested the command > bzr branch work -r <revision-id> oldstate > and it works perfectly, with revision-id being a revision > previously 'hidden' behind a merge. > I use 'bzr visualise' and it doesn't hide anything. I see the parallel lines that we used to have with the Mecurial web interface. On the command line bzr log --include-merges has the same effect. > Thus, if everybody communicates unique revisions with > the revision id and not the revision number, there is no > technical difference between the approaches. > > It is still more convenient to communicate with revision numbers though... > This will still work if one says #xxx on lp:dolfin. The bzr docs say that the revision numbers on given branch will never change. Garth > Martin _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
