Suppose that may be the case for "my" case. But by chance lets say I did
freeze_edge to current, and I had a 0.13.0 working copy. I would still need
this feature.
So it appears this doesn't have immediate fruit, but it is getting ripe for
implementation.
Thanks for the feedback.
-Nb
On 4/9/06 6
> Suppose that may be the case for "my" case. But by chance lets say I did
> freeze_edge to current, and I had a 0.13.0 working copy. I would still need
> this feature.
>
> So it appears this doesn't have immediate fruit, but it is getting ripe for
> implementation.
It's highly unlikely that we're
Ok, this makes a bit more sense now for the older versions. Wasn't aware
that the "rails:upgrade" was the method to upgrade these days.
So it is not expected that Rails' future upgrades will potentially overwrite
any of the files existing in my WC with new versions?
I can see this is already not
> I can see this is already not the case with the boot/config.rb.
See the release notes for Rails 1.1.2:
http://weblog.rubyonrails.org/articles/2006/04/09/rails-1-1-2-tiny-fix-for-gems-dependencies
> The capability of having a diff/merge/patch tool as an option when running
> the rails:upgrade co
On 4/10/06, David Heinemeier Hansson <[EMAIL PROTECTED]> wrote:
> We only update generated files that you shouldn't be changing. There's
> no need to update config/environment.rb, database.yml, or any of the
> other files that you're supposed to edit. So I don't really see a use
> for this.
Beside
