On 17/06/11 14:56, Garth N. Wells wrote: > > > On 17/06/11 14:33, Martin Sandve Alnæs wrote: >> 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: >> > > The docs > > http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html > > say > > "Merges do not change revision numbers in a branch, though they do > allocate local revision numbers to newly merged revisions. The only time > Bazaar will change revision numbers in a branch is when you explicitly > ask it to mirror another branch." >
Pushing upstream make trunk a mirror, so the numbers will change. Garth >>> 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. > > Do you have an example? > > We shouldn't be taking this message too literally since revisions are > not being lost. > >> This it is exactly what we've been trying to avoid. >> >> I have no problem communicating with revision ids instead of revision >> numbers. >> > > OK. How about this suggestion: we all try as far as possible to merge > locally, i.e. try not to use 'bzr merge lp:dolfin', but accept that it > will sometimes be required, or much more convenient (see Marie's very > recent message), to merge with lp:dolfin. This approach shouldn't > require using 'checkout' unless ones wishes to adopt this work flow, and > the repository should not be locked to prevent merging. > > Garth > >> Martin > > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : [email protected] > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
