On 17 June 2011 15:20, Garth N. Wells <[email protected]> wrote: > > > 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.
cd work bzr merge lp:~dolfin-core/dolfin/wells && bzr commit bzr merge ../localfeaturebranch && bzr commit bzr merge lp:~dolfin-core/dolfin/yetanotherfeature && bzr commit cd ../trunk bzr pull lp:dolfin bzr merge ../work && bzr commit bzr push lp:dolfin I don't see any problem. Your offline problem was probably the checkout vs branch issue I mentioned in the other mail. Just unbind the trunk/ branch and there is no such problem. >> 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 statement is wrong: > 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 The revision numbers on the lp:dolfin branch _do_ change every time you get this "2 revisions removed from branch" mail. This it is exactly what we've been trying to avoid. I have no problem communicating with revision ids instead of revision numbers. Martin _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
