I think we should make it possible to allow developer to push merged branches that screw up the revision numbers...
I will stick to the checked out (mirrored main) repository and merge into that one, as I think that workflow is cleaner and nicer. I do not consider that being cvs like. If other think that is too big of a hassle, well then be it. I will just silently grunt inside when ever I see: 35 revisions were removed from the branch. The revisions are not lost, and one can access and look at them using --include-merges in the bzr log command. Johan On Friday June 17 2011 03:56:41 Garth N. Wells wrote: > On 17/06/11 11:01, Martin Sandve Alnæs wrote: > > On 17 June 2011 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. > > > > That's just the point. Each time a 'revisions removed' email is sent, > > revision ids have been rewritten. No commits are lost from the log > > either way, but the revision ids that were on the server branch > > are no longer valid. > > > > The unique changeset numbering that bzr does is bazaar specific, > > and not a problem with git or hg because they use checksums. > > I've had a look, and bzr and hg are the same. 'hg log' gives something > like: > > changeset: 177:11429e0ea211 > user: User > date: Tue Jun 14 18:05:12 2011 +0100 > summary: Do something > > The revision number is 177, and the id is 11429e0ea211. The revision > number may change, but the id is unique. > > Doing 'bzr log --show-ids': > > revno: 5944 > revision-id: gn...@cam.ac.uk-20110617070912-hxk2utq5xtprs3nu > parent: gn...@cam.ac.uk-20110616232252-6h45lemz35m6hffp > committer: Garth N. Wells <gn...@cam.ac.uk> > branch nick: dolfin-wells > timestamp: Fri 2011-06-17 08:09:12 +0100 > message: > Add missing include > > The revision numbner is 5944, and the id is > gn...@cam.ac.uk-20110617070912-hxk2utq5xtprs3nu. The revision number may > change, but the id is unique. > > Garth > > > Martin > > > >>> 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. > >> > >> Garth > >> > >>> -- > >>> 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~dolfin > Post to : dolfin@lists.launchpad.net > Unsubscribe : https://launchpad.net/~dolfin > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
