On Jan 20, 2008 7:20 PM, Ian Bicking <[EMAIL PROTECTED]> wrote: > > Kevin Horn wrote: > > > > > > On Jan 19, 2008 11:18 AM, Mark Ramm <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> wrote: > > > > > > > > The reason I'm thinking about this is that one of the complaints > I've > > heard about Pylons is that it is difficult to upgrade from one > version > > to the next because so many template changes are required. And I'd > > like to insulate users from that a bit. > > > > > > I've been pondering a "paster restart" command which would possibly ease > > this process, though it wouldn't make it go away. It will probably be a > > couple of weeks before I have anything useful though. > > My thoughts for this (which I've never got around to implementing) is > that paster create could write .filename.orig everytime it writes a > file, and when doing another create you could check if the file has > changed. > > Another possibility, which is harder to code but probably nicer, is if > you could do a merge of sorts; make sure the raw paster create'd files > are committed, store that revision somehow (maybe in a log message that > you could search for). Then to update the template branch at the > revision of the original generated code, write over it with the new > templates, check that in, then take that and merge it back to the trunk. > Any conflict should be a genuine conflict, that happened because they > edited the files. > > This isn't actually harder to implement as much as it touches version > control a great deal. Possibly paster create could just say "commit > right now!" when you finish running it, and then there could be a > command that does all this other stuff (maybe just svn specific to start). > > Ian >
As I said I'd like to start with the simplest possible case . I think tying everything in with version control would be a mistake. Here's how I envision the development going: Phase 1: - "paster restart" command creates a context diff for every file that it finds in both the new and old versions. User manually merges them. Very basic. Phase 2: - "paster restart" command checks a timestamp which would be stored in the quickstarted project immediately after the quickstart process completes. The system could then (optionally) automatically replace files that have not been edited by the user since that timestamp was creted (which would theoretically mean that the user has never edited those files). Context diffs would be created for other files (which the user HAS edited). Phase 3: - add features to automerge the context diffs Phase 4: - tying-in-with-version-control-monkey-business (if desired, I don't really see this as a feature, more of a misfeature, since anyone who uses an unsupported version control system then would be locked out of this functionality...unless it was optional...but I think it adds too much complexity for not enough gain) Hopefully now that I've got my dev PC mostly working again, I'll have some progress on phase 1 in a week or so (keep your fingers crossed!) Kevin Horn --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
