I have a whole big bunch of new files I've recently dropped (via robocopy) into a folder tree. How can I ask ClearCase UCM to identify those files and get them placed under version control?
One easy way is to use clearfsimport in order to do a (recursive) import of a full directory content.
See "How can I use ClearCase to “add to source control …” recursively?".
It does work for ClearCase UCM view as well as base ClearCase view.
You only have to set an activity on the view you are using for the import before executing the clearfsimport.
That is easier than copying those file directly in the ClearCase destination view, and trying to detect those private (i.e. "not yet versionned") files.
Ah, turned out someone had already made such a post on an internal blog. Who knew!
I took that and then expanded it
for /f %1 in ('cleartool ls -r -s -nxname -view_only ^| grep -e ^\.\\SRC_ ^| grep -e vcproj$') do #cleardlg -addtosrc -nc "%1"
(Yeah, I've got some unix tools installed, grep and the like).
Looks for all vcproj files in a directory that starts with .\SRC_.
Related
I am working on a script that will update a bunch of files in a given ClearCase folder. Before to start, I want to check in the script if any checkout that will be performed during the process may fail (because of another checkout). The script does not know the config spec in use.
The basic idea based on cleartool lsco -rec cannot work because of the many false-positive result (mostly, checkout done on a not selected branch, or unreserved checkout).
So the question is: How can I list all file that I cannot checkout because of another checkout that will conflict with mine?
Thanks in advance for your help!
"The basic idea based on cleartool lsco -rec cannot work"
Yet it should work.
You can compare cleartool lsco -brtype abranch -me and cleartool lsco -brtype abranch in order to see other checkouts done on the target branch, not by you.
You can |grep -v unreserved to trim out any unreserved checkout.
The end result is the list of files, checkout not by you, reserved.
You can then compare that list with the files your script has to modify.
If you're using a classic-UCM environment, this would generally not happen if you're not working in a shared stream. So, I'm going to assume you are working in base clearcase.
One way to check this would be to look at the version trees of the files you plan on checking out. However, to automate it, you would need to also know what branch you're working on.
For a single file:
Windows:
cleartool lsvtree {my file} | findstr CHECKEDOUT
Unix
cleartool lsvtree {my file} | grep CHECKEDOUT
Any CHECKEDOUT returns on your branch (which may be /main if you're not doing parallel development) would block you.
If you have a list of files, it would depend on how you want to process that list.
I have a situation where I'd like to diff two branches in Perforce. Normally I'd use diff2 to do a server-side diff but in this case the files on the branches are so large that the diff2 call ends up filling up /tmp on my server trying to diff them and the diff fails.
I can't bring down my server to rectify this so I'm looking at checking out the the content to disk and using diff on the command line to inspect and compare the content.
The trouble is: most of the files have RCS keywords in them that are being expanded.
I know can remove keyword expansion from a file by opening the files for edit and removing the -k attribute from the files in the process, but that seems a bit brute force. I was hoping I could just tell the p4 sync command not to expand the keywords on checkout. I can't seem to find a way to do this? Is it possible?
As a possible alternative solution, does anyone know if you can tell p4 diff2 which directory to use for temporary space when you call it? If I could tell it to use abundant NAS space instead of /tmp on the Perforce server I might be able to make it work.
I'm using 2010.x version of Perforce if that changes the answer in any way.
There's no way I know of to disable keyword expansion on sync. Here's what I would try:
1) Create a branch spec between the two sets of files
2) Run "p4 files //path/to/files/... | cut -d '#' -f 1 > tmp"
Path to files above should be the right hand side of the branch spec you created
3) p4 -x tmp diff2 -b
This tells p4 to iterate over the lines of text in 'tmp' and treat them as arguments to the command. I think /tmp on your server will get cleared in-between each file this way, preventing it from filling up.
I unfortunately don't have files large enough to test that it works, so this is entirely theoretical.
To change the temp directory that p4d uses just TEMP or TMP to a different path and restart p4d. If you're on Windows make sure to call 'p4 set -S perforce TMP=' to set variable for the Perforce service; without the -S perforce you'll just set it for the current user.
I have checked out vlt repo using:
vlt co http://localhost:4502/crx/-/jcr:root path/to/repo --force
But now, my CQ instance changed location (port). Is there a way to set new URL(port) to vlt?
(without checking out again)
I have tried unzipping path/to/repo/.vlt and changing repository.url file sometimes it works, but in most cases it breaks local repo, or I'm unable to unzip.
I understand you're looking for something like the "svn relocate" command. This is not possible with the VLT tool directly.
Options (any one of these should do it):
I recommend checking out a new copy of the repository and reapplying the changes that show from running "vlt status" over there.
Set up a new CQ server on the old port, then use "vlt rcp". The process would probably be: copy the whole repository from old to new server, push your local stuff to the new server, copy part of the tree from new to old.
The repository.url setting is nested in .vlt files under all subdirectories of the repository. You could try a global/recursive search & replace for all of these. I've never tried this though. For example, something like this: (I get permission denied running this, needs more work.)
find -name .vlt -type f -print0 | xargs -0 sed -i 's/localhost:4502/localhost:4503/g'
Remove all the .vlt files and use the vlt import/export commands to load. See the "Using import/export instead of .vlt control" section of this document: http://wem.help.adobe.com/enterprise/en_US/10-0/core/how_to/how_to_use_the_vlttool.html
Okay this is and isn't programming related I guess...
I've got a whole bunch of little useful console utilities scattered across a suite of projects that I wrote and I want to dump them all to a single directory to make using them simpler. The only issue is that I have them all compiled in both Debug and Release mode.
Given that I only want the release mode versions in my utilities directory, what switch would allow me to specify that I want all executables from my tree structure but only from within Release folders:
Example:
Projects\
Project1\
Bin\
Debug\
Project1.exe
Release\
Project1.exe
Project2\
etc etc...
To
Utilities\
Project1.exe
Project2.exe
Project3.exe
Project4.exe
...
etc etc...
I figured this would be a cinch with XCopy - but it doesn't seem to allow me to exclude the Debug directories - or rather - only include items in my Release directories.
Any ideas?
You can restrict it to only release executables with the following. However, I do not believe the other requirement of flattening is possible using xcopy alone. To do the restriction:
First create a file such as exclude.txt and put this inside:
\Debug\
Then use the following command:
xcopy /e /EXCLUDE:exclude.txt *.exe C:\target
You can, however, accomplish what you want using xxcopy (free for non-commercial use). Read technical bulletin #16 for an explanation of the flattening features.
If the claim in that technical bulletin is correct, then it confirms that flattening cannot be accomplished with xcopy alone.
The following command will do exactly what you want using xxcopy:
xxcopy /sgfo /X:*\Debug\* .\Projects\*.exe .\Utilities
I recommend reading the technical bulletin, however, as it gives more sophisticated options for the flattening. I chose one of the most basic above.
Sorry, I haven't tried it yet, but shouldn't you be using:
xcopy release*.exe d:\destination /s
I am currently on my Mac so, I cant really check to be for sure.
This might not help you with assembling them all in one place now, but going forward have you considered adding a post-build event to the projects in Visual Studio (I'm assuming you are using it based on the directory names)
xcopy /Y /I /E "$(TargetDir)\$(TargetFileName)" "c:\somedirectory\$(TargetFileName)"
Ok, this is probably not going to work for you since you seem to be on a windows machine.
Here goes anyway, for the logic.
# From the base directory
mkdir Utilities
find . -type f | grep -w Release > utils.txt
for f in $(<utils.txt); do cp $f Utilities/; done
You can combine the find and cp lines into one, I split them for readability.
To do this on a windows machine you'll need Cygwin or some such Unix Utilities handy.
Maybe there are tools in the Windows shell to do this...
This may help get you started:
C:\>for %i in (*) do dir "%~dpi\*.exe"
Used in the dir command as a modifier to i, ~dp uses the drive and path of everything found in (*). If I run the above in a folder that has several subfolders containing executables, I get a dir list of all of the executables in each folder.
You should be able to modify that to add '\bin\release\' following the ~dpi portion and change dir to xcopy. A little experimentation should make it pretty easy.
To use the for statement above in a batch file, change '%' to '%%' in both places.
If I have added/removed/modified a large number of files in my local ClearCase view, how can I be certain that all the files have been added to source control?
Your answer is correct, for snapshot views (which you call 'local view' ?)
In a dynamic view, a simple
cleartool lsprivate
would suffice.
But that would leave out hijacked files (which are already added to source control, but may have been modified without ClearCase knowing it)
So I would recommend to complete your command with (for Windows):
for /F "usebackq delims= " %i in (`cleartool ls -r -nxn ^| find "hijacked"`) do #echo %i
For Unix:
cleartool ls -r -nxn | grep hijacked
That would also leave files in checkouts (granted, they also are added to source control, but should be also listed as they must be eventually committed or cancelled).
In Snapshot views:
cleartool lscheckout -recur
In Dynamic views:
cleartool lsprivate –co
I use a similar dos command for windows, but I also pipe the results of the clear tool command to findstr to 'ignore' specific patterns (using regex) such as .keep files, dll's, and compiled files and folder locations that I don't want to add to source.
Run the following command from the root folder of your view. If you have multiple top level folders then you'll need to run it once for each folder. Also, I believe this only works for SnapShot views.
cleartool ls -recurse -view_only | findstr /vi ".dll$ .pdb$ .suo$ .keep$ .unloaded$ \\bin$ \\bin\\ \\debug$ \\debug\\ \\release$ \\release\\ \\obj$ \\obj\\ ^cleartool$" > c:\ItemsNotInSource.txt
Use cleartool ls -view_only -r from the your local view VOB directory.
To add any files recursively to source control that are only in the local view, see How can I use ClearCase to “add to source control …” recursively?.