On Thursday, September 20, 2012, Paul Hoadley wrote: > 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? >
Yeah that describes what I do. Dealing with the merge conflicts between branches is certainly a pain, but it's tolerable. >
_______________________________________________ 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]
