dolfin team mailing list archive

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

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.

Garth



>> --
>> Anders
> 
> 
> Florian
> 
>>>>>>   ~/dev/fenics/ufl/trunk/ - local checkout of central ufl branch lp:ufl
>>>>>>   ~/dev/fenics/ufl/work/ - local branch where I usually do my work
>>>>>> (  ~/dev/fenics/ufl/somefeature/ - local branch with some half
>>>>>> finished feature if needed)
>>>>>>
>>>>>> One branch locally for normal work, one checkout locally mirroring the
>>>>>> central trunk, and any number of branches locally and on launchpad for
>>>>>> alternative half-finished work.
>>>>>>
>>>>>> Then I do:
>>>>>>
>>>>>> cd .../ufl/work/
>>>>>> <work work work>
>>>>>> bzr push lp:ufl # fails because Bob has pushed stuff
>>>>>>
>>>>>> cd ../trunk # should have no local changes now
>>>>>> bzr update # gets the latest version of lp:ufl
>>>>>> bzr merge ../work # merge my work into trunk
>>>>>> bzr commit -m'Merge my work on <superfeature>.' # Commit merge into trunk
>>>>>>
>>>>>> If trunk is a _checkout_ and not just a _branch_, the last commit here
>>>>>> will actually both commit and push the merge to lp:ufl directly.
>>>>>
>>>>> So the trunk should always be a checkout?
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~ufl
>>>> Post to     : ufl@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~ufl
>>>> More help   : https://help.launchpad.net/ListHelp
>>

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