We've just set up one of our projects in TeamCity (7.0 (21241)) to label our VCS when the build is successful.
This works fine in that we get Mercurial updated with the appropriate tag. But, as this creates a new Mercurial revision, it's also causing the build to start again as TeamCity is detecting a change.
Any ideas on how to prevent this?
Thanks
We managed to fix this by setting:
Edit Checkout Rules (within TeamCity Version Control Settings) to:
+:.
-:/.hgtags
(note that the settings are on two seperate lines.)
VCS Labeling mode was set to 'Successful only'
Related
Using TortoiseHg Workbench, almost every time I pull from a remote repository, I have uncommitted code changes so that I need to shelve them before I update and then unshelve them again.
Is there a way to do this all in one click? I seem to remember being able to do this when I used Git (perhaps with GitHub for Windows).
Follow-up or comments
Tried to add button to THG GUI
Defined new tool in Tools menu
Added to toolbar (failed, no buttom on toolbar, I suppose, due to icon size /small/ - using path to big icon file instead of embedded may change visibility result)
Tried to add to Revision Context Menu and use added feature
As you can see - button added, but command failed (for unknown reason): using plain hg for PATH\hg.exe is recommendation from "Define tool" window from THG
So the problem is that all developers need different settings for their local testing, but the settings file is part of the project (unlike the nbproject folder for example that we all ignore). I know about .htignore, but the filter only applies to files that are not part of the project.
If I forget the file, then this removes it from the "global" repository, where we have a "holder" version of the settings file.
Right now we just don't commit that file, but every now and then somebody forgets and pushes his own settings, which then are synced back to other developers and it's a constant pain. We just want to "automatically" not push that file. Is there a solution to this? Are we doing something wrong?
You could add a precommit hook that gives an error every time you try to commit this particular file.
To handle the case of developers that forget to setup such a hook, you can also add a serverside hook that will reject their push.
I'm new to Mercurial and MercurialEclipse, and I think I'm not quite understanding this:
After I pull from the central repository (with Update After Pull selected), it is my understanding that all files are loaded form the central repo to my local repo. However, after I pull, I'm seeing the following:
Doesn't the star icon indicate that there are differences between my local copy and the central copy?
What am I missing here? How do I make sure that my files are the most recent copies?
Try right-clicking on your Eclipse project and select Team --> Refresh Status. I often have to do that for the status icons to be updated.
Edit: if you want to override all local changes, select the checkbox "Clean update (override local changes)" in the Pull dialog of Eclipse.
When you update it merges the local changes you have with the changes in the revision you are updating to. In the update dialog if you select the "force" checkbox it will revert any uncommitted changes. Other ways to remove your local changes are updating by right clicking on a revision in the history view and selecting "switch to", or use the "revert" dialog.
I have kind of an interesting problem...
So I'm trying to run a build every time I see a change on a directory in my SCM in Hudson. However, I don't need to pull the directory to run my script. Is there any way to check if there's a change in a directory, but don't pull it?
In addition, there is another directory which I do need to pull from Hudson at the same time. So basically I want something like:
On change of directory A or B:
pull directory B only
run script
I was told there was functionality like this in Hudson, but I can't find it. Any suggestions? Thanks for the help!
In case anyone is interested, I was able to accomplish this with just Hudson and Perforce.
When using Perforce as the SCM (don't know about the others) there is a 'Use View Mask' checkbox. Checking that give you the ability to choose which directories/files in Perforce to poll without actually pulling those files. For example, I had in my view:
//depot/my_script
I didn't want my script to run automatically when I had a new version, so I put it int o the "Poll Exclude File(s) text box:
//depot/my_script
Which pulls the latest version of my script. Then I checked the Use View Mask checkbox and put:
//depot/my_code_to_compile/
into the View Mask box.
To make Perforce poll for changes, I just checked the "Poll SCM" in build triggers and then made it check every minute. (by inserting "* * * * *" into the Scheduler box)
So to sum up, with the variables set as above, my Hudson job had the following behavior:
check for changes every minute
On changes to //depot/my_code_to_compile/, the Hudson job will run
On changes to //depot/my_script, nothing will happen
The job will pull changes to my_script, but will download nothing from //depot/my_code_to_compile/.
I think you need to install the FSTrigger Plugin for this functionality. To what the wiki pages show this is supported in Jenkins, I am not sure about Hudson compatibility.
I'm using perforce for versioning control. Let's say I am working on a file in the main branch:
//main/xx.cs (it's open for edit)
In the mean time, //main gets branched to //v1 and then //main gets locked.
Is there a way I can integrate my local changes in //main/xx.cs directly to //v1/xx.cs ?
There's a similar question: Can I integrate checked out files into a different branch on perforce
One of the answers there gives:
http://kb.perforce.com/UserTasks/CodelinesAndBranching/BranchingWorkInProgress
which looks like it will provide more than you need.
There is also various p4shelve, p4tar options that might help:
P4 Shelve Python addition for any version of Perforce
P4tar offline (or at least off-server) saving of changes
p4 shelve 2009.2 and later Perforce feature to provide built-in shelving.
Here's one possibility...
Sync //main to the changelist where the branch was made. Resolve conflicts.
Important! Sync //v1 to the same changelist.
Open //v1/xx.cs for edit.
The ugly part: manually copy the local copy of //main/xx.cs over the local copy of //v1/xx.cs
Sync //v1 to head and resolve conflicts.
Submit changes.
Voila!