Spm versioning (rcwelsh) - #76
Conversation
…ster version from /net/misc/SPMS
…ding in mcroot/spm8 to mcroot/SPM/SPM8/spm8Legacy
… to instead add mcRoot/SPM/SPM8/spm8Legacy
… toolbox from spm8Legacy per request from @rcwelsh
… there are potential issues with the sledgehammer approach I took to updating the toolboxes" Revert "updated toolboxes in previous spm8 releases to use the version of the toolbox from spm8Legacy per request from @rcwelsh" This reverts commit 3873ddce24af639d963b274c1811333ffdf659a2.
… ExtractVals to R4667
|
The first 8 commits are also in pull request #67 so I'll go ahead and close that issue. However, for much clearer discussion of what's included in the pull request, see the notes there. |
|
@rcwelsh Just wanted to check what happened with the last two commits, since they have identical commit messages. When I look at the diff it looks like they touch different files, though, so maybe you just broke the final step into two pieces? |
|
I'd left something out of r4290 that needed to be there, so it should be much smaller diff. But, yeah take both. R typos due to iPhone 4S On Jul 11, 2012, at 9:36, "Daniel A Kessler" reply@reply.github.com wrote:
|
|
Cool, I'll go ahead and merge it. Thanks! |
Spm versioning. This adds support for multiple, simultaneous SPM versions, and should close #46
|
Great. Also, we should not have a problem with the large of a diff again. Let me know when we have totally clean and most up to date develop as I'll want to fetch to refresh. typos due to iPhone 4S On Jul 11, 2012, at 9:44, "Daniel A Kessler" reply@reply.github.com wrote:
|
|
Develop is reasonably up to date now. Next pending changes are to suppress a bunch of toolboxes that we don't plan to release. This plan is all documented in #77 |
|
so it has the latest and greatest for spm8Batch (with the merge of Joe's thanks! On 7/11/12 3:26 PM, "Daniel A Kessler" Develop is reasonably up to date now. Next pending changes are to suppress Reply to this email directly or view it on GitHub: Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
|
First level, most likely. I don't think the SOM stuff has been merged into develop yet, because it wasn't going to be in the first release. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
|
can we still get it in so that I can just grab and branch off develop? On 7/11/12 4:36 PM, "Mike Angstadt" First level, most likely. I don't think the SOM stuff has been merged Electronic Mail is not secure, may not be read every day, and should not Reply to this email directly or view it on GitHub: Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
|
Quick Answer I believe it also has most of the FirstLevel changes. From skimming the refs that are not merged, it looks like @heffjos started work yesterday on some tweaks to the firstlevel script, but I don't believe those are planned for release anytime soon. To confirm what Mike said, SOM is not included because it will not be in the first release. Longer Answer After doing a I ran this to see what had and had not been merged
Unmerged branches include: physioCorr_psycheLocale Merged branches include core/hide_unreleased |
|
@rcwelsh I will see about getting that merged in. It looks like there are five branches that contain SOM related stuff remotes/github/mangstad/MAS_resting so I'll need to look at their history and figure out how to best gather them together. Should happen early tmrw AM |
|
I know, but can we still get som in, I've not made changes in some time as which now that I think about it, because of the huge mess with the spm given that. I think we need to get an up-to-date develop that we all start -robert On 7/11/12 4:41 PM, "Daniel A Kessler" Quick Answer I believe it also has most of the FirstLevel changes. From skimming the To confirm what Mike said, SOM is not included because it will not be in Longer Answer After doing a I ran this to see what had and had not been merged
Unmerged branches include: physioCorr_psycheLocale Merged branches include core/hide_unreleased Reply to this email directly or view it on GitHub: Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
|
@rcwelsh I thought about that too, but fortunately, when github calculates the diff, it actually calculates the diff for the head branch vs the common parent. Because all of the spm versioning stuff lives between the base branch and the common parent, it doesn't show up in the diff. I tested it by creating a mock pull request for an unfinished feature I was working on and the diff was what I expected (hundreds of line changes, only pertaining to the feature I was working on). Nonetheless, I will try to get som merged in. |
|
why is an experiment specific folder (MAS_resting) in MethodsCore? is SOM_zeros Mike's version of going to 4-digit files -- that is in -r On 7/11/12 4:49 PM, "Daniel A Kessler" @rcwelsh I will see about getting that merged in. It looks like there are remotes/github/mangstad/MAS_resting so I'll need to look at their history and figure out how to best gather Should happen early tmrw AM Reply to this email directly or view it on GitHub: Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
|
ah, great, I was worried because when I switch branches on my local thanks! On 7/11/12 4:52 PM, "Daniel A Kessler" @rcwelsh I thought about that too, but fortunately, when github calculates I tested it by creating a mock pull request for an unfinished feature I Nonetheless, I will try to get som merged in. Reply to this email directly or view it on GitHub: Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
|
@rcwelsh MAS_resting is perhaps an unfortunate name for a feature branch, but from scanning the diffs that it introduces relative to SOM_zeros (it's most recent parent) the changes it introduces are not MAS specific. I believe @mangstad named it that because the changes he was introducing were motivated by the MAS study, though not specific to that. I definitely occasionally need to quickly hard code something to work for one of my studies and will name my branches to reflect that, but make sure that I cherry-pick or rebase any of the non-specific work I do in that branch to apply to my more generic feature branches. Generally speaking, branch names in developer repositories use a local namespace so developer's are kind of free (programatically speaking) to do what they will, but I agree that we should have a naming convention that makes it easier for us to review one another's repositories. However, coming up with a good naming convention was tricky and took some thought, as it's tightly coupled to the branching/merging strategy that we use. I've written up a pretty extensive doc how I think it should work in the standards page of the wiki. |
|
@rcwelsh from looking at the topology of the SOM stuff, it looks like virtually everything has been merged into MAS_resting with the exception of som_fixes, which just has one unique commit. I'll merge it in and then pull it into develop when I have a bit more time to carefully review the diff to make sure I'm not breaking anything. |
|
Yeah, that's my bad. While developing the som_batch code, I was using the MAS dataset as a test, so chose the name based on that, but the changes are not specific to that study. Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues |
Robert's changes for spm versioning issue.
We also were made aware that there are limit s in github that make diffs with a lot of changes impossible to auto-calculate. A support person said he manually created the diff for this commit and cached it so we could create this pull request