I am working on a project using Eclipse 4.19.0. I also have Subclipse installed. However I started using TortoiseSVN 1.10. I have ignored files in a nested project (trunk > subproject > right click > TortoiseSVN > Properties) like:
However, if I trunk > right click > Commit, changes in subproject/bin/someFolder does still get shown. Weirdly the ignore works for subproject/build/*.
Any idea what could be the cause?
If a file has been commited to SVN then it doesn't matter if it is ignored or not. It will be handled like any other file you have checked out from the SVN repository.
So if you want to ignore files that have already been committed to SVN you first have to delete them from SVN.
TortoiseSVN has a functionality that combines deleting the file in SVN (but keeping it locally) and adding it to ignore list:
Unversion and add to ignore list:
The other ways like deleting the file locally and commit it or delete the file in SVN via SVN repo browser will end up in the local file being deleted. So you chose this way make sure to first copy the local files to a backup location so that you are able to restore the file(s) once the delete operation has been applied.
Related
Does anyone know how I can untrack a couple of files committed by accident?
I'm looking for the equivalent of the Mercurial hg forget command.
I'd especially appreciate any answers that explain how to untrack files using the Spring Tool Suite IDE, i.e. not from command line.
It seems that it is not as easy as in Mercurial :) especially if the repo is shared with others and they also need to keep this file (after it is removed from tracking and ignored, the first svn update will delete it).
See this answer for detailed instructions: SVN: Ignoring an already committed file
I found a way to achieve this by fiddling around. Neither of these is ideal - can anyone improve on this?
Option 1: Delete in SVN repository, then resolve
Navigate to Window -> Open Perspective -> SVN Repository Exploring
to view the repository.
Right-click on the file and press Delete...
Navigate back to Spring perspective
Right-click on the file and press Team -> Show Tree Conflicts
In SVN Tree Conflicts perspective, right-click and press Resolve... to explicitly accept the repository deletion
In Spring perspective, right-click on the file and press Team -> Add to svn:ignore
Option 2: Delete locally, then resolve
Move file somewhere else on local
Commit to repository
Copy file back into tracked project
Add to svn:ignore
Run svn delete <path> --keep-local in your working and then svn commit the change.
The first command will schedule the delete of the file in repository, however it won't touch it in your working copy making the file unversioned. You can add the file to ignores afterwards.
svn delete
--keep-local
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.
I am having terrible trouble with SVN in Eclipse Indigo with my Java project.
I am not a hobby, not a professional programmer, but I have heard how important version control systems are for serious projects, and thought it was time I learned how to use one.
Now I find I can't commit, no matter what I try. I get different errors depending upon what I do.
I suspect the problem was caused by my checking the "Persist project refactoring history in project folder instead of workspace" box in Project > Properties > Refactoring History, but I am not sure. But since I did that, I got an error saying "svn: Path '.settings' not present" error. I tried again,unchecking the box for .settings/org.eclipse.ltk.core.refactoring.prefs. This time I got a different error upon an attempted commit, "Path 'gamecore' not present". ('gamecore' is a root-level package in the project, where I'm putting most classes until they can be moved somewhere more appropriate.)
I tried several permutations of fiddling with the project preferences I'd changed, and unchecking some files on attempted commits. All failed.
In desperation, I cut n' pasted the source files I'd changed to a text file, reverted to my previous version, then cut n' pasted the new versions over top of the old. This time I got "svn: File '/Space Game/.refactorings' is out of date".
So I am in a position where, no matter what i do, I can't commit. At this point I am considering expunging the whole repository and importing from my workspace (something I did when I accidentally deleted the project before, thinking there was a duplicate in the repository.)
I've searched the web for the errors I've had, and all the threads I have found seem to assume a lot more knowledge of version control than I have. Most include bash shell commands, which I don't have access to.
My questions are:
1) Is this the best course of action?
2) Is there another less drastic way to recover?
3) How to I prevent this error from recurring?
I am using Eclipse Indigo with Subversive SVN Connectors 2.2.2, Subversive SVN Team Provider 0.7.9 and SVNKit 1.3.5 Implementation 2.2.2.
This happenend beacuse you checked your eclipse metadata into source control and then moved it by changing those settings.
So first do an update to get the meta files back. If you watch the svn console youl see something like: Restoring FILENAME
After you have them back and assuming your project is still set to put the meta data in a separate folder then you can do an svn delete on them and commit the deletions.
Set up an svn:ignore on all eclipse metadata ie:
.project
.settings
.buildpath
.refactorings
If i were you i would close eclipse and do this all from the command line so it doesnt confused.:
cd /path/to/project/root
svn up
svn rm .project .settings .buildpath .refactorings
svn commit .project .settings .buildpath .refactorings -m "Deleting eclipse metadata."
svn propedit svn:ignore .
# this will open an editor ignored files are one per line so your file should look like
# the following without the "#" signs
#
# .project
# .settings
# .buildpath
# .refactorings
svn commit . -m "Adding ignores to eclipse metadata files."
In my python/pydev project home directory, eclipse create 3 files/directory :
.settings
.project
.pydevproject
As I do not want to share these files, I set a svn:ignore flag on the home project directory with these 3 files/directory specified in it.
It works well for .projet and .pydevproject, but not for .settings :
From time to time, .settings reappears into the "team synchronize perpective" as to be synchronized/committed into the svn repository.
How can I get the eclipse '.settings' definitively ignored during svn commit in eclipse gui ?
Do you have checked in .settings before adding it to ignored? If so, you should remove it from svn (not the working copy of cause).
If the .settings folder was previously under SVN (i.e. commited) then you should remove it from you SVN first.
If you still want to keep it in your working copy, you can do:
svn remove .settings --keep-local
in command line, and do svn ls (if you see this folder listed, you haven't removed it from SVN!!!)
If you already removed it and still have a problem you can try one of 2 things:
1. Deleting the folder manually (assuming no complex\unique settings were made)
and letting Eclipse recreate it
2. Deleting only the inner folder `.svn` (only the one inside .settings),
and then running svn cleanup (Team -> Cleanup)
The first one is preferred, since it is never the best idea to mess around with SVN's files.
You can (and should) exit eclipse, back this folder up, and update your working copy before this process.
if you have installed subversive you should also install the "subversive svn jdt ignore extensions".
you will find it here:
help > install new software ...
select your eclipse download site. in my case its "Helios - http://download.eclipse.org/releases/helios"
you'll find it under collaboration > Subversive SVN JDT Ignore Extensions (optional) (Incubation)
That sounds you have sometimes added this folder under version control and checked it it. You need to first removed it (svn rm via command line or via TortoiseSVN on windows) and do a commit. This needs to be done outside from Eclipse. After you changed that you can start Eclipse again.
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