bzr: public_branch

bzr: public_branch

[Glenn Morris]

Why I am advised (on the wiki) to set public_branch in branch.conf?
What is a public branch? What difference will I notice if I don't do this?

Why do some instructions include this step:
http://wiki.bazaar.canonical.com/Scenarios/RepeatedContributions

but some don't:
http://wiki.bazaar.canonical.com/BzrUsingBoundBranches

Similarly, what is a submit branch? Neither term appears in the bzr
glossary.

I see this question was asked before, but I can't see an answer.
http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00995.html

TIA.

Re: bzr: public_branch

[Bojan Nikolic]

Hi Glen,

Both of these concepts are related to the bzr send command, so it is
worth reading the help text for this.

The bzr send command basically creates a compact data set that describes
fully that the changes you have made as a developer. The submit branch
defines against what revision those changes should be measured. In other
words bzr send sends the changes you made in your branch as compared to
the submit branch.

In order to calculate those changes, bzr must analyse the submit
branch. Therefore it is most efficient for the submit branch to be
local. 

However, in order for others to make sense of your changes their bzr
must be able to access the branch against which the changes were
calculated. Therefore there must be a public branch with same
information as the submit branch. 

Allowing you to set separate submit and public branches allows you to
have the most efficient setup while others still can use the public
branch to interpret the changes you send.

Best,
Bojan


-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Current emacs blows up on OSX if any control key is pressed

[Randal L. Schwartz]

Some change between Jan 6 and now causes emacs to blow up on OSX
if any control key is pressed.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Current emacs blows up on OSX if any control key is pressed

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On Jan 10, 2010, at 7:41 PM, Randal L. Schwartz wrote:

> 
> Some change between Jan 6 and now causes emacs to blow up on OSX
> if any control key is pressed.


Is that the NS port, I take it?

I just merged the latest changes in and, at least with my branch, I'm not getting any such problems.

The trace would be most helpful in this case, or bisecting the changes until you find the relevant commit.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Current emacs blows up on OSX if any control key is pressed

[Randal L. Schwartz]

>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:

David> On Jan 10, 2010, at 7:41 PM, Randal L. Schwartz wrote:
>> 
>> Some change between Jan 6 and now causes emacs to blow up on OSX
>> if any control key is pressed.


David> Is that the NS port, I take it?

Yes, using the NS stuff.

David> I just merged the latest changes in and, at least with my branch, I'm
David> not getting any such problems.

I'm on Leopard, not Snow Leopard.  I did see some recent changes
to src/nsterm.m that talked about modifier keys.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Current emacs blows up on OSX if any control key is pressed

[chad]

On Jan 10, 2010, at 5:56 PM, Randal L. Schwartz wrote:

>>>>>> "David" == David Reitter <david.reitter@gmail.com> writes:
> 
> David> On Jan 10, 2010, at 7:41 PM, Randal L. Schwartz wrote:
>>> 
>>> Some change between Jan 6 and now causes emacs to blow up on OSX
>>> if any control key is pressed.
> 
> David> Is that the NS port, I take it?
> 
> Yes, using the NS stuff.
> 
> David> I just merged the latest changes in and, at least with my branch, I'm
> David> not getting any such problems.
> 
> I'm on Leopard, not Snow Leopard.  I did see some recent changes
> to src/nsterm.m that talked about modifier keys.

I saw the same thing, poked at it a little while, and got as far as verifying that reverting Chong Yidong's change to src/nsterm.m fixes the problem but not so far as to figure out why.  This is the first time I've been back to email since, and I don't expect to have time to dig for several days, sadly.  I'm building on Snow Leopard (configure --with-ns), in case it matters.

The actual crash is in keyboard.c, in a call to parse_solitary_modifer().  It gets called a few times successfully on startup, and then after all the init is done it tries to pass a zero to SREF() for the switch; I presume because of the init changes in nsterm.m.

I hope this helps.

