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.
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.
How do I have a Project Explorer's Working Set be built automatically from the contents of .gitignore, and then kept in sync with .gitignore?
I am working on a C++ AutoTools project which, as it is common for AutoTools projects, generates quite a lot of files during the build stage. I do have them .gitignored already. Now I'm trying Eclipse on that project, and found that I'd have to carefully pick files to ignore again.
You cannot. This feature does not exist.
The working sets functionality was implemented a long time before GIT appeared, and it was a method for removing clutter in large projects, and what is important, it was was a method that resided in the UI domain.
In fact, A working set extension point documentation shows it is possible to create a self-updating working set, and the search over the egit codebase returns no results.
As I have said, this feature is not implemented.
However, you can create your own plugin that will do what you want. It is not very complicated, and should not take more than a day or two. Or just open a feature request in the Eclipse bugzilla.
As for your underlying problem, you could try using the derived resources mechanism. It was added to make possible to prevent team providers (CVS/GIT) from managing files that are a result of a build.
Just a word of warning - GIT won't allow you to ignore further changes to any resource already under its control.
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".
There are often conflicts in the Xcode project file (Project.xcodeproj/project.pbxproj) when merging branches (I'm using git). Sometimes it's easy, but at times I end up with a corrupt project file and have to revert. In the worst case I have to fix up the project file manually in a second commit (which can be squashed with the previous) by dragging in files etc.
Does anyone have tips for how to handle merge conflicts in big and complex files like the Xcode project file?
EDIT-- Some related questions:
Git and pbxproj
Should I merge .pbxproj files with git using merge=union?
RESOURCES:
http://www.alphaworks.ibm.com/tech/xmldiffmerge
http://www2.informatik.hu-berlin.de/~obecker/XSLT/#merge
http://tdm.berlios.de/3dm/doc/thesis.pdf
http://www.cs.hut.fi/~ctl/3dm/
http://el4j.svn.sourceforge.net/viewvc/el4j/trunk/el4j/framework/modules/xml_merge/
Break your projects up into smaller, more logical libraries/packages. Massive projects are regularly the sign of a bad design, like the object that does way too much or is way too large.
Design for easy rebuilding -- this also helps if you're writing programs which must be built by multiple tools or IDEs. Many of my 'projects' can be reconstructed by adding one directory.
Remove extraneous build phases. Example: I've removed the "Copy Headers" build phase from all projects. Explicitly include the specific files via the include directive.
Use xcconfig files wherever possible. This also reduces the number of changes you must make when updating your builds. xcconfig files define a collection of build settings, and support #include. Of course, you then delete the (majority of) user defined settings from each project and target when you define the xcconfig to use.
For target dependencies: create targets which perform logical operations, rather than physical operations. This is usually a shell script target or aggregate target. For example: "build dependencies", "run all unit tests", "build all", "clean all". then you do not have to maintain every dependency change every step of a way - it's like using references.
Define a common "Source Tree" for your code, and a second for 3rd party sources.
There are external build tools available. This may be an option for you (at least, for some of your targets).
At this point, a xcodeproj will be much simpler. It will require fewer changes, and be very easy to reconstruct. You can go much further with these concepts to further reduce the complexity of your projects and builds.
You might want to try https://github.com/simonwagner/mergepbx/
It is a script that will help you to merge Xcode project files correctly. Note that it is still alpha.
Disclaimer: I am the author of mergepbx.
The best way I have found is to instruct Git to treat the .pbxproj file as a binary. This prevents messy merges.
Add this to your .gitatributes file:
*.pbxproj -crlf -diff -merge
To compare two Xcode projects open open FileMerge (open xcode and select Xcode (from the manu pane) --> Open developer tools --> FileMerge).
now click "left" button and open xcode project main directory.
click "right" button and open xcode project main directory to compare.
Now click "merge" button!
Thats it!
Another option to consider which may help to reduce the number of times you experience the problem. To explain, I'll call the branch that team members' branches come from the "develop" branch.
Have a convention in your team that when the project file is modified, the changes (along with any other changes required to ensure the build integrity) are committed in a separate commit. That commit is then cherry picked onto the develop branch. Other team members who plan to modify the project file in their branch can then either cherry pick into their branch or rebase their branch on the latest develop. This approach requires communication across the team and some discipline. As I said, it won't always be possible; on some projects it might help a lot and on some projects it might not.
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.