dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jun 17, 2011 at 10:34:13AM +0200, 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 <logg@xxxxxxxxx> wrote:
> > >>>>>>>> On Tue, May 10, 2011 at 03:49:18PM +0200, Martin Sandve Alnæs wrote:
> > >>>>>>>>> On 3 May 2011 18:25, Johannes Ring <johannr@xxxxxxxxx> wrote:
> > >>>>>>>>>> On Tue, May 3, 2011 at 3:52 PM, Anders Logg <logg@xxxxxxxxx> 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. ;-)

I've changed it back now to help you debug your bzr commands. :-)

--
Anders


> 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.
>
> 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
>