I have a project in IBM ALM which uses several external components. Every time the team developing those components makes a release, they create a snapshot with baselines for all components. As a result, when I want to update my project to the latest release, I see incoming changesets on all components, most of which consist of only the baseline labels with the snapshot name, with no actual code changes.
Is there a way to automatically accept all such "empty" changesets, so that I can clearly see the remaining components which have actual changes and have a chance to analyse those changes before accepting them?
That was asked 4 years ago in this thread, and referred to RTC Work Item 189873, which was rejected.
This thread proposed:
As far as I known there's no way to hide incoming change sets.
But you can hide empty baseline created by other users from Eclipse Preference, select Team > Jazz Source Control > Changes.
In the right panel, uncheck "Show all baselines (including empty baseline and baselines created by others)".
Related
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".
We are using ClearCase using a single Dev stream for our team, without 'locking' (Unreserved check outs).
ClearCase client version: 7.1.1
ClearCase server version: 7.0.1.2
We have performed the same test, without using the "Graphic merge". This option worked as expected! Maybe this can shed some light on past defects on ClearCase or workarounds.
This means that 2 or more people can make edits to the same file at once, without having to wait for for the file to be checked in.
We have seen a few cases of weird behaviour and experimented a bit today to find the following scenario that takes place:
File.txt is checked out by 2 team members.
Each members makes a change in the file (in other regions of the file).
First developer checks in the code to ClearCase, no problems here.
Second developer checks in, gets a merge popup notification.
When selecting "graphic merge", ClearCase in this case informs that all merges were done automatically and no additional input is needed from the developer.
Looking a little further, the first check in was removed (deleted), keeping only the later check in changes.
Why is this happening? This is causing our team to lose code on several occasions already. Are we doing something unsafe/wrong ?
Edit: Illustrating the problem with images of the issue:
The file Manager.cs is at version 27.
Two developers are checking it out.
One made a change, checked in.
The other checks in, gets the merge notification.
This is what i see in the graphical merge:
Note that on the left is version 27, in the middle version 28 (the latest checked in version), and on the right is the result which is dropping version 28's code change !
Why is this happening automatically??
Image can also be seen here: Image
Note: if you are using ClearCase without 'locking', that means you are doing unreserved checkouts (and not reserved checkout).
If you select "graphic merge", you should see a Windows helping you to reconcile the merge, even if there is no conflict.
Such a merge should not delete any previous checkins: it might cancel the previous modifications, only if all the new changes are selected, but if you have the graphical merge window open, you can control how the merge is applied.
For your past problematic merges, you can easily from the version tree re-apply the merge from the previous version of dev1 to the LATEST version, in order to reapply those canceled changes.
Since my initial answer 4 days ago, 2 new information came about:
ClearCase client version: 7.1.1 ClearCase server version: 7.0.1.2.
That is never good to have a client with a version more recent than the server.
We have performed the same test, without using the "Graphic merge". This option worked as expected!
That would be consistent with some discrepancies already seen between the GUI for merging and the pure command line (as in this other scenario).
When the GUI fails, always try to fall back on the pure CLI (Command Line Interface).
Is there any way using Subclipse or Subversive to apply some kind of filter on Package Explorer that will hide all files that weren't modified locally?
It would be sometimes very useful when I just want focus on my local changes (for example to revise them). I know that files that were modified locally are marked in Package Explorer (in Subclipse by "star" symbol) but in big projects with hundred of files it doesn't help that much (it would be much easier and clearer if only modified files would be visible).
Of course packages containing modified files should be visible as well.
Have you tried the Synchronize view? This shows all your changes in a view which makes it easy to work with the items. You can also create and group items by changeset when using this view.
Using Subclipse, I set the Synchronize view so that all SVN projects in my workspace are synchronized. I then pin it and set a schedule to refresh every hour. Local changes refresh immediately, the hourly schedule is for how often to check the repository for incoming changes.
You can out the view in Outgoing mode if you only want to look at your local changes.
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.
My team is working with VSS and we are having difficulties managing versions:
We want to take a "snapshot" of the project we're working on, so we can keep working on it, but when we need to - we can get the files of the snapshot and built them for a release. (Is that called branching?)
Alternatively, getting all project files by date would be great too. (Meaning I would get the last checked-in version of each file in the project prior to the specified date.)
Is there any tutorial regarding this? I searched the net a bit and only found very simple howto's.
Thanks.
As Cannonade wrote, a label might be what you want. But since you explicitly mentioned branching in your question, you should be aware of the differences between a label and a branch:
With a label, you simply mark the current state of all files in your source safe database (the repository). If you created a label "V1.0", you can now at any time easily retrieve exactly that state and rebuild the V1.0 release for example.
With a branch, you create a copy of the current state of your repository. E.g. if you create a copy named "1.0", you can then continue with the development e.g. towards V2.0. Should you ever need to fix a bug for V1.0, then you can do this on the "1.0" branch.
So branches should be used to work on different versions of your projects in parallel. Labels should then be used to mark special versions on your branches (e.g. the ones used to create a release).
One last note: SourceSafe does not have a specific "branch" command. Instead you "Share" your solution and select the option "Branch after share". You can find more information about it in MSDN.
And a very last note: We stopped using SourceSafe about 1.5 years ago and switched to subversion (which is opensource and free). Have a look at subversion or other solutions. I can not imagine ever going back to SourceSafe.
You can apply a label to a current snapshot of source safe (like BUILD1) and then get the tree based on that label at a later date.