I am trying to copy some files out of ClearCase using PowerShell. I don't need to actually check them out - it's part of a build process, so I just want to be able to grab copies of them.
My guess is that I need to use cleartool, perhaps with "find", but I'm having trouble actually getting to the files that I want. No matter what "paths" I use I always get an error message. For example:
cleartool find My_VOB\A_Folder\A_Subfolder -print
gives me the error message, "No such file or directory."
I'm trying to make this script reusable by everyone in our development group, so I'd prefer not to have it tied to any specific view. Do I need to create a view on the fly to work with ClearCase?
If you want to copy files, you need a view to access them.
(That is what a ClearCase view, either dynamic or snapshot, is for: accessing specific versions of files)
Either that view exists (and its root path is passed as a parameter) or it don't (in which case I strongly recommend a dynamic view for those kind if reading access)
Even though a cleartool find can list versions not visible in the current view, it still needs a view as a starting point.
A lot of other find examples are available in this IBM article "Additional examples of the cleartool find command".
This thread lists some causes for the "no such file or directory" error message.
(like being in a private directory, as in "non-versionned directory")
This case shows an example of Powershell script using CAL (the ClearCase Automation Library)
You definitely need a view, and make sure the VOB is mounted.
Related
I am aware that I am asking for an implementation detail but I want to hack something for my use case and hence the question.
My use case: I use an on-demand instance where source code is hosted at work. This means I get a new machine (let's say every day) where I open the same source folder (but hosted on that remote machine). Because of this, the context of opened files in editor gets lost between sessions.
I am curious where does VSCode save the information about open files in a workspace. If I know that, I am hoping I can copy that file at the end of day before I give up an on-demand instance AND when I get the next instance (which may have a different remote url but same file paths), I can somehow hack this file to open all the editors from previous session in the new on-demand. Does my question make sense? Let me know if something is not clear.
On Windows the workspace state is stored here:
%APPDATA%\Code\User\workspaceStorage
And on Linux:
~/.config/Code/User/workspaceStorage
Every workspace has a subfolder here with a hashed name. To find out which one belongs to your workspace, open the contained workspace.json, which looks like this:
{
"folder": "file:///c%3A/some/path"
}
Choose the one that matches your workspace folder and copy the complete folder.
However, I am not sure how VS Code calculates the hashes for the folder names, so maybe it won't use the same hash again in your new instance. But this definitely is the place where the information is stored, so it's worth a try.
Tried searching for this a number of ways and have not yet found an answer ...
Background
I am working on a legacy Perl application that has a lot of hard-coded values in it which should be configurable depending on where the app is installed. So, obviously, I am looking to externalize these values into a configuration file that may be located in one of a few "expected" locations. That is, using a traditional approach of checking for the configuration file in:
the current working directory,
the user's home directory (or a sub-folder therein), and
the system configuration directory (or a sub-folder therein)
where the first one found wins.
Where I am at
Perused the CPAN site a bit and found the Config::Any package, which looks promising. I can give it a list of files to use:
use Config::Any;
my $config = Config::Any->load_files(
{
files => [qw(sample.conf /home/william/.config/sample.conf /etc/sample.conf)],
use_ext => 0,
});
This will check for the existence of each of these files, and, if found, load the contents into an array reference of hash references. Not bad, but I still have to hard-code the locations where I search for my sample.conf file. Here, I assume that I am working on a Linux system, and that the location for the configuration file for all users of the application is /etc/. I could always add /usr/local/etc/ as well, but regardless, this is not system agnostic.
I can locate the user home folder using File::HomeDir for searching there, and it works correctly regardless of the system on which the application is running. So is there a similar package that would provide the /etc/ folder (or its equivalent on other platforms)?
Questions
Is there a way to do this without having to know what particular OS I am on? (Perl package or code snippet)
What is the "Perl best practice" way of accomplishing this? I cannot imagine that no one else has run into this previously.
Unless you don't plan to run your code on non unix-based hosts, according to the conventional directory layout and filesystem hierarchy standard, you may rely on a quite large set of well known places.
Anyway, nothing prevents you to dynamically build the file search specification to take account of platform oddities and their specific ways to get them (eg. File::HomeDir::Win32 vs File::HomeDir).
How do I use cleartool find to search a bare vob? Must I always first define a view?
I typically use CCRC and in this case I am looking for a list of all files of a certain branch type.
EDIT:
This page says:
Typically, you start with all objects in a directory tree as seen in
your view. You can also start with all objects in one or more VOBs,
regardless of they are visible in a particular view.
I'm looking for information on the version of the command that the second sentence describes.
You cannot use cleartool in a CCRC setting.
CCRC (ClearCase Remote Client) is a light-weight ClearCase installation which communicates with a CCRC server (which, in turn, talk to a full ClearCase Vob server).
You can use rcleartool, the CCRC CLI, but it doesn't include a find comnand.
'cleartool find' itself is always used in a view, because it needs a path (to at least a Vob).
You can also start with all objects in one or more VOBs, regardless of they are visible in a particular view.
That doesn't mean you can use cleartool find outside a view.
The two pages giving a lot of examples are:
SAMECS find examples
IBM additional find examples
The SAMECS link and the cleartool man page are clear:
-avobs
By default, find starts with all the elements, branches, and versions in all the VOBs mounted on the local host.
In a snapshot view, find –avobs issues a warning if all mounted VOBs have not been loaded into the view.
This option depends on the MVFS and is ignored on hosts that do not support dynamic views.
You must be in a view context to use find –avobs.
If the CLEARCASE_AVOBS EV is set to a colon-separated list of VOB tags (in UNIX; in Windows, list items must be separated by semicolons), this set of VOBs is used instead.
In short, to access any vob content, they must be loaded (snapshot view) or mounted (dynamic view). In both cases, even though the find is not restricted by the view confi spec (especially in the case of the -avobs option), a view is still needed to run cleartool find.
Sometimes when we issue an upgrade to our application we need to install some files to the application's Data folder. We want to make it possible for the users to move this folder to a place of their liking. But how to deal with this at install time?
I was thinking of deploying to the user's AppData folder and have the application somehow check there for new files at startup.
Any advice or references would be very welcome!
We use InnoSetup for a VB6 application if that matters for your answer.
Generally the best solution I've found is to allow the user to move the folder from within the application.
This allows the application to keep track of where its data is being kept (by adding a reference to it in a file or registry entry which it accesses at load time) and to access it seamlessly in the future.
Your update routines can then also access this information to determine where to place the update files.
Alternatively, make sure the folder name is as distinctive as possible and add a search routine to look for the directory in a number of sensible places at load time. Then write your manual specifying that the data folder can be moved to one of those locations ONLY.
Wouldn't the users just run an update or patch package? I'm not sure why they'd want or need to see such files. It's pretty rare for commercial software to offer users the options of where to store program settings and other internal-use files.
Give some thought to this before putting a lot of stuff into users' roaming profiles. You might want LocalAppData instead.
Is it possible to create StarTeam shortcut, opening project and overriding working directory?
Is it possible to create one StarTeam shortcut, opening several projects at a time?
Problem is: I have several solutions, which use the same StarTeam project, and I have to manually change working folder very often (View -> Properties -> Working folder). It is not possible to share data between solutions: local view should be located in separate place for each solution.
You could create different views for each project. Different views can have different working folders; in fact, they do by default. Keep in mind, a view can be set to behave pretty much the same as the default view, with regards to which revisions of files you see. But they can have their own working folders. The downside of this technique is that Change Requests and the like will also be "in the view," so moving them will not necessarily affect other views. But given that you are working on an entirely separate projects, that might not be all such a bad thing. As usual, you should experiment with this in a test project, and make sure you're happy with the behavior, before using it on your "life" repository.
The override/alternate directory for each project and folder is maintained inside a local file - not on the server. The default working folder is kept on the server, and any time you update it the changes are propigating to all other users.
The shortcut xml has no place to specify a working folder.
If you don't need the StarTeam GUI, stcmd allows you to specify a new working folder for most operations with the -rp and -fp flags.
If the projects that need this common library code are in their own views, you could also share the common project into a new subfolder within those other projects. You can use a relative path for this new subfolder that includes .. to move it outside the containing project's folder. This lets you use common code in many projects while allowing you to specify the location of that common code per project.
Shares come with some overhead, so be aware, but other than that it would probably work for what you're trying to do.