dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 17/06/11 14:05, Martin Sandve Alnæs wrote:
> 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.
> 

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.

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


> Martin