dolfin team mailing list archive

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

On 17/06/11 14:56, Garth N. Wells wrote:
> 
> 
> On 17/06/11 14:33, Martin Sandve Alnæs wrote:
>> On 17 June 2011 15:20, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
>>>
>>>
>>> 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.
>>
>> cd work
>> bzr merge lp:~dolfin-core/dolfin/wells && bzr commit
>> bzr merge ../localfeaturebranch && bzr commit
>> bzr merge lp:~dolfin-core/dolfin/yetanotherfeature && bzr commit
>> cd ../trunk
>> bzr pull lp:dolfin
>> bzr merge ../work && bzr commit
>> bzr push lp:dolfin
>>
>> I don't see any problem. Your offline problem was probably
>> the checkout vs branch issue I mentioned in the other mail.
>> Just unbind the trunk/ branch and there is no such problem.
>>
>>>> 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 statement is wrong:
>>
> 
> The docs
> 
>     http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html
> 
> say
> 
> "Merges do not change revision numbers in a branch, though they do
> allocate local revision numbers to newly merged revisions. The only time
> Bazaar will change revision numbers in a branch is when you explicitly
> ask it to mirror another branch."
> 

Pushing upstream make trunk a mirror, so the numbers will change.

Garth

>>> 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
>>
>> The revision numbers on the lp:dolfin branch _do_ change
>> every time you get this "2 revisions removed from branch" mail.
> 
> Do you have an example?
> 
> We shouldn't be taking this message too literally since revisions are
> not being lost.
> 
>> This it is exactly what we've been trying to avoid.
>>
>> I have no problem communicating with revision ids instead of revision numbers.
>>
> 
> OK. How about this suggestion: we all try as far as possible to merge
> locally, i.e. try not to use 'bzr merge lp:dolfin', but accept that it
> will sometimes be required, or much more convenient (see Marie's very
> recent message), to merge with lp:dolfin. This approach shouldn't
> require using 'checkout' unless ones wishes to adopt this work flow, and
> the repository should not be locked to prevent merging.
> 
> Garth
> 
>> Martin
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp