I am trying to make some changes in my cruise control the web dashboard.
I modified the corresponding .xsl file, but the changes does not seem to reflect back on the dahsboard.
I have tried the following:
- Restart ccnet service.
- Restart IIS.
I am using ccnet version 1.6.7
Am I missing something here?
Download this tool
http://www.voidtools.com/download.php
Find all copies of your .xsl file.
Make a small (text only) change in the xsl file.......and find the one it is actually using.
My guess is that you have 2 of the same xsl, and you're updating the wrong one.
Also clear the cache of the browser, or do a force-refresh.
If that does not help, check that there is nothing wrong with the xsl.
Simple check : alter the xsl so that it adds some text that must always be visible in the output.
Related
I am trying to automate installshield 6.0.
I want to automate the Name and Version field under Project->settings->Application.
I am trying to put the values in the fields via command prompt.
Can anyone please suggest how can it be done?
I believe InstallShield 6 stored its project information in INI or INI-like files. Examine the changes made to these files when you change those fields in the IDE. Once you know what it does, it should then be straightforward to write a command-line exe that makes the same (or configurable) changes to any project.
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.
I am using SharePoint 2010. When I insert an image into my content I see that spaces are added around the image. The spaces have default value 5px.
I would like to have 0px instead. The reason is that editors forget to set it to 0px manually and basically do not want to make the extra step.
I have found that in SharePoint core there is 14\template\features\publishinglayouts\provisionedui.xml file where the default values for spaces are set. I do not like an idea to make changes in the file at all because:
a. well it is core file and it could be changed in future by a
service pack for instance
b. I need to think about how to deploy the
changed file to a farm (I can create a feature which will replace the
file on all servers, but it sounds like a dirty hack).
Do you have better (or just any) ideas how can I achieve my goal?
not really sure about it but can you just change the interval from 5 to 0 on that xml file?
Does CC.NET allow for you to link to premade .html files on the plugin bar on the left?
I know it allows for you to link via XSL, but when I use the XSL for a certain plugin it does not display correctly. But the program can make a .html file itself so i was wondering if i could have it make one then link to it.
I know TeamCity has the capabilities to do this I was just wondering if CC.NET had this too.
And I know about the external links ability, but I want to link to it from the bar on the left, not the main build screen.
Have a look in your webdashboard\templates folder. In there are all the templates the server uses. I think you probably could edit ProjectSideBar.vm and add a normal xxx and use your file name and possibly one of the variables used in the file, something like:
<tr><td>Your File Ouput</td></tr>
I don't know if $projectName exists, but look in the other .vm files and you should be able to find something.
It should work, although I can't check myself at the moment.
Look at the trunk on sourceforge, I just read that in 1.5 is going to be an html plugin on the dashboard for displaying html output...
The Html Report Plugin is what you want to use - it's available starting with release 1.5 as Alex mentioned: http://www.cruisecontrolnet.org/projects/ccnet/wiki/HtmlReportPlugin
EDIT: I've spent a couple of days with the Html Report Plugin and unfortunately it looks like it has too many bugs to be useful. See my issues here and here.
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)