I have a project in Eclipse, MyProject/, that I want to share and import into my SVN repo:
MyProject/
src/
dist/
lib/
...etc.
Ultimately, I want to end up with an SVN repo for this project that looks like this:
svn://mySVNrepo/
MyProject/
trunk/
src/
dist/
lib/
branches/
tags/
But when I right-click MyProject and select Team >> Share, and follow the prompts, I end up with:
svn://mySVNrepo/
MyProject/
src/
dist/
lib/
So it's: (1) not allowing me to create trunk, branches and tags dirs, and (2) not allowing me to "nest" my imported project into trunk.
I then tried to create the directories manually from the SVN Repo Explorer view, and created:
svn://mySVNrepo/
MyProject/
trunk/
branches/
tags/
Then, I tried to share my project at:
svn://mySVNrepo/trunk
When I try to run this initial import, I get a warning from Eclipse:
Warning: The specified folder already exists in the repository. If you continue, that folder will be checked out to your local workspace and your project will be connected to this existing location. Do you want to continue?
I don't want to overwrite my local copy (that I'm trying to share); it has a lot of work in it!
I don't really understand what this warning is telling me, and basically I don't want to mess anything up!
So I ask: is my approach wrong, and if so, how can I commit my project for the first time into a trunk/ subdirectory? And if my approach is correct, then please help me decipher this warning message and advise on what I should do. Thanks in advance!
One approach that would work is to keep your manually created trunk/branches/tags directories in SVN. Check out the empty /trunk into a parallel directory on your local workstation (Let's say directory #2, with your local project as #1). Then copy your project + code from #1 into that /trunk directory and commit to SVN.
Then you can make a 3rd directory locally, and check-out your SVN copy and ensure it compiles/runs properly. If so you can delete the intermediate #1/#2 directories, or keep your initial project as a backup just incase (but it'll be non-versioned). Then continue to use directory #3 as your new SVN monitored workspace.
If I'm unsure how my changes will affect work that I don't want to lose, I try to take an approach like this so the least amount of harm is done to my code if something goes wrong (say with a SVN command/operation I'm unfamiliar with, etc).
From the menu, select Window > Open Perspective > SVN Repository Exploring
Right click your repository > New Project Structure > Single project or multiple projects layout > enter 'MyProject' for the Name. This will create the new project with the /trunk/branches/tags/ project structure.
Once it's created, right click the Project and select Checkout.
'MyProject' should now be in your Navigator View. From there you can copy your /src /dist and /lib folders into 'My Project' trunk folder.
Right click your Project and select Team > Commit.
EDIT:
You can also try the Subversive plugin for Eclipse. This plugin has an easier way to share your existing projects to svn as a multiple project layout (trunk/branches/tags folder structure).
I posted the steps in a similar thread.
After one hour of trial and error, I just did the following:
Share it to a wrong folder
Go into the SVN explorer and rename the folder (with src etc.) to trunk
Move that trunk to the correct location (e.g. Project/trunk) in svn
Got into the Project Explorer in Eclipse, right click on the project, team, switch and select the new trunk.
Related
I'm working on a group project for my software engineering course, and my professor has indicated that I set up the directory structure incorrectly on Github. I'd like to correct the issue now to avoid a grade penalty, but I'm very new to using Git. Basically we have a structure that is as follows on Github.
src
--main
----java
------Source Files
--test
-----java
------Test Files
Various Ivy/Ant build files
.classpath
.gitignore
.git
.project
README.md
I need to create a new directory called CodeComp that will contain the directory structure above except for the README.md, which should be on the same level as the CodeComp directory.
Since our grade is dependent on the commit history, this would need to be preserved. Is there an easy way to do this or are we better off just taking the small deduction on the final project grade?
UPDATE:
In case anyone else has to do this in the future:
Go to the folder holding the project and create the new directory.
Move all files needed into the new directory except .* files. Refresh Eclipse.
Commit and Push the directory changes to the repo regardless of Eclipse errors.
Manually delete the .classpath, .gitignore, and .project files from the repository.
Back-up your .classpath and .gitignore files. Delete your local copy of the repo and re-clone it.
Import the Git project and choose to put the project files in your newly created directory.
Copy the .classpath and .gitignore you backed up into the new project directory. Push the changes.
In theory you should be able to use a standard file browser to move everything but your .git and Readme file into your new sub-folder and then commit that.
The git history will still there but it may see it as two separate files, one that has been deleted and one that is just created. In my experience Git doesn't really like moving files.
In any case, you commit history will still be in the repository, it will just be 2 separate sections from when you moved the files.
But, hey... It may pay to show that move anyway. I know for sure that I was moving files all around when I first learnt about version control. It's all learning.
EDIT: You can test this by committing the change locally and checking the history before you push it upstream to Github.
I just started interning for a CIS team at a large company, and I'm trying to get my workspace set up. Right now I have to import the cis project from the SVN repository into Eclipse. The problem is that the project is huge (multi moduled with many revisions), and when I try to check out the entire project it gets to 95% and goes into a gruelingly slow crawl as it starts checking out all of the revisions.
So I read the Eclipse install instructions on my department's wiki page, and it tells me that I need to export a Team Project Set by doing
Export -> Team Project Set
on my "old" Eclipse and then later importing the .psf that I acquire out of the export onto the "new" Eclipse
But this is not available to me as I'm on a newly formatted computer and I have no previous projects to export.
I can import a small portion of the project that I can work with, but I can't seem to find the JAR files that I need for the build path.
I've spent almost 3 days on this, and I'm startting to pull out my hair. Can anyone help me with this?
So after some experimenting I found a solution which seems to work for now. I ended up importing solely from the directory that had all the files of code necessary for the scope of my first task.
However, I ran into a problem that I had been having before where I couldn't use basic navigation commands like F3 for viewing declarations. To fix this I did:
Project -> Properties -> Java Build Path -> Source Tab
The only folder on the build path was cis/src. I removed this one and added the entire parent directory cis.
If you are importing from an SVN repository and you can't change the settings for the build path, make sure that you imported your project as a JAVA Project, as opposed to a general project. This should link whatever JAR files you need.
If you need to add another folder/directory from the SVN that you didn't import initially, you can do so by doing almost the same steps as you did the first time:
File -> Import -> Project from SVN -> choose the appropriate directory ->
Select "Check out as a folder into existing project" in "Check Out As" window.
Afterwards you can move the newly imported files as necessary.
Fellow interns, if you aren't sure about anything, DO NOT hesitate to ask your supervisors for help and clarification.
I've just started to use Bitbucket, but I've the same problem on Github. I'm using Eclipse with EGit.
My problem is when I commit and push: I don't see directly "src" but there's a folder and it's in: https://bitbucket.org/Knux14/screenup/src/
Instead of having my src folder, I need to click on "ScreenUp" first, and then I can see src.
Did I make a mistake on pushing?
You simply added the folder containing your whole project to Git, so now all your stuff is in the subfolder ("ScreenUp").
You can keep using it like this, that's no big problem. But if it bugs you, just remove the repository and remove the project from version control (Google will help), and add it again.
I'm a student and have to work with Java and Eclipse. As we have teamprojects i have to sync my workspace with other students. The only problem i have is a folder called .metadata, right above my workspacefolder. Is there any possibility to change the path of this folder so that it won't be synced?
You can sync your project folder instead of the whole workspace.
If you want to share multiple projects you can put them in a sub-folder of your workspace and share only this sub-folder.
BTW, I recommend you using a real SCM like GIT or SVN that give you opportunity to ignore some file/directory.
I usually have multiple copies of a project, for example: a copy of the trunk and another of the last release branch. To cleanly separate my project files from Eclipse, they are checked out from Subversion in a directory outside the Eclipse workspace.
I want to make the project easily importable to Eclipse and followed instructions from multiple answers.
The problem is that my .launch files have the project name hardcoded. When a new project is imported, the launch files will display in the Run Configurations menu just if the project has exactly the same name of the exported one. This forbids me to have two versions of the same project.
It looks like the only way to do it is to have the .launch and .project files generated from an Ant task, but I don't see anyone using this solution. Maybe I should have multiple workspaces and the project always with the same name.
What's the best way to do it?
Edit: I'm marking VonC as the answer, but don't miss the comments.
Remember that the .launch configuration files don't have to be in your workspace.
They can be in your <project>/.settings as I mentioned in the answer you refer to.
That means you cannot import in your eclipse workspace two versions of the same project.
You need separate workspaces (not versioned themselves), each one referring to a project in a different path.
Each path represents different working trees (like different working directories for Subversion).
The OP adds:
The project must have the same name, but the project checkout dir can have any name.
To make the launch file work, you have to reference any file using the variable ${workspace_loc:ProjectName}.
Java files can be referenced using a path like: '/ProjectName/src/package/MyFile.java'
This way, it is easier to use any tool to interact with the subversion repository.
I want to make life easier for who uses Eclipse, but I don't want to force anyone to use it.
My recommendation is to tie the workspace to the checkout location, and then you can use the launch configurations for the relevant projects in Subversion.
My directory structure looks like this:
{checkout root}
|
+code
|
-workspace
In your case, that would mean a workspace for the trunk, and any other branch/tag you check out. I also keep all my projects outside the workspace. The workspace directory in Subversion is empty; I just recursively add the project reference(s) to the workspace from the sibling tree. It also helps if you export your Eclipse settings, as you can then re-import them into each new workspace.
I derived this approach from a pair of IBM and Rational white papers for using Eclipse with Rational ClearCase. This should work unless you need to have multiple versions of the same project open in the same workspace.