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.
Related
To date I have done all my management of SVN via TortoiseSVN. I would like to learn a bit more about how to use Eclipse/Subclipse. The main thing I am trying to figure out is the update. The issue is this that I need to update more then what is in the Eclipse project. Here is what things look like in Subversion:
trunk
Clients
EclipseProjects
Project1
Project2
Project3
Project4
Project5
Project6
Project7
JDK
SQLScripts
The issue is that while the Eclipse workspace only contains a few of the Projects# directories, to run the application one must drop to the command line and run it and the application uses ALL the projects. I also want to be updated the other folders that are at the same level as EclipseProject: Clients, JDK, SQLScripts.
Currently with TortoiseSVN, I simply go to the trunk and do an update. How can I do that within Eclipse when the trunk is not part of the workspace?
Subclipse can only operate on what is loaded into your Eclipse workspace. You have a few options here, not in particular order:
Checkout each project separately using Subclipse. Each project will be its own SVN working copy.
Checkout "trunk" using Subclipse. Just create an Eclipse "simple project" for this checkout. The individual Eclipse projects can then be Imported into your workspace. So projects will show up twice. Once as themselves, and once as a folder beneath the trunk project. If you want to update them all at once, you can take the Update on the trunk project. But you can still take actions on individual projects too.
Same as #2, but do the checkout of trunk using TortoiseSVN. And use TortoiseSVN when you update everything. You will need to do Team > Refresh to let Subclipse know you did something in TortoiseSVN. I would still use Subclipse and import those projects into SVN. Even if you do all your commit and update actions using TortoiseSVN, there are advantage inside Eclipse to having Subclipse installed and TortoiseSVN and Subclipse can both use the same working copy fine as long as they share the same SVN version.
I use all 3 of these approaches in different scenarios.
It's actually quite simple. All you'll have to do is check out the repository using Eclipse check out tool.
In Eclipse, open Window > Show View > Other..., select SVN Repositories. Click New Repository Location, enter your SVN url, username and password. Once the repository added, do Checkout and voilà.
A little advice based on my experience : do not check out the whole trunk! Because then you will have one big folder trunk in the Project Explorer and it's frustrating open three folders trunk > EclipseProjects > ProjectXYZ everytime to actually get to your project. It's also not very visually pleasant and ordered. What I recommend is checkout the ProjectX folders, Clients, JDK and SQL Scripts folders separately. You'll have a nice flat hierarchy like this :
Clients
Project1
Project2
Project3
Project4
Project5
Project6
Project7
JDK
SQLScripts
Remember that using this technique, anything outside the scope of these folders (e.g. trunk/EclipseProjects/log.txt) won't be taken into account. If you have anything like that, you can always put it in the separate subfolder of trunk and treat it the same way as others.
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).
I tried my best to get a multi-module Maven project synced with GitHub using EGit, but I've failed.
The structure of the project is like this:
parent (pom)
child-one (jar)
child-two (jar)
I tried this simple approach:
Completely blank copy of Eclipse JDT and an empty workspace
Create a new GitHub repository and initialize it with a README.md file
Clone that repository to Eclipse
Create the parent (pom) project
Create two children (jar) projects, add simple main classes, everything works at this point
Now comes the tricky part. Do I share just my parent project? Or children as well? Well, it seemed logical to me to share the parent only. However when I did, my build path went completely crazy and Eclipse could no longer find main classes. Then I restarted Eclipse. Issues persisted. Then I "disconnected" the project with the repository and logically EGit randomly deleted one of the children on the file system, and made the Eclipse project completely unusable (no classes would display, all structure was gone).
I previosly had an episode where EGit randomly deleted one of my repositories and that time it wasn't just a test, it was my actual latest changes to the codebase.
Is this plugging completely bugged out or am I missing something?
(I followed the basic tutorial on setting it all up, and have my SSH keys configured properly.)
What should I do to properly push a local Maven multi-module project to GitHub, and be able to clone it on a completely different PC out of nothing?
Actually it's 100% possible to do this!
Here's an even simpler approach than before:
Clone your repository
When creating a new Maven project, don't place it in the default Workspace location, place it in the *subdirectory** of the repository
Done! You can create as many sub-modules as you'd like, Eclipse has automatically detected your Git repository.
* the subdirectory is automatically created for you when you choose the default location, and it is named after your module. It's not automatically created when choosing a different location (which is a bit inconsistent, but makes sense). If you just choose your repo as your location, Eclipse/Maven will then generate all the top-level project files and directories (pom.xml, .project, src/, .settings, ...) in your repo's root directory - which might be what you wanted, but most likely isn't.
For a more complicated explanation of why it wasn't working, read on...
It's just a bit complicated and very unintuitive. Here's a picture of how it looks:
Steps I took (make sure to backup anything important):
Create a new repository on GitHub (with README)
Install Eclipse JDT (the "Java" download, with Maven and Egit preinstalled, but it would work in any Eclipse version I presume)
Clone the repository in Eclipse. At this time, there are no projects to import or anything, there's just the repository. To clone, go to Window -> Open perspective -> Other -> Git Repository Exploring
Create your projects in Eclipse using Maven. I first created one child and one parent. The parent has to have packaging type of pom. The child can have it as a jar and has to be a Maven module, not a project (but it's essentially the same thing). At this point I created a simple main class in this child module, and saved everything
Share your parent project to the repository you cloned before (right click on parent -> Team -> Share project -> Git -> select your repository). Now, things will start falling apart, but this is normal. Wait for Eclipse to finish. What happened is that Eclipse moved the project from the place you saved it previously (for me it was my workspace) to the git repository - and since the parent has the children inside it, it also moved the children repositories with it. However, it didn't update its definitions accordingly, so the child project is now just shown as an empty directory. You can commit now
Delete the missing child project (not the parent!)
Just import the projects again
Sadly, Eclipse does not really support what you are trying to achieve because it assumes the project hierarchy is single-level; while in your case the parent project contains the child projects as well. For details see this long bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=35973 (at the end there are some nice summary comment about the status).
As workaround I can suggest two things:
Do not import your parent project into Eclipse.
Put your parent project as a simple project in the hierarchy, where child projects are referenced with hierarchic paths
The projects I am involved in mostly follow the second approach (see e.g. the EMF-IncQuery project, where the parent is stored in releng/org.eclipse.incquery.parent in http://git.eclipse.org/c/incquery/org.eclipse.incquery.git/tree/), but if your parent pom rarely changes, the first option could work well as well.
Note that all the trouble and distress discussed here is specific to using the 'sharing' features of Eclipse in which the code is directly checked in and out of the workspace from source control. You don't have to use those features -- all of this works perfectly, with no magic and no stress, if you do not.
If you do a plain old git (or svn (or whatever)) checkout outside your workspace, and then use Eclipse's feature of opening an existing project leaving its source outside the workspace, everything will be fine. You will still have VCS operations in the resource tree, you can still commit or merge from inside Eclipse if you like, and your multi-module-Maven project will simply work with no special incantations.
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 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!