IntelliJ has the "task" feature where you can track the context for a Jira task, for example.
Now, I changed several files within this task und committed a few times. After a week, I returned to this project and I'd like to see all changed files for this task, from the start of the task until where I left of. I cannot find an option to do this, is this somehow possible?
By default creating a new task offers you to create a separate branch for this task. If you did so, all your commits are in that branch.
If you used another branch, I don;t think there is an easy way to do what you want. You could try checking the saved contexts under Tools - Tasks and Context - Load context
Related
Ocassionally I did hard reset on my current working branch. I restored all the changes lost but here I've another issue:
I have main branch named by dev_security.
I checkout it, I'm on it.
When I create new branch by selecting new branch from branches menu and give it test_branch name
it tells me that I've created branch from HEAD
Ok, I've deleted that branch.
When I am creating new branch by selecting the branch and them making new branch from it
Then it's ok and tells me that branch is created from dev_security
I am pretty sure before my hard reset operation it was the same and ALWAYS told me about creation from dev_security. How can I make it to behave the same?
git reset does not affect checkout action from IntelliJ UI.
In User Guide you can see the description of each action.
Therefore it is expected that you observe different behavior for different actions. There is no option to set the same behavior for different actions.
If you would like to see what commands exactly are executed when you perform different actions, then please open Git toolwindow, switch to "Console" tab and see what command exactly are executed.
With our TFS 2015 source control we require developers to check-in changes against work items.
However, we've had a couple of instances where a developer has checked in against one work item within our development branch, but then when merging to our QA branch they've checked in the merged changes to a different work item. An example of this is where a bug has been created underneath a PBI, the changes in dev have been checked in against a task under the bug, but then merged to QA against the PBI itself. This causes us issues with traceability.
I've seen that it's possible to add a check-in policy of "Work Item Query Policy". I'm just wondering if there is a way to write a query that will determine if the work item of a check-in after a merge matches the work item of the source changesets? I'm not necessarily after the exact query (though it would be lovely if someone could provide one :) ), really I'm just wondering whether it's possible or not to have a query to do this - i.e. is the information available to queries in TFS?
You can't do this with the existing policies, you'd need to build a custom policy.
So, technically this is possible. You can access the VersionControlServer object through the PendingChanges object:
this.PendingCheckin.PendingChanges.Workspace.VersionControlServer
You can use that to query the history of the branch in question and grab the work items associated to the check-ins in that branch.
You can check the associated workitems to the current workitem:
this.PendingCheckin.WorkItems
You could probably even provide the option to auto-correct by adding the correct work items to the checkin upon validation.
One of my policies provides an example on using the VersionControlServer from a policy.
I have asked a similar question
TFS Build Configuration: get all the Work Items Details for a particular build
And based on the answer of above question I have the below query. I decided to start a new thread for new question rather than confusing people in same thread.
I am using a default XAML template for workflow of TFS build configuration. Now my requirement is that I need all the Work Items since beginning whenever I trigger a build event for any build definition regardless of last successful build.
Let say I have triggered first TFS build and it is succeeded then I triggered 2nd build and that is also succeeded.
Then I have opened the log file of 2nd successful build and goes to Diagnostics Tab of last build. Inside Diagnostics tab there is a section as “Associate the changesets that occurred since the last good build”
Inside this it will display a message like
"No change sets are submitted to build 'ABC…..'"
Whereas I require list of all the work items since beginning.
Please suggest me the changes which need to be done in XAML template so that I can get all the work items since the beginning of source code.
As we know, associate the changesets and work items only occurs since the last good build.
There is a simple workaround to achieve what you want, you can specify a previous changeset to queue a build, then build the latest changeset again, then you'll get the associated changesets and work items again. Refer to this blog: http://chamindac.blogspot.sg/2013/09/tfs-2012-get-release-build-with.html
Otherwise, you need to create a MSBuild custom task that makes a call to TFS for the items. Check the links below:
https://volatilecoding.com/2013/06/11/tfs-build-how-to-customize-work-item-association/
(this solution is for TFS2010/TF2012 build process template, you'll
need to work on TFS 2013 build process template).
http://devgorilla.net/?p=104
Using the Microsoft Project VSTO, I am able to iterate through all the Tasks in a project.
The problem with this approach is that if a file has one master project and multiple subprojects, the Tasks collection for the master project will contain tasks from ALL the projects (master as well as subprojects).
Is there someway to differentiate whether the Task is from a master project or a subproject?
The easies way is Task.Project that will return you name of a project your task belongs to link also you can get name of a subproject from it's "ancor" task in your master through Task.Subproject link. There is also a field which tells you if the subproject is Read-Only or you can update it: Task.SubProjectReadOnly link
If you want to access only the main project, it might be quicker to start with the summary task and recursively deal with each task's children, stopping the recursion on tasks which represent external subprojects. That way, you will not have to touch every task.
We have a particular file, say X.zip that is only modified by 1 or 2 people. Hence we don't want the build to trigger on every check-in, as the other files are mostly untouched.
I need to check for a condition prior to building, whether the checked-in item is "X.zip" or not.. if yes, then trigger a build, else don't. We use only CI builds.
Any idea on how to trigger the build only when this particular file is checked-in? Any other approaches would be greatly appreciated as i am a newbie in TFS...
Tara.
I don't know of any OOTB feature which can do this, what you would need to do is write your own custom MSBuild task which is executed prior to the build running (pre-build action).
The task will then need to use the TFS API to check the current check in for the file you want and if it's not found you'll have to set the task to failed.
This isn't really ideal as it'll indicate to Team Build a build failure, which, depending on whether you're using check in policies, may be unhelpful. It'd also be harder to at-a-glance work out which builds failed because of the task and which failed because of a real problem.
You can change the build to occur less frequently rather than every check in, which will reduce load on your build server.
Otherwise you may want to dig into Cruise Control .NET, it may support better conditional builds.
If you could move X.zip into it's own folder, then you could set up a CI build with a workspace that only looked at the folder containing X.zip.
You would then need to add an explicit call to tf get to download the rest of the code as Team Build only downloads what the workspace is looking at.
But this might be simpler than the custom task approach?