When I delete a file from my snapshot view, the next time I look at the snapshot in ClearCase Explorer, it shows the "??" checked-out-but-removed icon. When I run "Find Modified Files" on the snapshot, the deleted files aren't shown. Running "Update View" on the snapshot causes ClearCase to re-copy the missing files back into my view.
What I want to happen is this: when I delete a file from my snapshot, and do an update, the file should be deleted from the view, just as if I had deleted it through ClearCase from a dynamic view. What's the best way to accomplish this?
I would prefer to avoid a lot of customization of my ClearCase environment. If there's a "standard" way to do this, I'd like to try that. If cleartool can show me search results for all files that fit this bill, that will be good enough for my purposes.
If you delete the file from the ClearCase Explorer, you shouldn't have any issue: it will
checkout the parent directory
rmname the file
checkin the parent directory
But if you do it directly from a shell or a Windows Explorer, then ClearCase won't be informed of the operation, hence the "??" checked-out-but-removed status.
With a dynamic view, you cannot remove a file without ClearCase knowing about it, since a dynamic view is an encapsulation of the file system managed entirely by ClearCase.
Now let's suppose you have deleted a bunch of check-out files directly from the native filesystem (not from the ClearCase Explorer or an IDE with a ClearCase plugin), and that you want those files to stay deleted!
Then a way to reconcile the two status would be to:
cleartool update . (at the root directory of the snapshot view)
parse the generated ".updt" file and for each checked-out file, rmname it (like in this article)
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 deleted a file from my Eclipse work space but that file is in SVN repository. Could any one help me to get my deleted file from SVN without using the command line?
There's a simpliest way to recover the file with Eclipse+SVN only.
Go to SVN Repositories view, find a folder your file was located, make a right click and choose Show History. You will see the list of commits to THIS FOLDER in the History view. Please make sure it's switched to Remote Revisions. From the list of commits find a commit that deleted the file. In the pane below there's a list of files involved with this commit - you can find deleted files with minus sign. Double click will open this file in editor...
If you've deleted the file in Eclipse, Eclipse has told Subversion to mark the file for deletion. This means the next commit will delete the file. You'll have to do a revert.
If you've deleted this file via Internet Explorer or some other file browser, and didn't tell Subversion, then the file isn't marked for deletion. Simply updating the file will bring it back.
This is where the command line client sings. With the command line client, I could tell Subversion to update or revert a nonexistent file. With a GUI, I would first have to select the file, then tell Subversion what to do. But without a file, I can't do anything.
Easiest solution: Recreate the file. The contents are not important. It can be empty or contain a dirty limerick for all you care. You're basically making a file you can select with your file browser.
Then, you can select the file and tell Subversion and/or Eclipse via the Team menu to revert it. This way, it doesn't matter how the file was deleted. Subversion will restore the file back to its original checked out version.
Along the lines of Bryn's solution, using Subclipse, find the delete 'D' entry for the file in SVN history, right-click and do "Copy..." which will then ask you to specifiy a location in your Eclipse workspace. Click OK, it will probably take a little while, and that's it.
I first tried "Export...", but that didn't work for me, seems like subclipse is looking in HEAD, even though an older revision was selected.
Decided to take the jump from CVS to SVN.
I setup a new repository in subclipse for my project. When I go to 'Finish' the setup it wants to do an initial commit and presents me with a flat list of files to select the files for version controlling.
The problem is I have thousands of generated binary files I dont want to commit.
So I click on cancel because it would take me all day to go through and unselect all the unwanted files. Annoyingly when I click on a parent category for the files I want to ignore it is not recursive!
So I click cancel then go to the eclipse directory structure for the project and manually set svn:ignore on all directories I want to ignore. Then I try and do a commit again and all the files are once again presented - ignore seems to have done nothing.
Can anybody point out what I might be doing wrong?
For the first commit, I recommend writing a small script to delete (of course you'll have a backup) all the files that are not meant to be committed.
Afterwards, if you find you accidentally committed a file, you can
svn delete file
Upon the first checkout, copy back (or better yet, regenerate) all the binary files. This will trigger svn to notice that your local repository is out-of-sync with the remote repository.
cd <Root of local repository>
svn status
You will see lots of "to be added" items. Go to the parent directory and add in svn:ignore properties for each of the generated items.
cd build
svn propedit svn:ignore .
which will open an editor (if it doesn't, you need to set the environmental variable SVN_EDITOR to a suitable editor). Then you can add in entries that svn will know are not tracked.
(in the ignore property editor)
target
build
image*
*.o
(and so on)
Save the file, and it will be staged for the next commit. Subsequent runs of svn status will no longer show these files as "needing to be added", but they will show the directory as "needing to be committed (it's a revision on the directory)"
Quick Aside
So I'm not entirely certain exactly which functionality of Subclipse you were using in order to create a repo and share a project to it, I'm assuming you created like a file based repo through the eclipse SVN repo view and tried to share and then commit to it. It looks like your problem got solved but I did want to add an answer on here because I ran across this post looking for the answer to this same problem of handling initial commits even just in general with SVN and wanted to offer help to anyone else looking for the help.
Intro
To start off I would recommend not working through an IDE extension like this just for the initial commit as they can miss a lot of the options for handling opening a repo in SVN. I personally really like the command line form of SVN to work with but TortoiseSVN is a good option for a GUI.
Whether you create a local file-based repo or are connecting to an SVN server and you want better control over your first commit in an previously unversioned project here is what I've found as the best general workflow for doing so.
Create the remote folder to save to.
On command line this will be:
$> svn mkdir your-url-scheme://your-site-address.domain/path/to/repo/example-directory
Or on TortoiseSVN open your repo for browsing, right click, and select "create new folder"
This will give you a location in the SVN repo to checkout from for our next step.
Checkout in to the already started project
Make sure to use the empty, newly created folder in your repo to checkout with. SVN does not actually require a folder being checked out to to be empty, which is an important part of what makes it actually very flexible and able to subsume parts of your directory into it fairly easily if used correctly.
Now you will checkout this empty folder into the root folder of your already started project. This will add your project to the working copy of this folder without any commit being made yet. The command is:
$> svn co your-url-scheme://your-site-address.domain/path/to/repo/example-directory /your/projects/root/
"co" standing for checkout. In Tortoise svn you can right click on or in the empty repo folder and select "checkout..." and then select the project root.
Set ignores and commit
Finally, you can easily set your ignores on certain files before adding any other files to the tree using the command:
$> svn propset svn:ignore file-or-directory-to-ignore
And to add all non-ignored directories and files:
$> svn add * --force
The force is technically unnecessary in this case but ensures full recursion. You can also now do all of this in your file explorer if using TortoiseSVN or you can even use your IDE extensions to do this at this point(make sure to ignore all files you need to before mass-adding files for commit), all that's left is to make sure to commit the newly added files to the repo and you're up and running with source control :)
Added this method here simply because this method allows you to avoid any unnecessary copying of those stinky binaries that no one wants to lug around with them.
Is it possible to exclude/ignore some specific files from synchronization with SVN that are present in svn ??
These files are already present in SVN, and I believe from other posts that the rightClick->Team->SVN:IGnore only works for files that are not there in svn.
I have read other posts but can not find the answer.
Reason : we have some files that have some specific content in SVN while some other content in local workspace, People by mistake are checking in theirversion of these config files to SVN.
Perhaps there is an easier way to do it, but following should work:
Optional: save your file somewhere, in case you can't recreate it
Open 'SVN Repositories' view, navigate to location of file you don't want to be in SVN, right click on it and choose 'Delete'. This would remove file from repository
Synchronize. You would see file removal as incoming change. Accept it. This would remove file from your local file system
Recreate file in your local file system, or copy from step (1). File would show as outgoing change if you synchronize at this point.
Now you should be able to do 'Right click->Team->Add to SVN Ignore' on it. Do this and commit property change on the folder.
TortoiseSVN has a option in the Windows-context-menu by right-clicking on the file to unversioncontrol and add to ignore list. The action should also be recogniced by the plugin, even if the plugin menu has not this option.
If you do not want to use Tortoise for this, a simple workaround would be:
remove the files from the folder(store them temporaly else where)
commit, the removed files.
if you are not on the commiting computer update now
paste back in the removed files and add them to the ignore list.
I'm looking for a way to convince Eclipse that a directory has indeed been removed from the CVS repository, permanently?
With regular command line CVS I would just edit CVS/Entries in the directory's former parent. With Eclipse, I've tried removing the directory from the Project Explorer view, removing the appropriate line in CVS/Entries, recreating the directory in PE so that it might be removed on update or synchronization, synchronize without recreating the directory, and probably other things that I've since forgotten, and nothing worked.
The directory has been entirely removed from the CVS repository, so I'm not talking about just pruning empty directories here. The error I am seeing is:
The server reported an error while performing the "cvs update" command.
Project: cvs update: cannot open directory /usr/local/cvsroot/one/two/three/removed_directory: No such file or directory
My project contains all of the contents from /usr/local/cvsroot/one/two. I do not get this error when I navigate to "three" and update from there. I only get it when I update from the project root.
One (quite imperfect) solution for this problem is, beside to check-out the project again, to remove CVS information stored by Eclipse.
Go in the right-menu under the project > Team > Disconnect, and check the radiobutton "Also delete the CVS meta information from the file system". Now your project is unshared and has no more CVS information into it. Then you just have to do Team > Share project, select the previous repository location, and you're done (CVS will detect by itself that the project is up-to-date and won't update nor commit anything, of course).
A folder that has been deleted in the cvs repository by hand won't then be proposed anymore by CVS under Eclipse to be commited.
Beware that on a big project with many files, depending on the speed of your network, the re-share may take some time.
Sometimes it may indeed be easier to delete the project and pull it off again from CVS.
I fought this same thing for several hours a couple of separate times. I just gave in and re-checked out the project. That seemed to work like a charm
Handling of directories in CVS is not perfect. This and many other reasons caused in creating more complete SCM tool subversion.
CVS can create directory, but can not remove it. From CVS point of view, to remove directory you need to remove (cvs rm) all files in directory. But directory is still present in CVS and there's no way to remove it. Hovewer, CVS propose a "hack" to hide such "deleted"/empty directories by executing "cvs up -P" (see here).
So, for CVS command line, I wouldn't mess with parent directory CVS/Entries file, but rather use "cvs up -P" described above.
The directory will be listed in the CVS/Entries file under the parent directory. Remove the entry in the Entres file and the directory. Eclipse should recognize the directory has been removed.
Refactoring directories in CVS is problematic. Due to the way CVS handles history one of the following usually applies:
The history of files moved to new locations appears to disappear. (It is located in the history of the old location.)
The history of files is retained, but files appear moved when checking out versions prior to the move. (Files were moved in the repository, rather than in a sandbox.)
Removing or moving directories in the repository generally creates problems for clients. It helps to retain directories and only move or remove files. Normal processing moves deleted files to an Attic sub-directory.
In the Eclipse CVS synchronization perspective, did you try the 'Override and update' option?
If the files/folders are already deleted on the repository, from the Eclipse project perspective, "replace with"->"latest from HEAD" on the folder containing deleted elements