We're trying to move a bunch of folders from one location to another in our vob. The process is that:
we check out the target parent folder
check out the source parent parent folder
ct mv source target
This unfortunately fails with moving only the top folder in the tree... On the other hand ct relocate works fine and we avoid checking out thousands of vob elements. Are there any drawbacks with that command? We assume that the source and the target are in the same vob.
We assume that the source and the target are in the same vob.
Then cleartool mv is enough: see "To move an element within a VOB"
It won't move just the top element.
As mentioned in "Relocating elements to another VOB":
The relocate command does not do any of the following:
Relocate elements when either the source or the target VOB is a UCM component VOB or PVOB.
Move view-private files and nonversioned DOs stored in relocated directories.
Move elements to a new location in the same VOB. (Use cleartool mv for this purpose.)
Related
I'm using the ClearCase as version control tool.
When I am creating view in a particular VOB, all the folders has been downloaded from the server. But files are not getting downloaded.
For that I am doing as a workaround a 'checkout' of the current vob and then UNDO checkout the same. Then only I am getting files.
Is there any fix for this?
all the folders has been downloaded from the server.
"Downloaded" means probably this is a ClearCase snapshot view, which reads the config spec:
"selection rules"
"loading rules"
and download the elements (files and directories) whose version matches the selection rules, and whose path matches the loading rules.
You need to do a cleartool ls in a folder where you see only subfolders in order to understand what selection rules was used to download those folders (and not the files)
cd /path/to/my/view/(vobs/)myVob
cleartool ls
From there, you can edit the config spec (cleartool edcs) in order to fix the selection or loading rules, ensuring that folders and files are downloaded when you update the snapshot view.
Maybe those folders are considered as hijacked: see "Locating hijacked files in snapshot views".
If there is a .cc_loading directory it looks like a wev view. Cleartool claims that it doesn't work in those views (if if the command has nothing to do with a view context!).
You should you "rcleartool ls", but you can also see what version of the directory is used with the help of CTE.
I guess that you see version /main/0 of the directories.
As this is a snapshot view, create a dynamic view with the same configspec and see what it sees. If you see directories and not files in the dynamic view, what is the configspec? And what does cleartool ls show you?
I have a certain folder(named SDK) containing many other folders as a VOB element in my dynamic view.
/vobs/tools/SDK
I also have a updated version of that folder elsewhere as view private (as flat files).
/homes/user/SDK
I need to add files which were introduced in the updated version to the checked in version which did not have them. I have a text file containing all the files which were newly introduced in the updated version.
/homes/user/files.txt
Contents of files.txt
./a/b/abc.cpp
./s/t/xyz.cpp
.
.
.
Which is the best way to have these files checked in at at appropriate location?
clearfsimport will not work because it takes the leaf of the source path and checks that at the target VOB location.
i.e.
clearfsimport -nset /homes/user/SDK/a/b/abc.cpp /vobs/tools/SDK
clearfsimport -nset /homes/user/SDK/s/t/xyz.cpp /vobs/tools/SDK
wouldn't create the /a/b/ and /s/t/ directories in /vobs/tools/.
I could use mkelem but that would require me to manually create the directory /a/ then /a/b/ and then copy the file abc.cpp and checkin back the newly created directories and the file itself.
Can someone suggest the most efficient way of doing it?
Yet clearfsimport should work (to import multiple files):
clearfsimport -preview -rec -nset /homes/user/SDK /vobs/tools/SDK
# or
clearfsimport -preview -rec -nset /homes/user/SDK/\* /vobs/tools/SDK
That should import all elements, but checkout and update only the ones modified, and create the one missing.
All that in /vobs/tools/SDK, not /vobs/tools.
Since there are too many files in /vobs/tools/SDK, copy the ones which have been modified in /vobs/tools/SDK_to_import, with their exact folder structure (like /homes/user/SDK_to_import/a/b/abc.cpp).
The clearfsimport, by default, will not remove the files of the destination folder which are not present in the source folder.
But it will update those files in the destination folder /vobs/tools/SDK.
If another developer adds a new directory to the CVS repository, I'd like my next update to bring this new directory into my working copy. Running cvs update doesn't do this. Running cvs update -d does, but it takes a helluva long time; it prints the pathname of every file in the repository and spends a little time thinking about each one. Running cvs update -d <dirname> in the new directory's parent does the job, but I have to know about the new directory first, and I have to do this for every new directory.
Is there an efficient way to get a complete update, including any newly-added directories, from a CVS server?
Use a shell script which generates a custom $CVSIGNORE list for this type of update, then runs cvsupdate -d to do this:
CVS has a list of files (or sh(1) file name patterns) that it should ignore while running update, import and release. This list is constructed in the following way.
The list is initialized to include certain file name patterns: names associated with CVS administration, or with other common source control systems; common names for patch files, object files, archive files, and editor backup files; and other names that are usually artifacts of assorted utilities. Currently, the default list of ignored file name patterns is:
RCS SCCS CVS CVS.adm
RCSLOG cvslog.*
tags TAGS
.make.state .nse_depinfo
*~ #* .#* ,* _$* *$
*.old *.bak *.BAK *.orig *.rej .del-*
*.a *.olb *.o *.obj *.so *.exe
*.Z *.elc *.ln
core
The per-repository list in ‘$CVSROOT/CVSROOT/cvsignore’ is appended to the list, if that file exists.
The per-user list in ‘.cvsignore’ in your home directory is appended to the list, if it exists.
Any entries in the environment variable $CVSIGNORE is appended to the list.
Any ‘-I’ options given to CVS is appended.
As CVS traverses through your directories, the contents of any ‘.cvsignore’ will be appended to the list. The patterns found in ‘.cvsignore’ are only valid for the directory that contains them, not for any sub-directories.
In any of the 5 places listed above, a single exclamation mark (‘!’) clears the ignore list. This can be used if you want to store any file which normally is ignored by CVS.
References
Ignoring files via cvsignore
I have a directory structure like:
project_root
data/
src/
.hg/
utils/
math/
graphics/
...
README.txt
LICENCE.txt
As you can see from the location of .hg/, only src/ is under Hg control. I'd like to move the repository root up from src/ to its parent directory project_root, so I can track data/, README.txt, and LICENCE.txt as well.
A hacky way to do this would be to move everything down a directory rather than moving .hg up:
Move the contents of src down to a new directory src/src/
Move the contents of project_root (other than src/) down to src/
Rename src to new_project_root
Move new_project_root out of project_root, delete project_root
Is there a better way? I can't be the first person with this problem, and the above solution seems overly involved.
You should try hg convert. You will be "converting" your existing Mercurial repo into a new one. You specify rules for the conversion, which in your case will be that all files from the original repo go to a src directory in the new repo. Then you can manually copy and hg add the other files to the new repo.
This has the advantage that it won't be reflected as separate changes in your history. The possible disadvantage is that it will cause your changeset IDs to be regenerated, and existing clones will no longer be able to pull from the new repo.
Your plan is fine. It may seem involved, but it should take less than 20 minutes (worst case) and only happens once.
In the first step when you move the files that are tracked, you should use hg rename (alias hg move) to move them, as Mercurial will remember what each file was before and after the move. This will help with merging changes on file prior to the move with the new files after the move. Works best when renaming/copying is not accompanied by changes to the contents in the same changeset.
I recommend cloning the actual repo (or copying the entire project directory) before proceeding.
hg's Detect Renames works a treat nowadays.
Clone the repo so that you can mess things up without worry.
Using your example:
create the src/src subdir
move utils, math, graphics etc into src/src
Then open the commit window.
the moved files will appear in their old directory with a ! and in their new directory with a ?
right click on any file and choose "Detect Renames..."
slide the Min Similarity slider to 100%
Click the Accept All Matches button, and close the Detect Copies/Renames window
the moved files should now appear with an R in the old directory and an A in their new directory
commit this change
Then I moved data, Readme.txt etc down into src (not src/src)
committed the adds.
Finally, now that I have the repo as I want it, push the changes back to the originally cloned repo. Don't forget you'll need to Update the original repo to see the changes in the working directory.
I have a file that needs to be brought into a different branch. How do I do this from the command line. Everything seems to be geared to merging, where the file already exists in both branches.
You have to merge the parent directory first, so that the file shows up in the directory in the destination branch. At this point the new file will have zero size. You can then merge the file itself. The easiest way to do both of these operations is via the Version Tree view - much less error-prone than doing it via the command line.
Much simpler:
1/ rmname the file in the destination directory
ct co -nc .
ct rmname -force file.txt
2/ merge the directory
ct findmerge . -ftag view_tag
with 'view_tag' a view on the source directory
I no longer have access to a clearcase environment, so this is from memory, but what you want is to link in a version from another branch into the one that you are working with.
Let's assume that you have a file new_file that have been added on the branch new_feature (the latest version is new_file##/main/new_feature/5) which you want to merge/bring into the branch maintenance.
prompt>cleartool checkout -nc .
checking out some_dir##/main/maintenance/2
...
prompt>cleartool ln .##/main/new_feature/LATEST/new_file/main/new_feature/5 .
...
prompt>cleartool ci -c "linked in .##/main/new_feature/LATEST/new_file/main/new_feature/5"
prompt>
The commands above are probably not 100% correct, but should give you the idea. You want to use cleartool ln to avoid evil twins, because that will bring in a version from the already existing element (i.e. not creating a new twin).