We're using RTC/Jazz SCM and I'm the Configuration manager in our team...
So I setup the RTC/Jazz SCM, I created a component, I created a stream, I created a repository workspace and a local workspace, the repository has the stream as flow target.
After I shared an eclipse Project I did some other changes and my component grew and grew...
I made baselines whenever I made a build. Now my coworker are asking me: how can I know if my file is in this or that build, and I'm not sure how to answer their question, so
How can you show all BASELINEs on a FILE?
The article "Practicing source control archaeology with Rational Team Concert" shows that a file History view only shows change set, not baselines:
If your change set is linked to a work item, that work item id will be part of the change set title.
And it is better to consider work items instead of files, because for a given build (see this thread), you can use the "Work Items link",the one in the Contribution Summary section of a build result.
You can then have a look at "Work items included in this build": work items whose change sets are included in the configuration being built.
This differs from "Work items reported against this build" (top right corner of a build result), which are ones that you explicitly associate with the build (commonly, work items that created after the build was completed, that refer to information generated by this build, such as errors reported in the build results).
So there isn't a direct way, but looking at a build result can help find a work item you know your file is a part of.
Scott Cowan adds in the comments:
you can easily get to a change set's work item to find it's build results by:
selecting the file version in the History view and
in the context menu select "Related Artifacts > Open".
Related
I see this feature is available, but I can't seem to get it to work the way I expect it to. Am I misunderstanding the capabilities of this feature?
When creating a build pipeline there is an option (since 2017) to automatically link a build to work items. Under this option is an Include and Exclude list for branch specifications. The default is Include * which searches all branches for work to link since the last successful build.
I'm trying to implement a branch naming convention because we have many solutions in the same repository and don't want work items relating to system 1 to be linked to the build of system 2.
To do this I'm using an Include sub2/* branch spec, but the build doesn't seem to link correctly.
Custom Branch Spec
Change on Branch Outside Spec
No Other Commits Linked to the Work Item
The Work Item Still Shows on the Build
BUT the build doesn't create an Integrated in Build link on the work item.
For changes made WITHIN the branch spec
The functionality of the build showing the work items in the progression (seen above) includes the work item as expected, but the Integrated in Build link is still not added to the work item.
Is it possible in EGit to see the simple history of a file?
Team > Show in history shows all commits to all files. Not useful.
I am looking for the history of a file. There is a button in the History view that says Show changes to selected resource but no way to select a resource.
There also does not appear to be any way to compare with a specific version unless that version has a tag.
The pieces seem to be there, but are they put together properly?
(No complex branching or other cleverness. I normally use the command line for this type of work but should not have to.)
You can open a file (or select it from project explorer) and do:
Right Click -> Team -> Show in history. This will open the following view:
The filter circled in red is: "Show all changes of selected resource and its children" which basically will filter only the commits that relate in any way to the resource you've selected (you can chose the different filters to get a better understanding of how they differ from each other).
The problem was that the Team > Show in History needs to be run from the Project Explorer window. When I first found those scoping buttons I right clicked on the class file's edit window and did the Team > Show in History there. That appears to be broken and only shows all changes.
(Thank you for your replies. Knowing that it could be done and by those scope buttons let me look further. I rarely use the Project Explorer, preferring to just type the class/file name into the Navigate dialog.)
Some other answers suggest clicking on Team > Show in History. This menu item does not show up. Instead, Team > Show Local History shows up.
I have Git Staging tab open all the time. I saved a small change to the file I wanted to see the history of. This caused the file to show up in the Unstaged Changes in Git Staging. I then right-clicked on the file, clicked on Show In and then History. This showed me the history of the file according to Git.
I'm having problem with deploying changes to Sitecore item. I've made changes in the template item in Sitecore. All changes of Sitecore items are stored in TDS. During the build TDS generates an update package, then I install this package using Sitecore UpdateInstallationWizard during deployment.
The problem is that I've already deployed several builds, and just found out that changes are not applied to this template item: I've removed one field from the item, but it still appears, also I've changed another field value in the _Standard Values but it does not change after deployment.
Could you please help me to find the cause of this issue? Is there any way to review what items are in the package?
UPD: I've renamed package into zip and was able to find the template item itself and standard values for the item in the addeditems folder. As I understand it right it should mean that the item with all the changes is in package, but for some reason they are not applied.
By default, TDS will NOT remove anything from Sitecore. You need to setup the child item synchronization settings and enable removing/recycling items in the build property page for the target environment. Please see:
http://hedgehogdevelopment.github.io/tds/chapter4.html#deployment-properties
http://hedgehogdevelopment.github.io/tds/chapter4.html#build
http://www.hhogdev.com/help/tds/deploymentproperties
For more information. I recommend that you use the deployment property manager window to make sure your templates are set to "Always". Tell TDS to put items in the recycle bin in the build property page and backup your target database before trying this for the first time. Once you get the hang of the deployment properties, it is pretty easy to manage.
You can review the actions applied from an .update package within the update installation wizard itself, right after applying the package. Click the button labeled "Installation result>" and try filtering the list to look for warnings and errors related to your item.
Another option is to review logs located at ~/temp/__UpgradeHistory/ folder. In particular, I would look at the messages.xml file.
We have a lot of Build Definitions and i want to create a category or a subfolder to make less mess (what a phrase) in our Project
this image shows only half of our build definitions and i really want to clean up here!
i've tried the context menu (right mouse button) but i didn't find any useful items there.
There is no "subfolder" option, for build (for grouping builds together) or even source control (for grouping streams together) in RTC (3, early 4).
The "Administering Rational Team Concert Builds" only suggests tagging builds
You can tag builds to organize them or identify them for search purposes.
You can also select a tag from an existing list of tags.
A tag is a single word with no spaces.
A build result can have multiple tags associated with it
Update 2015: as mentioned in Enhancement 217033 (even though it was triaged in Enhancement 303863), also mentioned in Task 303722:
RTC 4.0.6 has the capability to organize build definitions into build folders.
RTC 5 has that feature fully implemented, as mentioned in Enhancement 300232.
The OP Martin Frank adds this image:
Once a folder is created you can drag&drop the build definitions into the desired folder.
I'm trying to migrate to TFS from VSS and I need to be able to show what files were checked in between two releases. In VSS we would just label the code for a release and view history between labels and generate a report to show the checkins and the comments. Is there a way to get similar results with TFS? Or show the differences between two changesets or labels?
The command line tool tf.exe gives you more options than the GUI (and can either give results in a Dialogue or as standard output --- good for feeding into further processing).
E.g.
tf hist . -r /version:C10~C1000
will list all the changesets affecting this folder and content recursively between changesets 10 and 1000.
See the documentation on MSDN.
If you need maximum flexibility, you can create your own commands using the TFS client assemblies. Unfortunately documentation is somewhat sparse.
Right click on your desired folder on TFS (e.g. the root folder), you'll find following two options:
1, Apply Label - this allows you to apply label to a particular version of that folder.
2, Compare - this allows you to compare that folder between versions, and one of the choices is comparing by label.
Right click on any node in TFS Source Control and choose 'View History'
This will show you all changesets ordered by date descending.
Double click on those and you can see the detail about the change set: the comment, associated work items, and files that were changed.
As Jeff said, right-click on the project, any folder or file, and choose "View History" to see all changes. If you know when your labels were applied, it's easy to scroll down this list until you hit a particular date/time.
For an exact list between two labels or changeses, use "tf.exe history" (as Richard says) from a Visual Studio command prompt (in your start menu in the Visual Studio 2005 folder). For more info on this just execute "tf.exe help history".
For day to day changes, if you use TFS build you can see the changes since the last build at the bottom of the build information page (Double click the build name in Team Explorer, then double click the specific build. Scroll to the bottom of this page and open "associated changesets". I've set out CI build to not associate changesets, which means that our daily test build lists all changesets since the previous daily build - a great summary of the changes for our testers to get their teeth into.
I was using the command line tf hist and getting the changesets to compare by finding the highest changeset in a label or branch changeset, but having a manual process and using the command line didn't go over too well here. I used Carl Daniel's code to write a little web application that will bind the changes to a datagrid.
If you're looking for something special the standard interface doesn't give you it's fairly simple to write your own application that links into TFS. I'd definitely suggest it.