Re: ATTENTION: magic-removal being merged to trunk TODAY

Adrian Holovaty wrote: > Attention all users of the Django development version (a.k.a. trunk)! > > We are merging the magic-removal branch to trunk this evening, Monday, May 1. > > Do not "svn update" your Django code unless you're ready to convert > your code to magic-removal syntax. > > If yo

ANN: magic-removal branch merged to trunk

All, We've merged the magic-removal branch to trunk. All Django development will focus primarily on the branch formerly known as magic-removal, and all documentation on djangoproject.com will focus on the development version. Previous versions of the documentation are here: http://www.djang

Re: ATTENTION: magic-removal being merged to trunk TODAY

May I be the first to say: YEAY! On 5/1/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Attention all users of the Django development version (a.k.a. trunk)! > > We are merging the magic-removal branch to trunk this evening, Monday, May 1. > > Do not "svn update" your Django code unless you're

ATTENTION: magic-removal being merged to trunk TODAY

Attention all users of the Django development version (a.k.a. trunk)! We are merging the magic-removal branch to trunk this evening, Monday, May 1. Do not "svn update" your Django code unless you're ready to convert your code to magic-removal syntax. If you "svn update" by mistake and aren't ye

Re: OneToOneField behavior doesn't match docs

On 5/1/06, medhat <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] wrote: > > Joseph Kocherhans wrote: > > > The current trunk and magic-removal docs say this about OneToOneField: > > > > [snip] > > > > No feedback, so I've commited a patch. OneToOneField now behaves like > > ForeignKey for addi

Re: OneToOneField behavior doesn't match docs

[EMAIL PROTECTED] wrote: > Joseph Kocherhans wrote: > > The current trunk and magic-removal docs say this about OneToOneField: > > [snip] > > No feedback, so I've commited a patch. OneToOneField now behaves like > ForeignKey for adding objects in the admin system, and is displayed as > a read onl

Re: OneToOneField behavior doesn't match docs

Joseph Kocherhans wrote: > The current trunk and magic-removal docs say this about OneToOneField: [snip] No feedback, so I've commited a patch. OneToOneField now behaves like ForeignKey for adding objects in the admin system, and is displayed as a read only field for the change form. Here's the