On Dec 8, 2006, at 3:09 PM, Courtenay wrote: > > On 12/8/06, Brad Ediger <[EMAIL PROTECTED]> wrote: >> On Dec 8, 2006, at 12:34 PM, Francois Beausoleil wrote: >>> 2006/12/8, Michael Schuerig <[EMAIL PROTECTED]>: >>>> If I understand your suggestion correctly, it amounts to sorting >>>> and >>>> applying migrations based on timestamp. I think real time is not >>>> the >>>> right dimension for this as progress on different branches is not >>>> coordinated by time. Rather, I suggest to apply migrations in the >>>> order >>>> of their corresponding revision numbers. This approach doesn't >>>> guarantee that there can be no conflicts when branches are merged, >>>> but >>>> I think this can't be guaranteed anyway. >>> >>> You are right, Michael. Sort by time, then apply. So, you suggest >>> that we use the revision number instead ? This would tie Rails >>> to one >>> or more SCM. Is that advisable ? >>> >>> Maybe we should sort by time the migration was committed ? But then >>> again, we tie Rails AR to SCM. >>> >>> This is a hard problem. >> >> The basic problem is endemic to SCM anyways. If SCM is not being >> used, there is generally no need for this fix. In my mind, there's >> nothing wrong with saying "if you use version control, Rails handles >> migration merging for you, but only if you use SVN". Nobody is worse >> off under that arrangement than they are now. > > You think that tying rails features to specific dependencies of SCM is > a good thing? > > I don't believe this is a hard problem. > > The timestamp to me feels like "too much", and also, using SCM > revisions doesn't necessarily work, particularly where there are a few > branches, or where you're using (as what inspired this) something like > SVK. > > The main issue here is, how do you keep track of multiple branches of > migrations per DB instance, particularly migrations added in the past. > I had thought about storing the migrations which have been run in the > schema table, and decided that it was also "too much", however, it > could be a good way to maintain the simplicity of numbering with > dependencies. > > We already have the table of schema_info..
I don't think there is anything wrong with tying certain features to a certain SCM system. However, looking back at this, I agree that that is not how this should be done. The problem is not that Rails itself would depend on a certain SCM, the problem is that the data would depend on a certain SCM and a certain set of version numbers. It would be fragile to SCM changes. The original solution I gave (subverted_migrations) changes schema_info to reflect the set of migrations applied to the database (rather than just the latest migration). This is ideal because the totality of the versioning information is kept in the database rather than having to reference something external such as the version control repo. The only part of the plugin that is tied to Subversion is the migration generator (and only then because I only work with Subversion). And it's not tied to svn in a version-numbers sense; it only uses it for introspection into which files exist in which branches (to keep version numbers unique). It is more complicated than migrations are now, but it has been working for me. The only time I have to manually merge is when two revisions in different branches make overlapping changes. --be --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
