Eclipse acts as ".classpath" edited, and puts it in synchronization tab.
When I try to commit that into the repository on SubVersioN, eclipse gives multiple errors. I use jdk 1.6 and maven with Java. When not committing that .classpath thing, there is not any single error. I can commit my other class files succesfully.
Does anyone know how to deal with it?
How can I tell Eclipse that, ".classpath" is not edited or changed?
To make my comment an answer:
Eclipse handles all project's meta files itself. There are several actions that could lead to changes in the .classpath or even in the .project file. Most likely changes in the POM.
Errors when trying to commit such changes are most likely due to having a lower local SVN revision than the repository or due to conflicts. For both, do not use the synchronization perspective, but first do an SVN update (rightclick your project -> Team -> Update). If there is a conflict, you will be notified and must solve it. If there is no conflict, you should be able to commit changes, now.
For the future:
I always recommend to not put IDE specific files into version control. This way, each developer can choose whatever IDE he wants to use (if any at all). You also could work from command line (which CI systems do, for example). Using Maven and the M2E plugin in Eclipse is very easy: Checkout the project and afterwards configure it to be a Maven project. No need to have the Eclipse meta files under version control.
If you want to change it right now, do the following:
Remove the Eclipse meta files from the project folder. Commit that
change. I recommend to directly operate on the SVN repository (using
a repo browser, for example) or to checkout to another place, do the
changes there, and commit.
Do an SVN update your project in Eclipse. This will remove the meta
files. Update your project and then convert it again to a Maven
project (see above).
Last step: Ignore the meta files, so that they will not be committed
again. This can be done with Eclipse itself or with the svn:ignore
property (we do the latter).
Related
I have a project say Project in my eclipse workspace which I commit on an svn repository. When I make some changes in my local copy, I can easily integrate those changes with the project->right click -> team -> synchronize with the repository option. But in case I have another project name Project (same name for both projects) in another workspace say workspace2 which is not connected to svn and I want to synchronize it with the same project on svn repository How should I do it? Because the only choice in this case is project->right click->team -> share project or apply patch. To share this project I will have to commit it but in this case the contents of the project already available on svn repository will be lost. I want to merge the two projects such that the useful content of both is merged and the merged copy is available on the svn repository. Any help will be highly appreciated. Thanks in advance.
SVN can't automatically merge a SVN project with one that wasn't originally checked out from SVN. To merge two branches of a project, SVN needs to know which branch each change was made on. Otherwise it will just see the differences between the two sides, but won't have any way to know which side to keep. It can only do this if it has the history of each side's changes, which in this case you don't have.
What I would do is just diff the two projects, look at each change yourself, and decide whether to copy it into the SVN project. Start by backing up the non-SVN project, and committing any changes to the SVN project, so you have a clean place to revert to if you mess up. Then select both projects and do Compare With > Each Other. It will show you all the files that are different. Double-click each file to see the differences within the file, and copy them to the SVN side if you want to keep them. Then if everything looks good, you can commit it, and get rid of the non-SVN version.
I use Eclipse to edit Java, and use Git for my VCS. Should I have my local repository in my workspace, or outside it, and copy the files every time I want to commit? I know I can do it every way, but I'm new to Git, and wondering which way is better.
The best practice at the moment is to create your git repositories outside of your workspace. The most common form of repository contains a couple of projects in some logical structure, and the workspace likes projects in a flat structure. See the EGit User Guide/Considerations when creating Repos for more details.
When importing the projects into the workspace via standard import or EGit, Eclipse is happy to point to the other location on disk.
I just have the local repository in the workspace. I'm not sure why you'd want to keep the two separate - why create extra work for yourself?
Code, commit; code, commit... (where "code" includes tests of course)
Inside it. Creating an external one that you have to remember to copy files to, etc. starts to defeat some of the reasons to use a VCS like GIT :)
You can also always create and 'checkout' branches if you want to get some code separate for now. Then both the branch code and the base code are both in VCS and you'll always be able to mange them for merges, etc.
If you are used to subversion you may have this thoughts first. But working with Git means to have the complete repository as your own workspace.
You should configure Eclipse to use git and add to your .gitignore file the project folder if you do not want to have it in the repository.
As development workflow I can recommend the method Vincent Driessen bloged about: http://nvie.com/posts/a-successful-git-branching-model/
You have to remember that Git is just a single .git directory in your project. So you could just have one project folder that you work off of in your Eclipse workspace. If you are using Eclipse I recommend the EGit plugin.
Inside it; especially if all of your work is in Eclipse. Managing the repo outside of Eclispe is going to make it much more likely to add files you don't want in your repo (ex war/WEB-INF/classes). Also, managing from Eclipse means it will naturally be easier for other developers to sync your repo and setup their environment in Eclipse.
I suppose a good exception to this rule would be if you were maintaining a dev-environment folder of some sort (ex, jdk used/eclipse install used/jars for 3rd party libraries to add to build path/etc). So I guess the best general rule to follow would be if you're using Eclipse to change the files, you should also be using Eclipse to manage the file in your git repo.
Also, use EGit if you aren't already (I think others have mentioned this).
i was on a 2-day training introducing as to Java EE. We used there Java EE, Spring Framework, Maven, Springsource Tool Suite (Eclipse), Tomcat.
I took the Eclipse workspace we created there and run it on my work PC. I had, if i remember correctly, only to configure Tomcat properly, and it worked on my PC.
Now i want to save the created Eclipse workspace containing 5 "sub"-projects in subversion so that my work colleagues can checkout this to them and run it on their computers.
How to do this correctly? I found somewhere a svn:ignore rule:
.classpath
.project
.settings
target
Using tortoiseSVN i added to the folder with the workspace this ignore rule, but the found out that the underlying folders target were'nt deleted so i deleted them manually and "added to ignore list". But after that the project in spring source tool suite does not see the mevan dependencies (i think so) because the imports are broken. STS underlines org. in the imports and says it can not resolve this.
How do i correctly version control such a project?
In my project we are using Maven and Eclipse (Helios, currently) and the Maven plugins for Eclipse:
Maven Integration for Eclipse
Maven Integration for WTP
We only have the pom.xml file and the src/ directory tree in our version control system. We make sure not to add the eclipse files there. Then when a new developer starts in the project they do Import -> Maven -> Existing Maven Projects. The Maven plugins for Eclipse then set up perfect build paths, settings and so on.
This way it is also very easy to re-import your projects into Eclipse as needed.
So, my tip is to leave the Eclipse files out of SVN and make sure you can setup the project correctly automatically simply by importing a Maven project.
If I understand your problem the right way, you need to configure Eclipse in order to be able to launch tomcat from it. The key, here, is not maven anymore, but Eclipse, I think. As you've made modifications in your workspace that can't be put in your maven configuration file (the pom.xml), you become "Eclipse dependant".
The key here is that, as you're Eclipse dependant, you need the Eclipse configuration files to work. Consequently, I'm afraid you need to add back .classpath, .project, .settings to your versioning tool... It's not generic, because you force people who work on your project to use Eclipse. But if everybody in your team do so, it shouldn't be a problem.
As I don't use Eclipse anymore, I don't know if versioning theses files can lead to problems. However, I hope this answer will help you to configure your project back...
EDIT : to be more accurate... and maybe give a better answer.
When using a version control system, the main goal is often (always ?) to give all the keys to use the sources, and develop from them. Consequently, you need to put in your VCS your sources, and all the configurations needed to use them efficiently.
In your specific case, the key is that you've become Eclipse dependant through its Springsource Tool Suite plugin. Consequently, it becomes essential to add the configuration files for this tool, because they can't work without them, and if they can't work, you can't work.
I can tell you my way of subversioning maven eclipse projects. First, when you create the project structure you have to commit the .setting, .classpath, .project files into the subversion repository. If you can't do this the other colleagues will can not use the project structure after checkout. After you commit the project structure, the best way is not to commit these files except only when you change something important eclipse or build path settings, because the others will have conflicts due to the system dependent informations. Never commit the maven target directory. Sorry for my english. Hope it helps.
I was working with a project that I was uploading the source to a SVN repo.
For a few weeks I dind`t uploaded any code.
My computer has broken.
I could access to the HD and recover my eclipse project.
Now if I import my project into Eclipse and I want to synchronize with my repo, all my files appear to be in conflicts.
Is there any way that I could "clean" my recovered project so I can stop having conflicts and in this way start to sync my project again with my repo?
When I open a file to see the changes, in those files, where I know that there is no change between my local file and the repo file, my local file version is lower than the repo file, example (local file version: 244 and repo version: 351). But there is no change between one and another file.
How can I get my project working again with my repo?
First do a team -> cleanup on your project. This sometimes resolves some SVN-specific tree issues.
Then go to the team synchronization perspective and do an update of the complete project.
Select the conflicts tab and resolve each conflicted file, there are two options: 'override and update' (dismiss your local changes and continue with the repository version) or
'mark as merged' (indicate that your local file is correct, and the repository version should be overwritten)
Before selecting 'mark as merged' you can use the diff tool to view each discrepancy in turn and edit your local file if necessary. Note that the diff tool has a setting 'ignore whitespace' which might help reduce the clutter.
After you are done, before committing anything re-build the project from scratch and run all your tests.
If you still get stuck there is a more drastic solution: make a fresh checkout of the project in another directory and then copy your local changes into it by hand. Make sure you don't copy any .svn directories!
I want to checkin a Dynamic Web Project I created in eclipse into svn. Can someone tell me which files I have to check in and which one I should not? The idea is to be able to check out the project using the New Project Wizard so that I can create the Dynamic Web Project again. More specifically here are the files/directories I have in the project --
src
WebContent
build
dist
build.xml
.project
.classpath
.settings/
The build directory is not supposed to checked in obviously. What about the other ones?
I am guessing all the . files should not be checked in either. Can some one verify this?
What is this dist directory and the .settings directory?
Also where does eclipse store the Server information (tomcat)? I don't want to check it in either.
EDIT:
I initially checked in all of the above except the build directory of course. When I checked out the project from inside Eclipse it did not prompt me to create a new project since the .project is there but Eclipse was creating a JavaEE project or something instead of the Dynamic Web Project. Did anyone else run into this behavior?
** EDIT 2 **
Found it! Turns out I should not check in the following --
.project
.settings/
.classpath
Once these 3 are removed the New project Wizard works as expected and everything is fine.
If you check in .classpath/.project/.settings you make your project Eclipse-specific. What about developers who work with Netbeans or IntelliJ? IMO it is cleaner to keep your project IDE-independent and easy to set up.
I usually go for a Maven build. The pom.xml specifies all the required dependencies and mvn eclipse:eclipse generates the .classpath/.project files for you.
The .settings directory contains local settings (like which Java version you want to use). IMO it is not useful to check this in. You can enforce Java version compliance via the Maven2 pom.
Finally, for your next project, my protip is to svn-ignore the files or directories you don't want in SVN before your first commit. In a Maven2 setup that would be .settings .classpath .project target (the default output directory of Maven2) and any other generated stuff (log files, gfembed directories, etc). In your case you would ignore build and dist instead of target.
You can svn-ignore files or directories with RIGHT_MOUSE->Team->'Add to svn:ignore' (I use the Subclipse plugin). Ignore instructions are stored as svn-properties on the parent directory. The properties on a directory can be viewed by RIGHT_MOUSE->Team->Show properties. You can also edit the properties directly there by clicking on the value field. Make sure there is an end of line after each property.
Now that you have already committed and then removed these files, ignoring is not going to work anymore in my experience. Somehow I have never managed to successfully ignore generated files which have ever been checked into the SVN repository; they are like zombies, always coming back from the dead. Maybe by deleting their entries physically in the SVN repo this can be achieved, but I've never done it.
In our case, we have checked in all you mentioned in the list except, .settings/.
With .classpath and .project checked in, users can quickly check out the project and fire up Eclipse on a new computer and just start working on it; the alternative being to configure the project manually and adding in all the jar dependencies painstakingly (if you use ant). Many open source projects do this.
Read this, there are some really good points to ponder about.
Good Question... Many of us are in a dilemma on whether we want to check in IDE related files or not. I normally go for checking in .classpath for eclipse and I use eclipse variables to make sure that team needs to just change the variable value and it works. We also check in .project so that team need not to create new project in their workspace.
I would omit the .project, .settings/, dist, and build.
The .classpath can be left in if you use variables instead of hardcoded paths. This is useful so you don't have to rebuild your classpath every time you check out the project.