dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #23850
Re: [Ufl] [Branch ~ufl-core/ufl/main] 2 revisions removed
On 17/06/11 11:01, Martin Sandve Alnæs wrote:
> On 17 June 2011 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.
>
> That's just the point. Each time a 'revisions removed' email is sent,
> revision ids have been rewritten.
I think you mean the 'revision number'. A bzr 'revision id' looks like
gnw20@xxxxxxxxx-20110616191943-4ealighbcxrf311n
> No commits are lost from the log
> either way, but the revision ids that were on the server branch
> are no longer valid.
>
If we want unique numbers, we need to work cvs-style.
> The unique changeset numbering that bzr does is bazaar specific,
> and not a problem with git or hg because they use checksums.
>
bzr has both. See
http://wiki.bazaar.canonical.com/BzrRevisionSpec
Garth
> Martin
>
>
>>> 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.
>>
>> Garth
>>
>>> --
>>> Anders
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dolfin
>> Post to : dolfin@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dolfin
>> More help : https://help.launchpad.net/ListHelp
>>
References