*Chad


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x00000001000979d8 in parse_solitary_modifier (symbol=0) at keyboard.c:6909
6909	  switch (SREF (name, 0))
(gdb) where
#0  0x00000001000979d8 in parse_solitary_modifier (symbol=0) at keyboard.c:6909
#1  0x0000000100169dab in -[EmacsView keyDown:] (self=0x1008ebf60, _cmd=<value temporarily unavailable, due to optimizations>, theEvent=0x116b4c700) at nsterm.m:4435
#2  0x000000010017bf96 in -[EmacsMenu performKeyEquivalent:] (self=0x0, _cmd=0x7fff80bde7e8, theEvent=0x50f) at nsmenu.m:592
#3  0x00007fff80637db1 in -[NSApplication _handleKeyEquivalent:] ()
#4  0x00007fff805089e1 in -[NSApplication sendEvent:] ()
#5  0x0000000100167b36 in -[EmacsApp sendEvent:] (self=0x10072a590, _cmd=<value temporarily unavailable, due to optimizations>, theEvent=0x116b4c700) at nsterm.m:3977
#6  0x00007fff8049f796 in -[NSApplication run] ()
#7  0x000000010016ab80 in ns_read_socket (terminal=<value temporarily unavailable, due to optimizations>, expected=0, hold_quit=0x7fff5fbfea40) at nsterm.m:3126
#8  0x0000000100097075 in read_avail_input (expected=0) at keyboard.c:7156
#9  0x0000000100097954 in gobble_input (expected=0) at keyboard.c:7067
#10 0x0000000100098d56 in get_input_pending (addr=0x100533378, flags=1) at keyboard.c:7035
#11 0x0000000100098fb2 in swallow_events (do_display=1) at keyboard.c:4468
#12 0x000000010000514b in sit_for (timeout=120, reading=1, do_display=1) at dispnew.c:6622
#13 0x000000010009ead2 in read_char (commandflag=1, nmaps=4, maps=0x7fff5fbfef10, prev_event=4320133130, used_mouse_menu=0x7fff5fbff064, end_time=0x0) at keyboard.c:2970
#14 0x00000001000a03bf in read_key_sequence (keybuf=0x7fff5fbff100, bufsize=30, prompt=4320133130, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9502
#15 0x00000001000a293b in command_loop_1 () at keyboard.c:1643
#16 0x0000000100106857 in internal_condition_case (bfun=0x1000a26f0 <command_loop_1>, handlers=4320204170, hfun=0x10009aaa0 <cmd_error>) at eval.c:1490
#17 0x0000000100099e27 in command_loop_2 () at keyboard.c:1360
#18 0x0000000100106960 in internal_catch (tag=<value temporarily unavailable, due to optimizations>, func=0x100099df0 <command_loop_2>, arg=4320133130) at eval.c:1226
#19 0x000000010009a8b6 in command_loop () at keyboard.c:1339
#20 0x000000010009ad1f in recursive_edit_1 () at keyboard.c:954
#21 0x000000010009aebf in Frecursive_edit () at keyboard.c:1016
#22 0x0000000100090477 in main (argc=1, argv=0x7fff5fbff6d0) at emacs.c:1833

Re: Current emacs blows up on OSX if any control key is pressed

[Chong Yidong]

chad <yandros@gmail.com> writes:

> I saw the same thing, poked at it a little while, and got as far as
> verifying that reverting Chong Yidong's change to src/nsterm.m fixes
> the problem but not so far as to figure out why.  This is the first
> time I've been back to email since, and I don't expect to have time to
> dig for several days, sadly.  I'm building on Snow Leopard (configure
> --with-ns), in case it matters.
>
> The actual crash is in keyboard.c, in a call to
> parse_solitary_modifer().  It gets called a few times successfully on
> startup, and then after all the init is done it tries to pass a zero
> to SREF() for the switch; I presume because of the init changes in
> nsterm.m.

Thanks, I've checked in a fix.  Could you try again?

Re: Current emacs blows up on OSX if any control key is pressed

[Randal L. Schwartz]

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

Chong> Thanks, I've checked in a fix.  Could you try again?

As soon as that shows up on the git mirror, sure.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: Current emacs blows up on OSX if any control key is pressed

[chad]

On Jan 11, 2010, at 6:55 AM, Chong Yidong wrote:

> Thanks, I've checked in a fix.  Could you try again?

That's fixed it, thanks!

*Chad

Re: Current emacs blows up on OSX if any control key is pressed

[Randal L. Schwartz]

>>>>> "chad" == chad  <yandros@gmail.com> writes:

chad> On Jan 11, 2010, at 6:55 AM, Chong Yidong wrote:
>> Thanks, I've checked in a fix.  Could you try again?

chad> That's fixed it, thanks!

Yup.  Works for me too.  Amazing how that goes.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion

Re: bzr: public_branch

[Glenn Morris]

Bojan Nikolic wrote:

> Both of these concepts are related to the bzr send command, so it is
> worth reading the help text for this.

I did read that, and I was hoping it would explain these terms, but
AFAICS it does not, at least not at the level I can understand.

Anyway, thank you very much for your extremely well-written
explanation.