dolfin team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3yjbIACgkQ8Z6llsctAxYQlwCeOtKhsiotjPPNdFaIOKlmiMeH
mfMAoOEU3yFU5RfTB+MYogv6l1FNmBU+
=JRK3
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature