I am using 8.0.1.6 version of Rational Clear Case Explorer.
Version Tree is not popping up while checking using the Tools -> Version Tree option in clear case explorer.
Sorry, but all I can do is ask questions here:
Did it JUST start happening?
Does it also happen when you run "cleartool lsvtree -gra {element name}" on the command line?
Is this happening to all users, some users, or only specific users?
Is the issue limited to one or multiple users?
Does the problem follow the users?
You may want to delete the HKEY_CURRENT_USER\SOFTWARE\Atria\ClearCase\CurrentVersion\clearvtree key as a quick test. That is where user-specific settings for the vtree browser reside, and that may clear the issue.
If you are on Windows, see technote swg21238290: in addition of the registry cleartree key, you have other workarounds mentioned there.
But if you are not on Windows, or if you don't see any error message (meaning the clearvtree simply hang and refuse to be displayed), look for any log: Windows log event, and of course ClearCase logs using cleartool getlog. You might find a clue there.
Related
I am trying to install matomo by following the instructions in the website. But no luck, i keep on getting errors. I am using xampp to host the matomo.
First, I downloaded matomo, extracted it inside htdocs folder of my xampp. Then I go to localhost/matomo. It shows the installation welcome page. I click on Next and after a while got error "No database selected"
I researched and i read something that I need to create a config.ini.php and specify the database. And so I created a database in phpmyadmin called "matomo", then created a config.ini.php file. Then when I go to localhost/matomo, i get an error saying that matomo is already installed and that "matomo.option" doesn't exist.
Why is the matomo installation have to be this difficult? Has someone successfully did it? If you'll down vote, at least please let me know why so i can provide more information.
Ok, so after researching further, it seems after clicking Next, Matomo is already doing a system check which takes too long to complete. So the solution is to increase the max_execution_time found in xampp/php/php.ini to 90.
This will give matomo enough time to complete its process. I hope others will find this useful.
I am experiencing a very strange behaviour of redgate that prevents me from commiting the changes I made to the database (I'm using git). I can click "Get Latest" and get no errors, everything works, but when I try to commit I get an error without any description (please see the screenshot).
I'm asking for help cause I have no idea what maybe wrong. Thanks in advance!
One other suggestion is to create a copy of the GIT config file, (call it GIT2.xml) and add the -verbose switch to see if it then creates some useful output. You'll need to unlink and re-link with the new config file for it to be picked up.
Please make sure that your system's PATH is pointing to the right Git.exe. You may want to check your path for C:\Program Files (x86)\Git\cmd and change that to C:\Program Files (x86)\Git\bin.
I still have no idea what was causing the problem. I ended up committing the changes using Tortoise GIT.
Anyway, no one has spotted that Redgate is performing a git checkout trying to switch a branch into a file?! And surpressing the error with -q. This looks like a bug in redgate.
Maybe the developers misunderstood git's checkout and treated it as subversion's checkout, but this commands are completely different and they should have known it.
Thanks for all the answers.
Here is the post that put some light on my issue:
http://www.red-gate.com/messageboard/viewtopic.php?t=15157
In UCM project we are trying to deliver activity to default stream.
It is displaying that activity is having dependency with another activity.
As the dependent activity has no useful info we obsoleted it. But still it doesn't allow us to proceed and it force us to deliver that ?
Why dependency is being triggered even if the activity is obsolete?
The activity will be associated with your deliver (without choice) if:
there is a common file with other activities (file dependency)
you previously did a deliver to another stream (in which case it automatically link all the remaining activities together)
If the activity is small enough, the best course of action remains to deliver everything, and to cancel what you don't need.
If there is really no common file, one option mentioned in this old 2003 thread would be to try and change the owner (only by a ClearCase admin) of the activity.
See cleartool project:
cleartool protect -chown aNewOwner activity:anActivity#\aPvob
(you might have to "cleartool unlock activity:anActivity#\aPvob" first if it was "lock -obsolete")
#Samselvaprabu I have seen this happen before, this smells of hyperlinks. Can not be 100% sure if your problem is exactly same, but they have worked for me in the past:
checkvob -ucm activity:#\PVOB
which might point you to a bad hyperlink
checkvob -fix
Use ucmutil to do a similar job
Please be careful, there are always risks associated with messing with hyperlinks, so read the manuals and/or technotes before you actually run a checkvob -fix or something intrusive.
Events till now
We have a CC 7.1.2.2, multisite setup where we do deliveries between 2 sites. Now when resuming a delivery at the destination site, we get this error :
Unable to read change set entry for activity "<activity name>". Unable to
convert diffs to elements. Unexpected error in deliver. Unable to perform merge.
Unable to do integration.
Then running checkvob -ucm shows some broken hyperliniks which the SCM support team fixes for us. IBM tech note says this is a synch issue.
Now the actual problem:
This has started happening on a regular basis suddenly and we know its NOT a synch issue between VOB and PVOB as the packets are getting synched properly. What I am interested in finding out is whether this could occur due to a specific set of user actions like deleting checked out versions etc. The key point is its not a one off thing and impacts our deliveries everyday. We are not able to find any concrete triggering actions or root cause
Any ideas ?
This has been linked to a multi-site sync issue from a long time now (here an example in 2005), and was also associated with a bug in CC multi-site 7.0.
But if you are really sure multi-site sync is not the issue, then it could be linked to "lost+found" issue, where elements could have been:
deleted (rmelem by an admin -- I know regular users in your setup don't have rmver or rmelem rights -- in order to clean the lost+found directory automatically, maybe through a ClearCase scheduled job or some kind of trigger?)
not selected because the config spec of views involved by your deliver are setup to not select the lost+found directory
Found out the issue; it was hidden synch issues indeed. What really was happening was that multisite synch was timing out for packets larger than 250 meg. This would create problems for bid inetersite deliveries where PVOB would synch over and VOBs would not. This was hidden as otherwise sync was happening properly.
Thanks VonC for the other inputs; I know you'd have pointed me to synch issues as a first measure had I not confirmed it wasn't the issue.
We have noticed that when after retracting a MOSS solution package, we are still left with incorrect leaf entries in the alldocs MOSS database table. This is an issue if for example we rename a feature that deploys the same artifacts - MOSS will then not let us deploy the solution as it thinks these items already exist.
Would be interested to hear if anyone else has had this problem.
Depending on the solution, SharePoint doesn't always clean everything up. However you must never touch the SharePoint database! Even querying it is not supported as this can cause locking issues that will make the application unreliable. Also see KB 841057.
There should always be a way to solve the problem via the SharePoint API. Once you've found it, add the clean up code to a feature receiver so that it executes when the feature is deactivated. If you need help, please ask in a new question with the code/schema you are using.
Depending on the error you are receiving, the tools on these pages may also help:
WssRemoveFeatureFromSite
Dealing with abducted SharePoint features
I Agree with Alex, this shouldn't concern you and the fact that you've noticed this means that you have more than a a healthy interest in the sharepoint DB.
Practical explanations maybe that you created assets (e.g. listitems) that have references to the solution (content types, site columns etc) and so these are orphaned when the solution is removed, of course when you re install the solution these assets will work correctly so its not all bad.