First, there are no problems with my build path, and there's no problem in the "problems" window regarding this error. What happens is:
I check a project out of SVN
I then build that project
SVN "version" and link gets removed from classes and build directories (and red ! appears)
I can no longer commit project as a whole, as I get this error:
svn: Commit failed (details follow):
svn: Working copy 'C:\Users\<me>\Documents\eclipseSDK\<project>\classes' is missing or not locked
It's NOT missing, it just was "refreshed" during build
I've also tried to delete the dir on the SVN side, but the red arrows still appear and committing throws an error - even though those dirs are no longer part of the checked resources.
Also, basically, any "Team" menu option will no longer work on those two dirs, if I try to Team>Add to Version Control, nothing shows up in the Resources window.
I don't even know if I care about the red exclamation as much as just getting those two dirs out of the SVN process. Like I said, I've deleted on the SVN side even, so they are no longer there.
Are your compiled classes file part of your Subversion repository? If so, GET RID OF THEM FROM SUBVERSION!.
Sorry about the screaming, but files that can be built (like classes and jar files) should not be stored in version control. It just doesn't make sense.
Source control allows you to see the history of changes. You can see who made what changes in the source, but you can't do that in class files or jars. Source control allows you to branch and merge changes. You can't do that with class files. And, they go stale very quickly. No one cares about class files that were built last month.
The biggest issue is sheer size. Binary files don't diff well (and many version control systems don't even try). Let's say you build 15 megabytes worth of class files each time you do a build. That's probably at least 12 megabytes added to your repository each and every time. With in a year, you could be adding, 1 gigabyte to your repository. You can easily end up with the vast majority (and I mean in the 90% range of your source repository being nothing more than compiled code. Compiled code that no one cares about. Compiled code that can't help you understand your development history. Compiled code that clogs up your repository.
Go to your classes directory, and do an revert from the Team menu on that directory. You'll lose all of your changes, but so what? They shouldn't be there. This will set things up, so you can at least commit your changes.
Then, delete that classes directory and all of its contents from Subversion and commit. Eclipse will create the directory when it does a build, and you can make the directory in Ant's build file before you compile the code. You should then set an svn:ignore property on the directory parent to prevent people from checking in the classes directory.
If you need to store jar files for other projects to use, use a release repository. In fact, use a Maven repository like Artifactory or Nexus. You don't have to use Maven. Ant can use Ivy to fetch the files from a Maven repository, or you can simply use URLs to download the files as needed via wget or the <get/> task in Ant.
OK, I deleted [build & classes] from local, and deleted from SVN. Made a minor edit to a file, just to be able to run Commit - which worked fine.
That's good.
Both local & SVN were in sync. build & classes are (and were) part of ANT build file, so ran build again. build & classes reappeared (with ? this time), and added to svn:ignore.
Any file that's not in the repository will show up with a question mark. Those question marks will disappear if you add the svn:ignore property to the parent directory with classes, sync, and build in it.
Made another file change, but now I cannot commit the entire project, as I'm getting more/different errors now (e.g. "out of date").
The out of date means that someone somewhere modified a file that was in the repository and committed it. It's very likely that the change is one of the *.class files that you removed. You will have to do an update before a commit. When you do the update, you will likely see a lot of conflicts where a class file was changed, but you had removed it. Resolve these changes, update, and commit again.
By the way, I have a pre-commit hook that is useful in this situation. First, it can prevent people from adding that classes directory to the repository (and any files under it). Second it can make sure that the svn:ignore is setup correctly.
Related
I'm totally new to git and have a question related to the work bench. I do stuffs in java so I would ask in term of java. When you commit files to git repository, do we commit .java, .class files? Or it is ok to put the whole work bench into the local git folder then commit everything?
It's generally not considered a good idea to commit binary files to any version control system if you can recreate them by simply compiling the source code you also committed. This is especially important with a DVCS as every copy of the repository carries around the redundant data. This might not be a big deal if you're working on a fairly small project, but once the project gets bigger it's a nuisance.
The other problem with committing the .class files or any sort of binary is that any sort of build will show your source tree as "dirty" in multiple places unnecessarily as both the class files and the java files will need comitting.
My advice would be to put the build directories in your projects in .gitignore so git knows not to look at them, then add your source files and the Eclipse project files to git.
Every once in a while I get an error when committing code to our SVN repo, and this is what it says (I'd show a screenshot but I can't reproduce it):
SVN: '0x00400045: Collecting Properties' operation finished with error:
0x00000014: Resource is inaccessible or it is not under SVN control:
'C:/Users/blah/dev/big_project/bin/com/meh/package1'.
0x00000014: Resource is inaccessible or it is not under SVN control:
'C:/Users/blah/dev/big_project/bin/com/meh/package2'.
And my commit dialog which shows up after dismissing that shows some (but not all) class files under my bin directory:
If I do a Project>Clean, (and then it rebuilds automatically) the message goes away for a long while. It seems to happen only after I build the project via an ANT script (which uses javac instead of Eclipse's compiler), but it's not reproducible. As in it'll happen after an ANT build, but not always.
The bin directory is supposed to be ignored. What's going on?
I had the same error, among others. I don't know what's the cause. The only (desperate) way I could fix them was deleting the project from SVN repository (Delete project through the SNV Perspective in Eclipse and removing manually all the ".svn" hidden folders inside the real path of the project). After that, I was able to commit the project again without errors.
Whatever the cause adding bin to svn:ignore should fix it.
In my project I have a directory structure like this :
project
--common
--subproject
--common (junction, not a copy)
The subproject needs some files from common. Therefore I created a 'junction' (in XP using the sysinternals command) to be able to see and make changes in common from within the subproject.
This works like a charm, any changes to both commons are immediately on both common since in fact it points to the same folder.
Then I made a separate project in Eclipse for the subproject folder and its own svn repository.
But when I want to commit the subproject, it wants to commit the 'common' folder as if it were a real folder, but in fact this folder needs to be committed only to its parents repository!
Is there a way of telling svn to make commits to a different repository than its own?
svn:externals is not a good solution since this creates duplicate sources, and makes it even harder to maintain, because it's not automatically kept in sync.
eclipse's file system abstraction features linked folders.
Have you tried using those rather than a junction at the filesystem level? (I don't know how the subversion plugin treats those, but perhaps you are in luck)
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