I have selected several projects in my eclipse CVS repository and I have marked them with a new version/tag.
I would now like to display the content of this new version instead of analysing projects by projects the history of each.
Is there a solution ?
I've googled and no result for my need (may be wrong key words ?)
Thanks you.
Patrice
I'm assuming that you have 1 CVS repository which contains N Eclipse projects.
Create a simple Eclipse project at the root of your CVS repository. That will allow you to import everything as a single project. From this project, you can see the whole history over everything.
When you want to work on a child project, import it from the local disk instead of from the CVS server. Don't forget to disable "Copy files" when you import. Eclipse will notice that these two projects are related (i.e. one is inside of the path of another). Doing CVS operations will now work on the parent project.
That said, you should really consider to move to a DVCS :-)
Related
We have a huge, old, and ugly SVN repo, with a main folder on the top.
This folder contains the branches folder (with the core of our code), as well as several other folders F1, F2, F3... that contain some dependencies.
I would like to import in a single Eclipse project, by using subclipse, a particular branch as well as only folders F1 and F3. But subclipse doesn't seem to allow a checkout in an existing Eclipse project (but perhaps is my intent totally stupid?). And what if I want to import folders that are outside main?
An Eclipse project that is linked with Subclipse has to be a single SVN working copy rooted at the top folder of the Eclipse project. So any legitimate way that exists to construct a valid working copy would work. This could be checking out the top level folder using the Depth = Immediates option and then using the update set-depth option to expand specific folders. You could use Switch to swap out some folders with those from a different branch. You can use svn:externals to pull in folders from other locations etc.
It is hard to say which, if any, of these options might work for you.
When sharing a project as git and trying to make the Eclipse project folder as the git repository, Eclipse says that it is not recommended to do so and that it should be outside the Eclipse workspace.
Why is that?
From Eclipse EGit help pages,
It is probably not a good idea to make a project the root folder of your Repository
The reason is that you will never be able to add another project to this Repository, as the .project file will occupy the root folder; you could still add projects as sub-folders, but this kind of project nesting is known to cause lots of problems all over the place. In order to add another project, you would have to move the project to a sub-folder in the Repository and add the second project as another sub-folder before you could commit this change.
Some more information
It is a good idea to keep your Repository outside of your Eclipse Workspace
There are several reasons for this:
The new Repository will consider the complete folder structure of the Eclipse workspace as (potential) content. This can result in performance issues, for example when calculating the changes before committing (which will scan the complete .metadata folder, for example); more often than not, the workspace will contain dead folders (e.g. deleted projects) which semantically are not relevant for EGit but can not be excluded easily.
The metadata (.git-) folder will be a child of the Eclipse Workspace. It is unclear whether this might cause unwanted folder traversals by Eclipse.
You can easily destroy your Repository by destroying your Eclipse Workspace
While I agree about keeping the repository outside the Eclipse workspace, and I would still make a git repo within an Eclipse project root directory (like in this answer).
Unless your program is composed of lots of little inter-dependent projects, I would limit one git repo to one Eclipse project.
A git repo is about recording the content of a tree structure, and if that tree represents one project, it is easier to manage, tag, branch, merge (as a coherent set of files).
If it represents multiple project, you are not sure anymore about what a tag like "1.0" represents for each of the projects in that Git repo.
Plus, I like to add the .project, .classpath and .settings to the Git repo (as "Does git exclude eclipse project files from a new repo by default?")
I have an old eclipse java project which is stored in SVN. I wish to create a new one based on the old one but without the SVN files. I'll be doing some experimental changes to it and I want to have the old one as backup basically. Anyone can give advice on how to do this? Thanks
FYI: This has been posted in Javaranch as well
You have a number of options:
Don't do a check-out (which creates the metadata files, allowing for changes to be easily and later committed), but an export instead. From the "SVN Repositories" view in Eclipse, right-click the project folder, then click "Export...".
Just check-out a 2nd copy of the project from SVN, naming it with a different project name in the workspace to keep it distinct. Just refrain from checking-in any changes back to the SVN repository.
Copy the project as usual, and simply delete the SVN metadata files.
Same as #3, but let Eclipse do this for you - using Team / Disconnect.
I keep my .project and .classpath files in my source repository. I maintain separate eclipse workspaces for each branch off my trunk. I've found the best way to do this is to recursively copy my trunk workspace (cp -r dev/ branch-foo/). This works great. There are a few other details that facilitate sharing templates and key mappings, but that's not important here. The issue with this solution is that I end up with a workspace that, to no surprise, contains all the trunk projects. I then have to remove all these projects from the workspace manually and then import all the projects in the branch. Not a huge deal, but I'm wondering if something better can be done to automate this process.
I don't see any files that get written to as I add/remove project files in my workspace so I'm assuming eclipse manages these relationships in some internal DB or something. Additionally, I looked into any command-line support eclipse offers for doing this, but don't see anything.
Any thoughts would be much appreciated.
One P.S. - I do see some binary files located in ~/workspace/branch/.metadata/.plugins/org.eclipse.core.resources/.projects/project_name/
I have an eclipse project on my hard disk, which is a fairly recent check out from an SVN repository. I've imported this project into my Eclipse workspace, and now want to associate it with the SVN repository.
How do I do this? The only options I seem to have under Right-click -> Team is "Share Project", which only seems to allow me to do an initial import.
Edit: Motivation - It's a largish repository, and I don't really want to have to import the whole thing over the network.
Edit 2: There are (for some reason) no .svn dirs in the project. So maybe a fresh import from svn is the only option
Team->Share project is exactly what you need to do. Select SVN from the list, then click "Next". Subclipse will notice the presence of .svn directories that will ask you to confirm that the information is correct, and associate the project with subclipse.
I just wanted to add that if you don't see Team -> Share project, it's likely you have to remove the project from the workspace before importing it back in. This is what happened to me, and I had to remove and readd it to the workspace for it to fix itself. (This happened when moving from dramatically different Eclipse versions + plugins using the same workspace.)
subclipse not showing "share project" option on project context menu in eclipse
I'm asked this question very frequently, if it's smart to use "Share project..." if a eclipse project has been disconnected from it SVN counterpart in the repository. So, I append my answer to this thread.
The SVN-Team option "Share project ..." is totally fine for projects that exist in SVN and in your Eclipse workspace, even if the Eclipse project is missing the hidden .svn configuration. You can still connect them. Eclipse SVN-implementation (Subclipse/Subversive) will verify if the provided SVN http(s) source is populated. If yes, all existing files will be copied and linked (checked out in SVN terms) to your very personal Eclipse workspace.
Word of caution:
Do a backup if you depend on you local files. The SVN implementation may vary its behaviour with every release.
If you have multiple projects encapsulated within each other, make sure you point the SVN path to the correct local path.
regards,
Feder
I came across the same issue. I checked out using Tortoise client and then tried to import the projects in Eclipse using import wizard. Eclipse did not recognize the svn location. I tried share option as mentioned in the above posts and it tried to commit these projects into SVN. But my issue was a version mismatch. I selected svn 1.8 version in eclipse (I was using 1.7 in eclipse and 1.8.8 in tortoise) and then re imported the projects. It resolved with no issues.
I am using Tortoise SVN client. You can alternativley check out the required project from SVN in some folder. You can see a .SVN folder inside the project. Copy the .SVN folder into the workspace folder. Now remove the project from eclipse and import the same again into eclipse. You can see now the project is now associated with svn
In case of SVN servers you have to creating a central repository with all projects. The contents of the repository can be uploaded with the Team/Share command; in case of the Subversive client it automatically runs a commit after the import, so you can upload your files.
This step cannot be circumvented in any way using a centralized version management system such as SVN.
Try this- Close the project then open it. It links with svn automatically,if project was checked out from valid svn path.