I am using eclipse plugin for RTC. Not able to find a option to accept only some of the change sets and not all of them at one time.
Is there an option for this?
You should see in the "Pending Changes view" some work items or baselines in the "Incoming" section that you can unfold.
Once unfolded, you see a list of change sets: right click on one (or several selected together) and you can accept only those.
But if the change set depends on a previous one, RTC will will first propose to apply that change set as a patch.
The repository workspace you are accepting this change set into doesn't have all the change sets that led up to this change set.
You can try applying the contents of the change set as a patch or you could try and accept more change sets together.
Do you want to apply the change set as a patch?
Learn about patches and content accept:
You are accepting a change set that depends on change sets that are not already in your workspace. This would create a gap in the component's change history.
You can resolve this problem by accepting the changes as a patch.
So here: click cancel and widen your change sets selection.
Related
After mild frustration with the difficulty to make top-level "plain old folders" within Eclipse for visual-organization purposes, I discovered that the thing I'm after is called a "working set". Hooray! But they don't seem to be rename-able, by any of the apparent avenues (right-clicking on it or using the Configure Working Sets window).
Is that just the way things are, since no one should be so lazy as to refuse making a new working set with the right name and transferring everything over? Or am I missing something obvious?
I also have a more minor question whose answer I already think I know. Can I tell a specific working set not to change its icon to have the "red X" when one of its children has an error? Nothing in the preferences under Debugging suggests to me the ability to turn off the automatic icon-changing. It's a useful feature, but I have a few simple practice projects with very basic errors, and I don't need the visual reminder to "fix" them, especially if they're in my "Practice" working set, whose icon I'd prefer not to change.
To rename a Working Set, you need to get to the dialogue of selecting a Working Set (click on the white down arrow at the top right of the package explorer > Configure Working Sets..), focus on your Working Set and click the "Edit" button. There, you can change the Working Set's name, as well as what's actually included in the Working Set.
There is no way (that I know of) to change the icon display to avoid showing the errors marker.
I wanted to remove a work item association to an outgoing change set and then associate it to a new work item. However, I selected Remove... on the change set to remove the association, but it instead deleted all my code changes. This is bad. Can this be reverted?
Since it is a change set, that means it is a committed set of files.
If you selected "Remove" in the "Related Artifacts / Associate Change Request" dialog box, this shouldn't be an issue.
You always can test and make a second repo workspace, load that second repo workspace in a second local workspace and see if you get the change set back.
You can modify the flow target of your second repo workspace, and make it reference your first repo workspace, to see if you get that same change set in the "incoming" section of the "Pending Changes" view.
I checked-in some changes by mistake. Now the changes are in the outgoing changes, but I don't want them to deliver. How can I return them back to the unresolved? If I discard them they vanished from my source code and I lost my work.
You can still discard the change set: see this thread.
By discarding the change set, the changes in it will be reversed. This happens to be the addition of the files once the initial share was performed.
(hence the removal of those files)
To avoid this, you can disconnect the project then discard the change set.
(when you disconnect the project, select the option which don't delete the local files)
This kind of behaviour is intended as you would want to discard a change and have your local shared content to reflect the same state as your repository workspace.
You should be able to simply drag & drop files from Outgoing Change Set to Unresolved in the Pending Changes view. Then you can reuse the Change Set for some other changes.
This will work only until you mark the Change Set as Complete.
I created a label using the new label context menu:
I defined the parameters as follows: (unlocked)
Label:
ms_test
Description:
Created by ms
view:
//depot/Projects/Shared/...
//depot/Projects/AddIn/...
The label is created and shown in the label pane but when I select the label and click on the "List files at ms_test" menu item the log message states "Label ms_test points to 0 files".
Any ideas about why the label is not pointing to any files? How can I make this label to work?
thank you in advance.
Note: I have checked that the view paths are correct and there are file contents and subfolders under then.
I am using P4 client version 2006.1.105584 with no filter on the depot and my client is set to client view of the depot
That means no p4 labelsync or p4 tag commands occurred after the p4 label took place.
Did you create the label as described here?
The following instructions apply to the Windows client (P4WIN) only.
Click the label toolbar button to show the labels page.
Make a new label (right-click in the list); Give it a useful description.
Restrict the View to that needed by the project being labelled (See Using Wildcards and - - Excluding Files for examples).
Drag the project files from the depot over to the label;
Select Add/Replace Files Listed in Label… from the popup menu.
Perforce will open a dialog offering to replace the contents of the label.
Click Ok to add the files.
Even if your label currently references no files, you still can sync it with files:
Select the label from the Labels pane
Right-click to bring up the shortcut menu
Select Sync specific files to bring up a sync dialog
Click Select All
Click Ok
I suspect VonC's answer is pointing in the right direction. On a sidenote, it is worth pointing out that Perforce Labels are badly named and work very very differntly to Labels in virtually any other SCM system.
From the Docs
A Perforce label is a set of tagged file revisions. You can use labels to reproduce the state of these files within a client workspace.
Labels provide a method of naming important sets of file revisions for future reference. For example, you might want to tag the file revisions that compose a particular release with the label release2.0.1. At a later time, you can retrieve all the tagged revisions into a client workspace by syncing the workspace to the label.
Create a label when you want to:
keep track of all the file revisions contained in a particular release of software,
distribute a particular set of file revisions to other users, or
branch from a known set of file revisions.
Essentially what this goobledygook means is that whereas most people use Labels to do exactly what a Changelist number does (eg. Mark a particular point in time) it infact marks the set of files currently synced to in a particular client. This is a bizarre quirk of Perforce and possibly the worst design decision they made in an otherwise wonderful product.
You are probably better off taking note of the changelist number you want (generally the latest at a point in time) and the paths you wish to sync to , that is all the information you need to sync to a point in time.
As of Perforce 2010.1, the correct way to do this is using automatic labels, which are really just a way to name a changelist.
Whenever I switch working sets in the project explorer, the working set does not switch for the search and call hierarchy views, so I end up with search results from the wrong working set if I forget to switch those over manually.
Is there a shortcut for switching working sets in all those tools simultaneously?
Thanks!
There is a special working set concept in Eclipse called Window working set which is basically a 'centralized' way of managing your working sets.
You can set up your working sets in Window / Working Sets. Most views which have support for working sets have an option to select this special working set (as you can see here). After finishing the setup you can turn on/off your active working set in Window / Working Sets and all views are automatically use the changed values.
Project explorer, call hierarchy and search support this feature.
To obtain some automation with Working Sets I suggest the following...
First of all a premise. All the views that support Working Sets ask you to select which one they are going to refer to. In the selection dialog, usually, you will find the name of the currently defined Working Sets AND the label Window Working Sets. The latter is, as Csaba_H was saying, some sort of centralized Working Set manager.
Therefore, make sure that every time you need to select a Working Set, your Window Working Set label is selected instead (in the search it's the last input field, press the Choose button...in the Package Explorer, it's the first entry above your WSs).
This is important because when you now change the WS selection within the Window Working Sets (sorry, a lot of WS here), you will automatically change all of them! You will see the Package Explorer change, for example.
As said here already, you can change it through Window -> Working Sets (if the entry is not there, just Window -> Customize Perspective... -> Command Groups Availability tab -> tick on Window Working Set). Not only that, now you can assign a shortcut under Window -> Preferences -> General -> Key -> Select Working Sets (category Window) and use the shortcut to open the selection dialog and change WS from there!
Hope it helps.
Not sure there is a direct way, but what you can try is (just for testing) to associate one perspective to one working set.
I.e. define a package explorer, a search view and a call hierarchy view:
all set to working set WS1 in perspective P1.
all set to working set WS2 in perspective P2.
That way, you should be able to switch perspective, effectively switching working set at the same time.