how to set a capistrano deployment to some particular git previous commit.
There is one command I saw cap deploy:set_current_revision
How to pass an argument to this command?
cap deploy:set_current_revision=6740ee25...` ?
How to use this command to set current revision to some previous git commit.
The deploy:set_current_revision task merely fetches the current revision from the underlying VCS.
What you would need to do is temporarily (you don't need to commit it unless you are using CI for deployments) add set :branch, '<REVID>' to your deploy.rb. Then do a normal deployment.
Related
i came across a problem with subversion at my work. I want to create a post-commit-hook (post-commit.bat file) command that creates information about the last transaction.
The code looks like this:
#echo off
set file="D:\mypath\logfile%2.txt"
svn log D:\'my path to repro'\ -r %2 -v > %file%
The %2 corresponds to the last revision number. It creates the file with the correct number and tries to write in it. But then the commit hangs and the file remains open. The curious thing is, if I manually trigger the command with a valid revision number, then the whole thing works. Only with the hook it hangs and it also does not commit the files.
Can anyone help me or have any ideas for my problem?
I found a solution, maybe this might be helpful for some person.
I used the wrong command "log". Instead you have to use "svnlook changed..." on the server to get the latest information about the last commit.
Our installer updates our application from using java7 to java8. In doing so, we'd like to update their Tomcat7 configuration to limit the Metaspace at the same level as their PermGen space (which they might have customized). So if they had...
-XX:MaxPermSize=256m
we'd like to set...
-XX:MaxMetaspaceSize=256m
The trick is, the installer must do this via a batch file. (Perhaps querying Tomcat with some command that would spit out the present value to a file, and then read that value in, and then fire off another command to set the value.)
If I can get the present MaxPermSize, I know that last piece of the puzzle:
"%TOMCAT7_EXE%" %SERVICE_NAME% --JvmOptions "-XX:MaxMetaspaceSize=%MAX_SIZE%"
(It might also be nice to remove the no longer applicable MaxPermSize, but that would be just for extra-credit.)
What is the best way to debug git-hooks?
The way I prefer is adding statements to add output to a log file. For example, the following.
echo 'post-receive executed' >> hooks.log
Is there a better approach or way to do logging?
This is an old question, but for future readers, one recommendation would be :
Debugging the hook as a shell script
I doubt that it is the script itself which needs to be looked at, however if that turns out to be the case, then the next step is to do what you normally would to debug shell scripts (since that is what the default commit-msg hook is).
I would start by changing the she-bang line from #!/bin/sh to #!/bin/sh -xv and then revel in the uber-verbose output as the script is executed when you do a git commit --amend
I have a big named branch with a lot of changes. Some of these changes are non-destructive so I want to pick these specific files out first, and merge them with default as soon as possible. (Then later, the destructive changes are merged as well.)
In Git I would create another branch and squash all changesets outside of the index, then I would add the specific files to the index and commit. After that, I could merge this temporary branch with master so master has a clean commit with only the non-destructive change. I don't know how to do this with Mercurial.
You can use hg cat to grab the contents of a file as it exists on any particular branch, and replace the working copy version with that.
This isn't technically a merge, but since you're replacing whole files you shouldn't have too much of a bad time merging things later:
for example, to grab myfile.c form branch somefeature, and replace the working copy version, do:
hg cat path/to/myfile.c -r somefeature > path/to/myfile.c
note that this completely replaces the working copy file so make sure you have no outstanding changes first
I think mercurialqueues is what you want. With mq you can turn any changeset into a patch and any patch into a changeset. So taking a changeset converting it to a patch deleting the chunks out of the patch that you don't want and then applying it to whatever branch you want. This is a fairly complex operation though and requires a certain amount of discipline on your part. So I would try to nail down your workflow on a test repo before trying it on code you care about.
As far as I know, Mercurial doesnt any have tools to split changesets. If youre lucky, all the changes you want are in separate changesets and then you can use the TransplantExtension. I think it can be compared to Git's cherry-pick but I havent used git much.
You can also use hg diff to manually commit the changes to a certain file to a new branch. Use the rev range to mark your entire source branch:
hg diff myfile -r startrevision:endrevision
The output can be treated as a patch. Do this for each file you want and commit them and then merge. Skipping the destructive changes. You can also, of course, do this multiple times of a destructive change is in the middle of a revision range.
Having said that what youre trying to do isnt something mercurial was built for. That hardcore history editing is more Git's area (note that its just my opinion). Keep your stable changes and destructive changes in separate changesets (and maybe even in separate branches). I use transplant, rebase and strip to move changes around. When its all done, they are merged and properly pushed.
Oh, and check MercurialQueues. I havent used it myself but Ive seen it do some crazy stuff. Maybe its capable of doing something along the lines of what you want.
I'd like to know if it is possible to restore a removed file from an older revision (a clean way to do it)
I've renamed a file for some tests, than I commited all my work (and I forgot to rename the file) and did a lot of other commits...
When I realised, it was too late...
Regards,
Ayman
The easiest way is to simply use bzr revert with a revision number before the file was deleted:
bzr revert -rX path/to/file
bzr commit -m 'Bringing path/to/file back'
You don't need to merge anything.
If you know revision number when you removed that file (you can inspect history with bzr log -v) then you can resurrect that file with merge command. So for file foo and revision number N you need to run command:
bzr merge foo -r N..N-1
E.g. for revision 287:
bzr merge foo -r 287..286
This command will restore your file as in revision 287. You need to commit this change and you done.
This isn't the best answer. See bialix' answer which is a lot simpler. I'll leave this here just for reference.
Here's what I think is the cleanest method:
Create a branch:
bzr branch mytree repair-path
cd into the repair branch
Revert just the missing file at its last revision (eg 287 in this example):
bzr revert -r 287 lost.file
Commit the change
bzr commit -m "Unshoot my foot"
cd back into the main branch
merge in the repair
bzr merge repair-path
When ready, commit the merge and delete the repair branch.
You could do this just by reverting in the original working branch, but it's probably good practice not to. You also need to worry (just a little) about any uncommitted changes.