In eclipse we have possibility to create psf file using Export --> Team Project set and use that psf to create new workspace code.
Is there a similar possbility in ALM to get the information out of snapshot and use it as psf?
This is not exactly like a project set file (psf), but in RTC, you can memorize the exact state of multiple repos (here in RTC "components") with a stream.
By communicating the stream name, any collaborator can create a repo workspace on that stream and checkout (in his/her own sandbox) the components.
That is what you find in this thread for instance::
Instead of a .psf file, you would use an RTC stream.
When someone has changes that they want to make visible to the rest of
the team, instead of updating the .psf file, they would deliver their
changes to the RTC stream.
Conversely, when you want to catch up to
the changes being made by other team members, you would accept changes
from stream (rather than pulling a set of tags).
See also this thread:
A team project-set (Eclipse) can be exported to a .psf file while working-sets are part of your preferences.
The team project-set was added to eclipse to augment SCM systems which didn't make it easy to bootstrap and get the right line-up of projects.
In Jazz we recommend you setup a stream with the component/projects your team members need to work on and they can simply create their own repo workspace and load it.
When a repo workspace is loaded, we automatically create a working-set for each component that is loaded, as the documentation quote above mentions.
Related
I am trying to connect my code to a ClearCase Stream. Currently I'm operating under the belief that, once connected to ClearCase, the "Deliver Stream" activity from the drop-down menu will perform this task.
However, all the literature I have read is just vague enough that it isn't clear if this will overwrite the code that is currently in that stream, or if that code will overwrite the code that is currently in my workspace.
I do not want to lose my workspace code, nor do I want to overwrite my ClearCase code if I can help it.
Will this "Deliver Stream" activity do either of these things? And, more importantly, will it actually connect my code to source control?
If not, and this is really the heart of my question, then how do I connect my RAD 7.5 workspace to a ClearCase source controlled file sharing system?
It won't affect your workspace, but I would recommend doing those operations outside of RAD first, to be sure of what is actually taking place:
I am trying to connect my code to a ClearCase Stream
First: is your code versioned in ClearCase in the first place: is your workspace part of a (snapshot) ClearCase view attached to an UCM Stream?
If not, you need to create an UCM dynamic view attached to the right stream, and use clearfsimport to add your files.
Once the import is done, create a snapshot view on the same stream to be used in RAD (since, as I mentioned in your previous question, dynamic views aren't well suited for compilation)
if this will overwrite the code that is currently in that stream, or if that code will overwrite the code that is currently in my workspace
A Deliver Stream is about:
deliver and integrate change sets to the integration stream once an activity has been completed.
For example, if your task was to create a new feature A, you can deliver a change set relating only to new feature A into the integration stream.
That means your current workspace represents a snapshot view loaded and attached to a child stream "FeatureA", and "Deliver Stream" would trigger an UCM deliver between your current (child-)stream FeatureA and the parent Integration stream.
See more at "Integration stream vs integration view in ClearCase".
If you do a "Deliver Stream" from RAD:
As you deliver your changes to a stream, we suggest that you have two different instances of Rational Application Developer open:
one workspace will have your development workspace which contains the complete changes,
and the other will have the integration workspace open.
If you invoke the Deliver Stream option from the integration workspace, your changes automatically appear in the workspace.
If you deliver from your development workspace, you will have modified the file system outside of Rational Application Developer.
In Eclipse PDE, when looking for resource changes (using IResourceChangeEvent), how do I find out exactly when a project is created? Do I have access to the project (as an IProject) in this context?
Several parts to this answer:
When resources change, your listener gets an event. From that event you can get a delta describing the resources that were changes. You implement a visitor (passed to the delta with the accept() method) that actually implements your response to the change and controls how far down the delta you want to traverse by answering a boolean from its visit() method. You probably won't traverse too much since any new projects will be at the top of the delta. Once you've recognized that you're visiting a delta node representing a new project (you use flags() and getKind() to see whether or not it's a new project) you can take whatever action you'd like.
The other part of this answer is to warn you that often resource changes are batched, usually for performance reasons, so you might get notified of a new project being created after many files have been created into that project.
To augment the other answer that referenced resource change listeners...
Reliably detecting project creation is actually rather difficult. The issue is what you define as project creation. To the Eclipse resources layer, project creation is when a blank project is created (no metadata or files of any sort), but in a typical scenario you want to know when a particular kind of project is created.
This means that you cannot assume that when your code receives a project creation event, that you will be able to ask questions about that project. Project creation event may be delivered together with subsequent file events in a single batch or the events may trickle in separately.
Another consideration is that to Eclipse project creation is a number of different scenarios. It could be user running a project creation wizard, or importing existing project from disk, or importing from Git, or any number of other ways that a third party plugin may cause a project to be added to the workspace. Each of those scenarios will have slightly different way in which events are batched or trickle in.
The only solution is to look at file events as opposed to project events. Figure out what questions your listener needs to ask of the project, then figure out what files contain the answers and track those files. For instance, if you need to check for a nature and a classpath entry, monitor .project and .classpath files. Don't assume that the project is always in consistent state. It may not be if you are looking at it part way through a Git import.
Going forward, our group will be developing .NET apps using TFS, and the application lifecycle management will be great.
We also have a lot of legacy java apps that we currently version by zipping them up and throwing them in source safe. Or an other example would be a couple of stored procedures used for a report or scheduled job, we want them versioned and backed up with the rest of our source.
Can we achieve that same sort of one off functionality using TFS? We'd like all of our source in one place, but some of it just needs to be very simple. Thanks for your help.
Yes.
TFS is made to handle your scenario- not just to manage your SDLC and .NET applications.
For example, we store our legacy SPs and documentation in TFS. You can have those files versioned with your development branch too if you so desire. Essentially anything you can do with the code for your .NET application in terms of versioning you can achieve with all of your legacy files as well.
So you can feel confident, moving forward, that your choice to move to TFS is the right one if that is your only outstanding concern.
How to Add Files
Go to Source Control Explorer (View -> Other Windows -> Source Control Explorer or Double Click in Team Explorer View).
Navigate to where you want to store your legacy files in the structure or if you need to create a new folder to store the files (Icon is on the left of the toolbar).
Once the folder is created, click the icon with a little plus beside it to the right of the new folder icon to "Add Items to Folders." You can also right-click in the window to the right-hand side that shows you the files in the folder and both create new folders and add files to the folder.
Inside of this dialogue you can select your legacy files and add them to TFS.
I just want to know if the search result in eclipse search view can be shared with fellow team mate as it is.
I perform a search and delete few unwanted entries and then send it to him/ her
The other person shall be able to view it exactly same manner in the search view.
Is there a way to do this?
The will be very helpful for me
You should be looking at the Mylyn project (http://eclipse.org/mylyn).
This project allows you to create tasks and send them to co-workers through a task repository (such as bugzilla, jira, or most major issue trackers). Attached to these tasks are "contexts", which associate code elements (methods, fields, classes, etc) with the task.
Here is what you would need to do:
Install mylyn (you and all co-workers)
Install the proper connector for your issue tracker (most major issue trackers have one). If you are not using an issue tracker, then you can still import and export tasks as files, but it is less easy to do, and I'd recommend using an issue tracker anyway.
Now add the task repository to your Eclipse. This is the way that mylyn speaks to your issue tracker. It allows you to create issues, bug reports, tasks, etc, from within Eclipse.
With this set up, you can now create a task associated with a task repository and activate it. You can add the desired program elements to your task by right clicking -> Mark as Landmark.
Once you have your task context complete, you can then attach the context to the remote repository (essentially attaching a zip file to the issue in your issue tracker). Other users can then retrieve the context and immediately start working with the context that you created.
It is really a great way to work when you need to share information about specific features in the code to other people on the project.
I have been using an open source Java project and had to make some custom changes for our site. I have downloaded the source code via Subversion, modified two files and built a custom JAR file. Now I need to store these custom changes into OUR Subversion source control system. What is the best way to do this?
Should I check the entire tagged version of the open source code into our system and then create a branch with our change in it? Or should I just check-in our custom files and rely on the open source tagged version to always be around? Or perhaps something else altogether?
Take a good look at Subversion vendor branches, which are meant for "maintain[ing] custom modifications to third-party data in your own version control system". This sounds like exactly what you want. You would create a vendor branch for the open source Java project in your main repo (from their last SVN revision before your modifications). Then, check in your modifications. In the future, you can merge in upstream changes.
The Subversion book is free and available online, with a section devoted to choosing a repository layout.
the Subversion community recommends
that you choose a repository location
for each project root—the “topmost”
directory that contains data related
to that project—and then create three
subdirectories beneath that root:
trunk, meaning the directory under
which the main project development
occurs; branches, which is a directory
in which to create various named
branches of the main development line;
and tags, which is a collection of
tree snapshots that are created, and
perhaps destroyed, but never changed.
I'm happy to elaborate if you are having trouble determining what exactly this means for your project.
First try to avoid this as long as you can, if it is possible try to get your changes into the open-source project (less work for your self in the future...)
But if that was not a option, I would follow Matthew Flaschen advice about vendor branches.