Hi Pascal, On 21/09/2012, at 4:52 AM, Pascal Robert wrote:
> I was wondering how do you deal with situations where your development branch > is having migrations that are NOT part of trunk/current release but that you > need to do a migration for a fix in trunk? > > Let's say trunk is at migration 2 (on the prod database), but the "super new > features" branch is at migration 5 (on the dev database), creating a > migration 3 in trunk will create problems when trunk is merged with the > "super new features" branch, and doing a migration 6 in trunk will make that > migration 3-4-5 won't be executed in prod since prod will already be at > version 6. > > Any solutions? Assuming that (a) you can trash and re-create your development database at will, and (b) this fix in the master branch is destined to be merged into the development branch (either or both of which might be false), I would: 1. Create migration 3 in the master (or hotfix, or whatever) branch to fix the problem. 2. When you're ready to merge in the fix, bump 3, 4 and 5 in development up to 4, 5 and 6, and at the same time merge in the new 3 and whatever else is part of the fix. At that point you'd obviously drop and re-create the development database with the new chain of migrations. Does this fit your constraints? -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
