How to revert to changes to previous revision using smartgit?
I can't find an option there
I suppose you want to return to one of the past commits.
Click on "Log" on right hand side of the window then choose the commit you want to return to and select "check out". The older version is now checked out.
Then you can commit and push that file.
Related
I have a static view with some files checked out that I am working on. Someone else checks in a bunch of changes that I want to add to my view. So, I run update on my view. It turns out they changed a file I have checked out. Now my view is left only partially updated and may not even compile until I figure out which checked out file I have to manually merge.
I know I can reserve my checkouts, but that blocks other devs from checking in stuff they are done with.
According to: http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m1/index.jsp?topic=/com.ibm.rational.clearcase.cc_ref.doc/topics/ct_update.htm
update does not apply to files or directories that are checked out to the current view.
So, it seems it's working as the atria/rational/IBM folk want it to work. I don't understand why it works this way.
Is there any way to update my static view and also automatically merge changes into my checked out files?
Is there any way to update my static view and also automatically merge changes into my checked out files?
Not really, since a checked out file is a file being modified locally, and cleartool update tries very hard to not touch any local file.
Your checked out file is selected by the element * CHECKEDOUT selection rule, which means any update won't update it (it is already selecting the right version).
You need to check in those file (triggering the merge, similar to "To merge the latest version to a hijacked file"), and check them out again.
But that isn't always possible since it would make a work in progress visible (checked in) to other views in the same branch.
The only other solution is to compute a patch between the checked in version and your checked out file, and apply that patch cleartool lsco -all -s -cview | xargs cleartool diff -diff, with the difficulty to diff between your checked out version and the LATEST version.
I have a component which contains outgoing changes :
When I right click this component and compare against the 'initial baseline' I get a list of change sets which comprise this component. This is displayed in the 'Change Explorer' view :
Is this the list of change sets over time that have been delivered to this component or change sets that have been delivered to a baseline, or is it both ?
By right clicking on each change set I see the option to 'accept' the change set. Should this copy the selected changeset into my workspace ?
If you see accept on a changeset, that means it is part of the incoming changes, done and delivered over time on the stream.
If you accept those, and if your component is loaded in your sandbox, then yes, those files will be copied over on your hard drive.
To be clearer, the "Change Explorer" (compared to your classic "Pending Changes" view) is about source control exploration (ie finding, and if needed, accepting old changeset that you need to see back in your repo workspace, and, if the corresponding component is loaded, in your sandbox or hard-drive)
See "Practicing source control archaeology with Rational Team Concert"
Choosing Open in Change Explorer on a change set will show you the all the file versions and directories involved in that change set.
Decorators and clarifying comments are displayed to help your understanding of what had occurred:
File or directory changed:
File or directory added:
File or directory deleted:
Within 'Pending Changes' RTC source control is listing my target folder as an outgoing change. My project is maven based. I have not made any changes to the target folder.
When I compare the target folder with the stream I am flowing to I there are no differences displayed :
Is there some other criteria that is causing the 'Pending Changes' view to list my target folder & how can I determine what change is being recognized by RTC ?
When I try and undo the changeset within the target folder I receive the error :
The little + in the black arrow above the 'target' directory means RTC detects said directory as a new element to be delivered.
That means you must have checked in that directory with the rest of your changes.
Generally, target should be ignored (ie never considered to be checked-in in the first place).
In your case, you should:
remove that directory from your changeset (assuming you didn't already complete the changeset): try undo on the target directory within your changeset.
(That would actually trigger, for a newly created element, the error message
"Undoing this change would produce an orphan with no parent folder").
Right-click and select "ignore"
(don't select "Reverse" on the changeset itself: it would roll back all the changes currently checked-in)
add it to your .jazzignore: the ignore option will add or create a .jazzignore, in order to declare your directory in it.
Of edit your .jazzignore if you have already one, with a content like:
core.ignore.recursive= \
{target}
Note: with ClearCase, the issue is different, since ClearCase doesn't detected what is private from what is checked-out (and you don't check out with RTC).
You need to ask explicitly for all private files or all checked out files.
I'm about to do a commit in TortoiseSVN involving rearranging a lot of files and directories. On the "commit" window, there are several files whose text status is "deleted" or "added" but others whose text status is "deleted (+)" or "added (+)". What does the (+) mean?
(It's quite difficult to Google for a plus sign, and the word "plus" turns up lots of hits about the blue overlay icon meaning "added")
The "+" means that TortoiseSVN was able to figure out the item's history, and has added the history metadata to this commit. For instance, say you rename a file from a to b. If you see the (+), Tortoise knows that you didn't really delete a file called a and make a file called b, and has determined that a rename took place.
That's good, because it means you can trace the history of b backwards to the point where it used to be a. Otherwise, you'd hit a dead end, and it would look like b sprang out of nowhere in the history. You can mouseover these entries and see more details about where they came from.
Deleted(+) is used to indicate that the file isn't really gone, it's just been renamed, and there is an associated added(+) that represents the new file.
We have a patch model where we're intending on using cset.pl -findmerge <activity> to selectively merge cumulative activities to a patch stream (integration stream to integration stream). Note that we're using a single stream model; although support for teams working with their own dev stream would be supported (i.e. when they join a project they would be working with the integration by default).
However there's the issue of activity dependencies we're trying to solve.
So say you have integration stream A,
file a.txt
-> Change 1 (baselined ReleaseA)-> Change 2 -> Change 3
fileb.txt
-> Change 1 (baselined ReleaseA)-> Change 2
an integration stream B and the config. manager decides they want to include "Change 3" in a new patch (patch integration stream - integration stream C).
They perform a cset.pl fetchmerge against Change 3 (which includes changes for Change 2).
Change 2 for fileb does not get picked up so the issue is identifying these activity dependencies.
Anyone have any ideas?
If Change3 is a rebase/deliver activity you can use
%ct lsact -contrib Change3
to get a list of contributing activities
and then traverse any of the rebase/deliver activites listed as contributing
activities to trace if any of them has Change2 as the contributing activity.
Also assuming that the foundation baseline for the patch stream is the one used for RelaseA,shouldn't you need to list activities from Change1 onwards when you do the merge ?
i.e shouldn't your findmerge invocation be something like
%findmerge ... Change2,Change3 -fcsets ...
Note (in addition to sateesh's answer), a deliver -act Chaange3 (instead of a findmerge) would list Change2 and Change1 as activities to include in your deliver.
It would pick up on those dependent activities, probably following an algorithm close to the one described by sateesh.
See "About activity dependencies in the deliver operation"
alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/deliver_depnd.gif
Had to use a variety of cctool commands to view current version in view and pushed it into a script to get a list of activity dependencies