dolfin team mailing list archive

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

On 17/06/11 10:27, Anders Logg wrote:
> On Fri, Jun 17, 2011 at 10:22:51AM +0100, Garth N. Wells wrote:
>>
>>
>> On 17/06/11 10:13, Anders Logg wrote:
>>> On Fri, Jun 17, 2011 at 10:05:04AM +0100, Garth N. Wells 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.
>>>
>>> I agree it was simpler before, but believe one can still accomplish
>>> the same type of workflow (just with different commands).
>>>
>>
>> For what purpose? I can't see any.
> 
> To avoid the "revisions removed" commit and keep history.
> 

I might not have said this 100 times yet, but history *is* kept. I don't
care about the "revisions removed" email that Launchpad sends.

Garth

> Show me an example that doesn't work. If I can't get it to work I'll
> agree and just drop this.
> 
> Describing a scenario that doesn't work should not take more time than
> logging into the Launchpad ftp and changing that flag (again). ;-)
> 
> --
> Anders