Just created a ticket for: http://dev.rubyonrails.org/ticket/4673 Which outlines the option to merge/diff or patch on upgrade. Currently I see the functionality of upgrading quite tedious, especially with the now planned rapid release cycle. This is solely due to the fact that I need to create temp files and merge core files, such as application.rb, application_helper.rb, with the updated Rails copy. I am proposing we look into creating a Diff/Merge/Patch option, that creates a file with the changes embedded so I can look at that file, tweak it if necessary, and patch the WC. Ideas/comments? -Nb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Just created a ticket for: > > http://dev.rubyonrails.org/ticket/4673 > > Which outlines the option to merge/diff or patch on upgrade. > > Currently I see the functionality of upgrading quite tedious, especially > with the now planned rapid release cycle. This is solely due to the fact > that I need to create temp files and merge core files, such as > application.rb, application_helper.rb, with the updated Rails copy.Why do you need to do this? rake rails:update only changes the javascript files. rails . hasn''t been needed since .13->.14> I am proposing we look into creating a Diff/Merge/Patch option, that creates > a file with the changes embedded so I can look at that file, tweak it if > necessary, and patch the WC. > > Ideas/comments? > > -Nb > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Nathaniel S. H. Brown http://nshb.net > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Cheers Koz
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:13 PM, "Michael Koziarski" <michael@koziarski.com> wrote:>> Just created a ticket for: >> >> http://dev.rubyonrails.org/ticket/4673 >> >> Which outlines the option to merge/diff or patch on upgrade. >> >> Currently I see the functionality of upgrading quite tedious, especially >> with the now planned rapid release cycle. This is solely due to the fact >> that I need to create temp files and merge core files, such as >> application.rb, application_helper.rb, with the updated Rails copy. > > Why do you need to do this? rake rails:update only changes the > javascript files. > > rails . hasn''t been needed since .13->.14 > >> I am proposing we look into creating a Diff/Merge/Patch option, that creates >> a file with the changes embedded so I can look at that file, tweak it if >> necessary, and patch the WC. >> >> Ideas/comments? >> >> -Nb >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Nathaniel S. H. Brown http://nshb.net >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> >> >> _______________________________________________ >> Rails-core mailing list >> Rails-core@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-core >> > > > -- > Cheers > > Koz > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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 going to spend time automating upgrades from 0.13.x. If you''re still on that version, you''ll have to do it manually. And then cherish the fact that you won''t have to do it again. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
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 the case with the boot/config.rb. The capability of having a diff/merge/patch tool as an option when running the rails:upgrade could be quite useful, and would lend aide to having to create a tmp file manually and running diff against the two to see what changed. -Nb On 4/10/06 7:10 AM, "David Heinemeier Hansson" <david.heinemeier@gmail.com> wrote:>> 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 going to spend time automating > upgrades from 0.13.x. If you''re still on that version, you''ll have to > do it manually. And then cherish the fact that you won''t have to do it > again. > -- > David Heinemeier Hansson > http://www.loudthinking.com -- Broadcasting Brain > http://www.basecamphq.com -- Online project management > http://www.backpackit.com -- Personal information manager > http://www.rubyonrails.com -- Web-application framework > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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 could be quite useful, and would lend aide to having to > create a tmp file manually and running diff against the two to see what > changed.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. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
On 4/10/06, David Heinemeier Hansson <david.heinemeier@gmail.com> 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.Besides that, assuming you have your project in some type of source control (anymore, there''s _no_ excuse not to), if you really need this functionality, it''s as simple as performing the update on a clean working copy and then doing an `svn diff` (or the equivalent for your SCM). No use for reinventing the wheel, either. -- Regards, John Wilger http://johnwilger.com ----------- Alice came to a fork in the road. "Which road do I take?" she asked. "Where do you want to go?" responded the Cheshire cat. "I don''t know," Alice answered. "Then," said the cat, "it doesn''t matter." - Lewis Carrol, Alice in Wonderland