On 17/06/11 14:33, Martin Sandve Alnæs wrote:
> On 17 June 2011 15:20, Garth N. Wells <gn...@cam.ac.uk> wrote:
>>
>>
>> On 17/06/11 14:05, Martin Sandve Alnęs wrote:
>>> On 17 June 2011 12:17, Garth N. Wells <gn...@cam.ac.uk> wrote:
>>>>
>>>>
>>>> On 17/06/11 11:04, Anders Logg wrote:
>>>>> On Fri, Jun 17, 2011 at 10:49:47AM +0100, Garth N. Wells wrote:
>>>>>>
>>>>>>
>>>>>> On 17/06/11 10:43, Anders Logg wrote:
>>>>>>> On Fri, Jun 17, 2011 at 10:33:23AM +0100, Garth N. Wells wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 17/06/11 10:28, Anders Logg wrote:
>>>>>>>>> On Fri, Jun 17, 2011 at 11:24:21AM +0200, Marie E. Rognes wrote:
>>>>>>>>>>
>>>>>>>>>> On 17. juni 2011, at 11:05, "Garth N. Wells" <gn...@cam.ac.uk> 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 <l...@simula.no> wrote:
>>>>>>>>>>>>>>>>>>>>> On Tue, May 10, 2011 at 03:49:18PM +0200, Martin Sandve
>>>>>>>>>>>>>>>>>>>>> Alnęs wrote:
>>>>>>>>>>>>>>>>>>>>>> On 3 May 2011 18:25, Johannes Ring <joha...@simula.no>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> On Tue, May 3, 2011 at 3:52 PM, Anders Logg
>>>>>>>>>>>>>>>>>>>>>>> <l...@simula.no> 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.
>>>>>>>>>
>>>>>>>>> If Garth can't be bothered, maybe you could describe a specific
>>>>>>>>> example that doesn't work?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Why would I bother with something that I think is pointless and
>>>>>>>> cumbersome? Like Marie, I have never had a problem with the present
>>>>>>>> approach.
>>>>>>>
>>>>>>> I disagree. I think there is a point to it and that it's not
>>>>>>> cumbersome.
>>>>>>>
>>>>>>> I'm just asking for a simple example that I can try. Otherwise it's
>>>>>>> just handwaving.
>>>>>>>
>>>>>>
>>>>>> You made the change, so the onus is on you to make a case, not the other
>>>>>> way around. I'm changing it back because I don't have any inclination to
>>>>>> change unless someone can make a case why. The status quo rules until
>>>>>> there is a consensus.
>>>>>>
>>>>>> What I don't want is to work in a CVS way. See:
>>>>>>
>>>>>> http://wiki.bazaar.canonical.com/BzrForCVSUsers
>>>>>>
>>>>>> It advocates checkout for those who want to keep their CVS work flow,
>>>>>> and says of the approach:
>>>>>>
>>>>>> "This section explains how to perform common CVS behaviours in a Bazaar
>>>>>> world. Unfortunately, this means that I won't be able to teach you many
>>>>>> of the things that are unique to decentralized revision control systems.
>>>>>>
>>>>>> This section covers how to use Bazaar in checkout mode. Reading section
>>>>>> 3, which covers standard Bazaar methods, is highly encouraged."
>>>>>>
>>>>>> Section 3 describes what we've been doing all along.
>>>>>
>>>>> I think you still need to make the case that it doesn't work. I claim
>>>>> it does and if you say that it fails so badly, it should be easy to
>>>>> come up with a single example of where it doesn't work.
>>>>>
>>>>> I've already made the case for the change: to not change history of the
>>>>> common branch (which append_revisions_only prevents).
>>>>>
>>>>
>>>> Which I don't support. I also disagree with the technical point of
>>>> history changes.
>>>>
>>>> A common branch is a centralised concept. I support developers using
>>>> separate feature branches, and using personal branches on Launchpad, and
>>>
>>> I work that way all the time, pushing and pulling branches
>>> between different computers and launchpad branches.
>>>
>>>> the merging this into lp:dolfin.
>>>>
>>>> Garth
>>>
>>> The only difference between the approaches is to merge
>>> your work _into_ lp:dolfin instead of merging lp:dolfin into your work.
>>>
>>
>> I can follow that for simple usage, but I'm often merging between, for
>> example, lp:dolfin and lp:~dolfin-core/dolfin/wells and something in
>> between.
>
> cd work
> bzr merge lp:~dolfin-core/dolfin/wells && bzr commit
> bzr merge ../localfeaturebranch && bzr commit
> bzr merge lp:~dolfin-core/dolfin/yetanotherfeature && bzr commit
> cd ../trunk
> bzr pull lp:dolfin
> bzr merge ../work && bzr commit
> bzr push lp:dolfin
>
> I don't see any problem. Your offline problem was probably
> the checkout vs branch issue I mentioned in the other mail.
> Just unbind the trunk/ branch and there is no such problem.
>
>>> You have educated me on the difference between revision number
>>> and revision id. I thought there was no such thing after some reading.
>>>
>>> I have now tested the command
>>> bzr branch work -r <revision-id> oldstate
>>> and it works perfectly, with revision-id being a revision
>>> previously 'hidden' behind a merge.
>>>
>>
>> I use 'bzr visualise' and it doesn't hide anything. I see the parallel
>> lines that we used to have with the Mecurial web interface.
>>
>> On the command line
>>
>> bzr log --include-merges
>>
>> has the same effect.
>>
>>> Thus, if everybody communicates unique revisions with
>>> the revision id and not the revision number, there is no
>>> technical difference between the approaches.
>>>
>>> It is still more convenient to communicate with revision numbers though...
>>>
>
>
> This statement is wrong:
>
The docs
http://doc.bazaar.canonical.com/latest/en/user-guide/zen.html
say
"Merges do not change revision numbers in a branch, though they do
allocate local revision numbers to newly merged revisions. The only time
Bazaar will change revision numbers in a branch is when you explicitly
ask it to mirror another branch."
>> This will still work if one says #xxx on lp:dolfin. The bzr docs say
>> that the revision numbers on given branch will never change.
>>
>> Garth
>
> The revision numbers on the lp:dolfin branch _do_ change
> every time you get this "2 revisions removed from branch" mail.
Do you have an example?
We shouldn't be taking this message too literally since revisions are
not being lost.
> This it is exactly what we've been trying to avoid.
>
> I have no problem communicating with revision ids instead of revision numbers.
>
OK. How about this suggestion: we all try as far as possible to merge
locally, i.e. try not to use 'bzr merge lp:dolfin', but accept that it
will sometimes be required, or much more convenient (see Marie's very
recent message), to merge with lp:dolfin. This approach shouldn't
require using 'checkout' unless ones wishes to adopt this work flow, and
the repository should not be locked to prevent merging.
Garth
> Martin
_______________________________________________
Mailing list: https://launchpad.net/~dolfin
Post to : dolfin@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dolfin
More help : https://help.launchpad.net/ListHelp
