CurrentVersionSHA fixes

[dankessler]

The post-checkout hook doesn't do a very stable job of updating the .local/CurrentVersionSHA file.

There seem to be two problems

1. The path to the directory used by the checkout.sh script is based on a pwd but should use some of the trickier dirname $0 business used in the self_update.sh script.
2. If you go to detached HEAD state, HEAD will not contain a reference to a branch, but rather the sha itself, so we need a way to identify the difference between these two things. My simple guess is that refs will include file separators, whereas sha's will not. Maybe we can use that?

[mangstad]

Since this is still open I'm guessing this isn't working in the current develop? Just asking because the logging code will depend on this since it is intended to embed the current version SHA in the logged script.

Also, any thought about how to deal with Robert's suggestion awhile back in issue #27 about a human readable version number for major releases? Do we just add another file in .local with the major release number, or just include that also in the CurrentVersionSHA file or something else.

[mangstad]

@dankessler do you see any downside to declaring mcRoot as a global variable so we can access it in any of our methods core functions without needing to pass it in?
So instead of

%DEVSTART
mcRoot = fullfile(fileparts(mfilename('fullpath')),'..');
%DEVSTOP

in the templates it would be

global mcRoot;
%DEVSTART
mcRoot = fullfile(fileparts(mfilename('fullpath')),'..');
%DEVSTOP

[dankessler]

I don't see any issues with that

On Thu, Jun 14, 2012 at 2:14 PM, Mike Angstadt <
reply@reply.github.com

wrote:

@dankessler do you see any downside to declaring mcRoot as a global
variable so we can access it in any of our methods core functions without
needing to pass it in?
So instead of

%DEVSTART
mcRoot = fullfile(fileparts(mfilename('fullpath')),'..');
%DEVSTOP

in the templates it would be

global mcRoot;
%DEVSTART
mcRoot = fullfile(fileparts(mfilename('fullpath')),'..');
%DEVSTOP

---

Reply to this email directly or view it on GitHub:

#51 (comment)

Daniel A. Kessler
Research Area Computer Specialist
Psychiatry - Rachel Upjohn Building
University of Michigan, Ann Arbor
kesslerd@umich.edu
+1 734.418.8134

[dankessler]

Also RE your earlier issue, yes, this is still an open issue. However, it's more of a weakness that I realized and wanted to follow-up on. For the most part, the deployed repositories should never be in an detached head state, and it's unlikely that the robustness I proposed in 1) is really necessary. You should be able to assume that stuff works and is in place for now.

[heffjos]

For number 2, my solution looks for a colon in .git/HEAD. I think the colon should only appear when HEAD points to a branch. Let me know if this is a good solution. Here is the added code to checkout.sh:

#Check if in detached head state
headContent=`cat .git/HEAD`
colonLoc=`expr index "$headContent" :`

#Identify Current Version
if [ $colonLoc -eq 0 ]
then
    cat .git/HEAD > .local/CurrentVersionSHA
else
    cat .git/`cat .git/HEAD | awk '{print $NF'}` > .local/CurrentVersionSHA
fi

[dankessler]

@heffjos that looks like a reasonable assumption and a good bit of code. Have you tried it?

[heffjos]

I tested it. The code updates the the current version sha correctly except I found some other behavior that may be bugs. I tested it by cloning my whole repository and then running setup_deployment.sh. When I did this, CurrentVersionSHA was not created until I actually performed a checkout. This can be fixed by putting git checkout HEAD at the end. I was just wondering if the installation I performed would be a typical one so that this line of code is actually needed. Committing anything does not update CurrentVersionSHA, but I do not think anyone should be committing in a deployment version.

Also, if the detached head is at a commit before my changes, then the updated code will be missing.

[dankessler]

Yeah the logic gets rather tricky. I think the git checkout HEAD idea
doesn't hurt.

On Wed, Jun 27, 2012 at 3:57 PM, heffjos <
reply@reply.github.com

wrote:

I tested it. The code updates the the current version sha correctly except
I found some other behavior that may be bugs. I tested it by cloning my
whole repository and then running setup_deployment.sh. When I did this,
CurrentVersionSHA was not created until I actually performed a checkout.
This can be fixed by putting git checkout HEAD at the end. I was just
wondering if the installation I performed would be a typical one so that
this line of code is actually needed.

Also, if the detached head is at a commit before my changes, then the
updated code will be missing.

---

Reply to this email directly or view it on GitHub:

#51 (comment)

Daniel A. Kessler
Research Area Computer Specialist
Psychiatry - Rachel Upjohn Building
University of Michigan, Ann Arbor
kesslerd@umich.edu
+1 734.418.8134

[heffjos]

I add git checkout HEAD: heffjos@934226c

[dankessler]

Sweet. I've tweaked the reference for your commit so that it points more clearly to a commit in your repo rather than mine.

Also, would you mind potentially putting these changes in a separate branch, and resetting your develop back so it doesn't include these? Would make it easier to figure out where the changes are if I fetch from you.

[heffjos]

New branch is SHA_fix.

[dankessler]

Sweet, thanks!

On Thu, Jun 28, 2012 at 12:01 PM, heffjos <
reply@reply.github.com

wrote:

New branch is SHA_fix.

---

Reply to this email directly or view it on GitHub:

#51 (comment)

Daniel A. Kessler
Research Area Computer Specialist
Psychiatry - Rachel Upjohn Building
University of Michigan, Ann Arbor
kesslerd@umich.edu
+1 734.418.8134

[dankessler]

@heffjos does your code address the first issue I raised in the issue description at all?