dolfin team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 17 June 2011 12:17, Garth N. Wells <gnw20@xxxxxxxxx> 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

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.

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.

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

Martin