Adding a script, migrate_dir_to_cime, to help with ACME/CIME merge.

[jeff-cohere]

This script allows us to perform the ACME/CIME merge one subdirectory at
a time, allowing for an interruptible and reliable mechanism for resolving
conflicts between these two moving targets. This tool is highly specialized
and really only going to be used for the one-time initial merge, so it's not
incredibly polished.

SEG-107
SEG-115

[BFB]

[jeff-cohere]

No hurry, Jim. This is just a tool that lets us perform the merge at a very controlled pace. Try it out and see if it makes sense to you, or if it needs more documentation/explanation/polish, or just bug me if you're curious.

[jgfouca]

Sorry for slow response, was out of commission last week. Looking at it now.

[jgfouca]

Jeff, this seems to have similar (identical) functionality as the cime_merge_helper tool. What's the motivation here? I'm not too concerned about keeping these tools clean since I doubt we'll ever use them again after this merge is done, I'm just curious.

[jeff-cohere]

Jim,

The only difference is in the packaging. I borrowed pretty heavily (at least conceptually) from your merge tool, basically adapting to a process where we merge directories wholesale but one at a time as part of a larger process. I think you were geared a bit more toward cherry picking commits, which is a bit more laborious with the changes we’re looking at. But yeah, it’s the same basic process except for how it’s invoked and how it “fits in” to the larger picture.

Don’t know if that’s a satisfying answer. I learned a bit about git remotes doing this, too, so it could be considered a didactic exertion as much as anything else. :-)

Jeff

On Jun 1, 2015, at 9:12 AM, James Foucar notifications@github.com wrote:

Jeff, this seems to have similar (identical) functionality as the cime_merge_helper tool. What's the motivation here? I'm not too concerned about keeping these tools clean since I doubt we'll ever use them again after this merge is done, I'm just curious.

—
Reply to this email directly or view it on GitHub #229 (comment).

[jgfouca]

Hi Jeff, cime_merge_helper is designed to do one subdirectory at a time too and the cherry picking is optional. The tool prints "Now you can cherry pick" but you don't actually have to do so. One thing I am concerned about is this:
ACME/A/B -> CIME/X/B
ACME/A/B/C -> CIME/Y/C
I had to take pains in my script to filter commits in C when merging B. I don't see anything like that in your script.

[jeff-cohere]

I noticed that as well. My feeling was and is that we are less concerned about preserving specific repo history (order of commits, etc) than we are with ending up with consistent contents. Maybe I'm not seeing the full significance of this, though. If you have some time this afternoon, maybe we can discuss over the phone?

[jgfouca]

Hi Jeff, the problem is that if you don't filter C when merging B above, C then lives in two places:
CIME/X/B/C and CIME/Y/C. I suppose you could remove CIME/X/B/C as you were doing the merge though.

[jeff-cohere]

Right. I guess the major difference between our scripts is that I'm putting the responsibility of choosing the directories to be migrated on the invoker of the script. I'm cataloging the progress of the merge in the "CIME merge journal" page on Confluence, which you should have access to, just to keep things visible.

[jgfouca]

Skipped integration testing.