I'd like to automate TortoiseSVN as part of a commit process.
Specifically I'd like to dynamically create a log entry for the commit dialog.
I know that I can launch the commit dialog either from the commandline or by right clicking on a folder and selecting svncommit.
I'd like to use the start commit hook to setup a log entry.
I thought this worked by passing an entry file name in the MESSAGEFILE variable but when I add a hook script it cannot see this variable (hook launched successfully after right clicking and choosing svncommit).
When I try using the commandline I use the /logmsgfile parameter but it seems to have no effect.
I'm using tortoisesvn 1.5.3.
Looks like it was my own misunderstanding of the the API that caused by a problem.
Solution:
1) I've added a start commit hook script to TortoiseSVN using the hooks gui in the settings area of the right click menu.
2) The script receive 3 pieces of information: PATH MESSAGEFILE CWD
For details see: Manual
These are passed as command line arguements to the script - for some reason I had thought they were set as temporary environmental variables.
My script then simply opens the file specified by the second arguement and adds in the custom text.
When the commit dialog comes up the custom text is there.
3) Best of all if tortoisesvn is launched from a script directly into the commit dialog:
e.g. [ tortoiseproc /command:commit /path:. /closeonend:1 ]
The hooks are still called.
If you just need a static template, set the tsvn:logtemplate property.
For dynamic generation, the /logmsgfile parameter does work, but it seems to need the full path. A batch file that looks like the following might work for you.
GenerateLogMsg.exe > tmp.msg
"C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe" /command:commit /path:. /logmsgfile:"C:\Documents and Settings\User\My Documents\Visual Studio Projects\Project\tmp.msg"
Related
I just download the latest 2011.1, and try to use "ant extgen" command to create a default extennsion, but meet following error:
Would anyone know how to deal with it?
extgen.xml:293: The following error occurred while executing this line:
extgen.xml:35: Source directory '${ext.develop.path}' for template 'training' does not exist.
Just run it again and it should work the second time.
There does seem to be a bug in the build scripts that has probably been there a while. I assume that ant extgen was the first thing you ran after unpacking. There is no config folder so the build script did this:
[input] No config folder was found at /path/to/hybris/config.
[input] Please choose the configuration template.
[input] Press [Enter] to use the default value ([develop], production)
and you chose develop
Unfortunately it stores your choice in a variable input.template which is the same name as used when later on the script asks you what extension template you want to base yours on. So the script sees that the variable already has a value and doesn't ask you:
[input] Please choose a template for generation.
[input] Press [Enter] to use the default value (commercewebservices, commercewebservicestests, yacceleratorfulfilmentprocess, yacceleratormarketplaceintegration, yacceleratorordermanagement, yacceleratorstorefront, yaddon, ybackoffice, ycommercewebservices, ycommercewebservicestest, ydocumentcart, [yempty], yhacext, yocc, yoccaddon, yocctests, ysapproductconfigaddon, ysmarteditmodule, yvoid, ywebservices)
It then tries to find a template extension develop and fails.
Running it the second time means your config folder is already generated and it correctly asks you which extension you want to base your extension on.
I am using following command to sync B vob files from A vob
clearfsimport -master -follow -nsetevent -comment $2 /vobs/A/xxx/*.h /vobs/B/xxx/
It works fine. But it will check in all the changes automatically. Is there a way to do the same task but leave the update files in a check out status?
I want to update the file for B from A. Build my programme, and then re-cover the branch. So if the updated files is an check out status, I can do unco later. Well with my command before, everything is checked in. I cann't re-cover my branch then.
Thanks.
As VonC said, it's impossible to prevent "clearfsimport" to do the check in. And he suggested to use a label to recover back.
For me, the branch where I did "clearfsimport" is branched from a label.Let's call it LABEL_01. So I guess I can use that label for recovery. Is there an easy way (one command) to recover the files under /vobs/B/xxx/ to label LABEL_01 ? I want to do it in my bash script, so the less/easy the command is, the better.
Thanks.
After having a look at the man page for clearfsimport, no, it isn't possible to prevent the checkins.
I would set a label before the clearfsimport, and modify the config spec for the new version to be created in a branch (similar to this config spec).
That way, "re-cover" the initial branch would be easy: none of the new version would have been created in it.
After installing CodeCollab on OS X 10.6, I get Error: Unable to run ccollabgui when I try to add a new code review from P4V.
Strange but google was not able to find any match for the search :(
I you receive this error just go to p4v Tools->Manage Custom Tools and select Code Collaborator - Add to Review->Edit.
Now change the application from ccollabgui to /Applications/ccollab_client/ccollabgui.app/Contents/MacOS/JavaApplicationStub.
I received this error because I installed by ccollab in a non-standard location (not /Applications/ccollab_client)
[remove any already installed ccollab p4 custom tools if installed]
To fix, in p4v Tools|Manage Custom Tools|Select "SmartBear - Add to Review". Click edit. In the edit box called "Application", adjust the path to the correct path for your install.
My issue had something to do with perforce. I updated Code Collaborator to a newer version and it installed the Add to Review tool in perforce. When I tried to run it I got the error above.
When I looked at the old tool that had previously been added I noticed one difference. The Arguments had --p4 /usr/local/bin/p4 while the newer one didn't. When I added this it worked fine.
To fix, in p4v Tools|Manage Custom Tools|Select "SmartBear - Add to Review".
Click edit.
In the edit box called "Application" point to proper like below:
/Applications/ccollab_client/ccollabgui.app/Contents/MacOS/JavaApplicationStub
In the edit box called "Arguments" point to proper like below:
--p4 /usr/local/bin/p4 --pause-on-error --scm perforce --p4port $p --p4user $u --p4client "emptyArgumentPrefix $c emptyArgumentSuffix" addchangelist ask %C
I am Using CC.Net to run an .exe file after project build is complete and need to pass the project name, publish date/time and user on the command line as parameters to the .exe. However I can't get cc.net to recognise these a dynamic properties and replace them with the correct values.
<publishers><exec executable="C:\MyApp.exe"></exec><buildArgs>"$[$CCNetProject]" "$[$CCNetBuildDate]" "$[$CCNetBuildTime]" "$[$CCNetUser]"</buildArgs><buildTimeoutSeconds>30</buildTimeoutSeconds></publishers>
The correct syntax for properties in ccnet config is $[CCNetProject]
I believe the correct syntax for properties in ccnet config is:
$[CCNetProject]
Rather than:
$[$CCNetProject]
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Pre-build task - deleting the working copy in CruiseControl.NET
I would like to delete my working directory during the cruisecontrol build process...I'm sure this is easy, but I have been unable to find an example of it...
If you know how to create a directory, that would be useful as well.
Thanks.
One of two ways.
If you're already using an MSBuild file or something similar, add the action to the MSBuild file.
Instead of directly executing some command, create a batch file that executes that command and then deletes the directory, and have CCnet call that batch file instead.
My guess is that you want to delete the working directory before CruiseControl.NET gets the latest code from source control. If this is the case, then the only way to accomplish this is to write a custom source control provider for CruiseControl.NET that first deletes the working directory and then gets the latest code. Have a look at CruiseControl.NET's source code for examples of how to write a source control provider.
If you want to delete the working directory after the latest code is retrieved from source control, then you can use CruiseControl.NET's executable task by running "cmd /c del directoryname".
In the ASP.NET work, for me, the easiest way I do it (which allows me to hit either MSBUild or NAnt depending upon the project) was to roll my own exe that takes an argument which I pass in with a bat file fired by CC.NET. It's not the safest thing in the world, but if you have total control over your automated build machine; it's not too shabby. Quick and reusable.
Drop in the exe somewhere that does the recursive delete:
static void Main(string[] args)
{
for (int n = 0; n < args.Length; n++)
{
if (Directory.Exists(args[n].ToString()))
{
Directory.Delete(args[n].ToString(), true);
}
}
}
Drop it in somewhere multiple files can pass arguments to it and just write a custom .bat file for each project. So my task block looks like this:
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
<workingDirectory>Z:\WorkingDirectory</workingDirectory>
<projectFile>YourSolution.sln</projectFile>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<exec>
<executable>Z:\SomePathToBuildScripts\YourCustomBat.bat</executable>
</exec>
</tasks>
Then the final step is setting up that .bat file to perform the delete/rebuild functions after use. In the bat file just make sure you rebuild ("MD") the directories you deleted if youexpect to publish a site back to them. On our dev boxes I found this to be the best way to prevent the beloved Frankenbuild.
The way I've done this in the past is to not have CC.Net checkout source itself. Instead, there are two <msbuild> elements for the project, the first one calling a build target that runs svn-clean.pl (compiled to .exe), and then updates the source using svn.exe. The second <msbuild> element starts the main build process.
You can easily replace svn-clean with a delete command. For my projects, deleting chaff from a checkout has always been faster than checking out a fresh working copy.
The two msbuild elements are necessary because the main project build file is often updated. This is important because updates to your build file(s) will only be reloaded if you start a new msbuild process.
This setup breaks down when I (very rarely) move or change the dependencies of that clean-and-update build target to the extent that the msbuild process would need to reload for valid instructions to run the clean-and-update target. When this happens, I stop CC.Net before committing, go into the CC.Net server, and do an 'svn update' by hand.
Sidelight: It could well be that CC.Net has a natural clean-before-build operation by now. I've since moved to TeamCity, which is configurable to do this every build or only when the developer chooses (e.g., when you know you've made a change that would not update cleanly--svn moves of directories with build products comes to mind).