Loading ...
Sorry, an error occurred while loading the content.

Re: [agileDatabases] Re: how to sequence database refactorings?

Expand Messages
  • Pramod
    Sorry it took so long to reply, go side tracked with other stuff. Comments below. Thanks Pramod ... We handle this using the revision or release identifier on
    Message 1 of 15 , Jul 14, 2004
    • 0 Attachment
      Sorry it took so long to reply, go side tracked with
      other stuff. Comments below.

      Thanks
      Pramod
      --- Steve <spam.target@...> wrote:
      > According to these scheme, how do you handle merges
      > of different
      > branches - especially with production databases. For
      > instance, if you
      > have a bugfix branch which you want to merge into
      > the mainline, you
      > have to cater for the situation where some customers
      > have a database
      > that comes from the branch (they have deployed the
      > bugfix), while
      > others have a database that comes from the mainline
      > (they have not
      > deployed the bugfix). At the mergepoint you would
      > have to run two
      > different sets of scripts to handle the merge.


      We handle this using the revision or release
      identifier on the VersionLog table.
      Every change that is made to the database has to be
      logged and tracked in this
      versionlog table with the release being either the
      BugFix version or the Head Version, there on it does
      not matter what branch of the code base you
      made the change in, since before applying a change you
      can check if the particular change was made to the
      database (production in your case ) or not if
      it was not made then you go ahead and make the change.
      The sticking point is how to merge the base scripts
      (the script that creates all the tables/views/indexes
      etc), I guess it would have to be handled like any
      code merge

      >
      > Another situation is where some customers are on a
      > customization
      > branch, and then that customization goes into the
      > mainline and you
      > get a mergepoint. Again you would have two distinct
      > upgrade paths for
      > the production databases: one for the customers with
      > the
      > customization and one for those without it.

      Again I think this is the same situation as above, as
      long as you are tracking,
      logging and applying database changes for each branch
      then you can easily
      determine if the given change was applied to the
      customized Version or the Main
      branch or not

      >
      > How do you handle the above scenarios?


      =====




      __________________________________
      Do you Yahoo!?
      Yahoo! Mail - You care about security. So do we.
      http://promotions.yahoo.com/new_mail
    Your message has been successfully submitted and would be delivered to recipients shortly.