Okay great, I'll send a docs patch in next week (assuming no one shows any
disagreement), and hopefully that'll be the end of it!
Thanks to all for your feedback.
Cal
On Fri, Mar 28, 2014 at 10:04 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 28 mars 2014, at 22:28, Ca
On 28 mars 2014, at 22:28, Cal Leeming [Simplicity Media Ltd]
wrote:
> So is that a "no" to the docs patch proposal?
It isn't. Like I said, I really don't care. If someone wants to commit
something, that's fine.
--
Aymeric.
--
You received this message because you are subscribed to the Goo
So is that a "no" to the docs patch proposal?
Cal
On Fri, Mar 28, 2014 at 8:52 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> I'm not sure this thread is going anywhere and I don't care either way.
> If you've been reading up to this point...
>
> ... either you h
Hello,
There's no particular process. Just show up, pick a ticket you're interested
in, assign it to yourself, and figure out a resolution. Rinse, repeat ;-)
I would simply advise to setup a development environment in advance. Check out
the source and make sure you can run the tests. That's all
Hello,
I'm not sure this thread is going anywhere and I don't care either way.
If you've been reading up to this point...
... either you have too much spare time. Rather than rehashing this debate,
may I suggest triaging some tickets? That would really help!
https://docs.djangoproject.com/en/dev
I know Django will be sprinting at PyCon, and I thought I might like to
participate. I haven't done conference sprints before, so I'm curious,
what's the process? If I have a particular ticket that I'm interested in,
do I just work on that bug at the sprint? Or will there be a proposed list
of
Yes, --update is very risky if you run it on migrations that are already
committed and pushed, but the main reason I left it out of 1.7 was
complexity (because makemigrations is now much more intelligent, updating
and adding a foreignkey into a migration might introduce a new dependency
or force a
>
> South's `--update` also rolled the previous migration back, changed it and
> then reapplied it to the current database.
>
OK, in that case I can very much see how it's useful for people who develop
against a persistent database. That's probably most people.
Anyway, the result of this threa
South's `--update` also rolled the previous migration back, changed it and
then reapplied it to the current database.
M
On 28 March 2014 10:48, Bernie Sumption wrote:
>
> That script would be bad if you'd run any of those migrations against your
>> development db (yes it should be "throwaway"
> That script would be bad if you'd run any of those migrations against your
> development db (yes it should be "throwaway" or rebuildable but...)
>
I'd think the same could be said of --update? As I understand it, --update
is the equivalent of deleting the most recent migration and recreating
That script would be bad if you'd run any of those migrations against your
development db (yes it should be "throwaway" or rebuildable but...)
Personally, I'm strongly in favour of Shai's suggestion and also in favour
of --update, mainly as I like being able to capture (most) migrations has
logica
OK, it turns out that the "safe update migrations script" too simple to
even qualify as a "script":
git clean myapp/migrations -f && python manage.py makemigrations
Perhaps the solution is to document this on the testing page as a solution
to the "accumulation of many small migrations during de
The problem with --update is that if overwrites the most recent migration,
then it might be used to modify a committed and distributed migration,
which is a Bad Thing. The flag would probably be useful to people with my
use case, if they trust themselves to use the flag with care and remember
t
13 matches
Mail list logo
