dolfin team mailing list archive

["Marie E. Rognes" <meg@xxxxxxxxx>]

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. 

--
Marie



> Garth
> 
>> --
>> Anders
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp