dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, Jun 17, 2011 at 11:17:24AM +0100, Garth N. Wells 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" <gnw20@xxxxxxxxx> 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 <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. ;-)
> >>>>>>>>
> >>>>>>>
> >>>>>>> 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
> the merging this into lp:dolfin.

So do I, but I claim this is all still possible. I may be wrong but
haven't yet seen an example that fails.

--
Anders