On Wed, Sep 4, 2013 at 9:16 PM, Andrew Grieve <agri...@chromium.org> wrote:
> Changes should sneak into dev, not master. Unless someone else messed
> something up, there shouldn't be any conflicts on master.
>
> I see what you're saying though. Sneaking a change into dev while you're
> testing would mess you up a bit.
>
> One option is to push after incrementing the version and writing the
> changelog, that way subsequent changes will happen after your merge point
> just fine. It means that you'll have a non-dev version on master for a bit,
> but I think that's fine. Small window.
Would this be any easier if coho had the ability to maintain, say in a
small text file, a list of repos and their associated hashes, as a kind of
'snapshot'? Coho could output that format based on what it sees at a given
time, and then could use it again as input when performing certain git
operations.
Something like this:
$ coho snapshot
{"cordova-android": "8091a2b3c4d5e6f708192a3b4c5d6e7f",
"cordova-ios": "abcd1234...",
"cordova-plugin-camera": ...,
...
}
Then, you could use that to snapshot the plugin state before starting the
release tests, and use it when merging:
$ coho snapshot -r plugins > CURRENT_VERSIONS
... testing follows ...
... ready to commit ...
$ coho foreach -r plugins "git checkout master"
$ coho foreach -r plugins --use-snapshot CURRENT_VERSIONS "git merge
__REVISION__ --ff-only"
Coho would use the appropriate hash in place of __REVISION__ (or some other
placeholder) for each repo in the foreach loop.
