What is causing these red X's on my files? I accidentally moved my source folder into another folder in my project and when I moved the folder back and recorrected the location of the source folder I started seeing red X's on all my files in that folder. My project builds and runs fine, but svn seems to still believe I have deleted all these files if I try to commit. Is subclipse marking them? I do not see any errors under problems and cannot figure out how remove these.
That means files are deleted and you need to commit the folder/package that's being deleted to reflect the same in the repository.
Related
I have a project in Eclipse Oxygen that uses Git. When a file is created or edited it shows in the Unstaged Changes list on the Git Staging View. This allows you to drag the file to the Staged Changes list and then it can be committed.
I needed to create a folder named .sti directly under the project folder and then a folder named bin under that, like this:
project/.sti/bin
Then I had to create a file called assemble in the .stl/bin folder.
The problem is that the file called assemble does NOT show in the Unstaged Changes list. Therefore I cannot stage and commit it.
Is there any way of getting this file to appear?
I'm sure that the .sti folder is the cause of the problem.
Any ideas or help would be much appreciated...
In the end I deleted the .gitignore file in the project folder and recreated it. Upon refreshing the project in Project Explorer, the changed file appeared in the Unstaged Changes.
This was rather strange as the original .gitignore did not specify: .sti
I'm using Juno SR2 on Windows, with Subclipse 1.8 (JavaHL 1.7.9), against a svn:// repository. Sometimes during synchronization I would see some folder is marked in red as having conflict, the files under the folder are all checked in without issue, just the folder itself having this problem. I don't want to revert, so I tried "Mark as Merged", but this pops up error " (Access is denied)", I have no idea what this means or how to resolve it.
I often get this problem after ignoring resources in subfolders of the folder in question. Simply updating the folder gets rid of the conflict.
I confirm that when you make a svn update to the folder it resolves the problem.
I'm using SVN within Eclipse. Whenever I change a file I commit the changes. It works for everything except for three certain folders (which contain certain files) I cannot commit. When trying to commit them I receive the following error message:
workspace\yp\src\yp\forum\locale\cs is one of the three uncommitable folders. The folder definitely doesn't exist on the server yet, but I get the above error each time I'm trying to upload it.
How do I solve the problem?
EDIT: I've deleted the .svn folders from the problematic directories. I still get the same error when trying to commit and the problematic directories have no .svn folders.
EDIT: I'm still trying to fix the problem. Now I get another error message when trying to commit:
EDIT: Now I've tried to do Team --> Cleanup and got that error message:
Move the problematic folders out of the way, then do Team->Update which will recreate the folders from the repository.
Then you can copy your changed files back.
This problem can arise when there are files in a folder checked into the repository that only differ in case - which is not supported in Windows. So it might be worthwile to look at the repository with a repository browser - if it is http:// then the web browser will do.
try deleting .svn folder in your pc and try adding folder or file again.
Extract your project from SVN to a new folder.
Erase all sourcecode files ( something like any file but .svn ) and replace with the ones from your previous working folder.
Try Team/Cleanup in Eclipse (right click in Project explorer or Navigator)
I'm trying to do a commit on my project and am running into the following error. Pay close attention to the path:
Commit failed (details follow):
Cannot commit both
'C:\Development\Project\branches\nextver\project\bin\com\companyname\blah\Foo.java'
and
'C:\Development\Project\branches\nextver\project\src\com\companyname\blah\Foo.java'
as they refer to the same URL
How in the world did this happen? I never had my source files in the bin path in Eclipse! What can I do to fix it? Please tell me there's something better than checking it out again and replacing all of the files. I have 191 Java files alone, not to mention resources and Eclipse files.
I know it's over a year since you posted this, but this may help someone else. I've just gone through the same issue. I eventually traced it back to the project setup on Eclipse. In my case what happened is the build process within eclipse was "building"/copying ALL files in the source folder to the build folder. This caused the .svn directory from the source to be copied to the build folder and this is how Subversion gets mixed up. If you check the paths via RepoBrowser (I am using Tortoise in a Windows environment) the paths point to the correct directories (source and build), but if you run "svn info" from within the directory on your local machine you will find that the source and build directory point to the same URL (hence the message).
Once I realised the problem was within Eclipse and not specific to Subversion it was easy to search for a solution. You need to add "**/.svn/" to the source exclusions in the Java Build Path of the Source tab:
Project --> Properties --> Java Build Path.
Try this:
Go to C:\Development\Project\branches\nextver\project\bin\ and delete .svn if you see one. And then try committing.
I think somehow stuff in the src including the .svn got copied to bin making both of them seem like they are from the same url in the server. Of course you don't want that. You may want to correct your build settings.
The solution was to delete and ignore my bin dirs from my local copy. Again. Tortoise SVN seemed to forget that I had done that before and I didn't notice that the bin dirs had crept in, leading to this problem. After resolving several other problems it threw in my path (source trees in conflict, etc.), I managed to get it to commit.
I did first try deleting the .svn folder from the bin dirs, but all that did was cause it to complain that the bin dir was no longer under source control and halt.
In my case I had a config file that was shared between two projects but I had updated the file (with the same changes) in both projects.
SVN can't commit as it thinks there are two different sets of changes to be committed to the same file.
So I reverted one of the copies and then I was able to commit.
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