We're using eclipse and svn. We keep the .project file in version control.
The problem is, if you have more than one checked-out project (e.g. a trunk checkout and a feature branch) and would like them both to be available in Eclipse, you lose, because the .project files are identical and therefore can't both be imported into Eclipse.
What's the right way to deal with this? (I'm mostly having to deal with this in TI's Code Composer v4 which uses an older version of eclipse, but I'm also going to need to do this in the regular Eclipse)
I recommend setting up separate workspaces for working on multiple branches. It is possible to do it all in one workspaces, but it gets awkward in a hurry. Depending on which tooling you use, you may need to close projects from branches you are currently not working on to keep them from interfering.
Since Eclipse3.3, you find bugs like:
Bug 218973
[Import/Export] Import existing projects wizard: can't import two version of same project
Bug 110135
[Import/Export] Import existing projects wizards: enhancements for duplicate projects
Both bugs illustrates that this issue hasn't been fixed yet.
Separate workspaces (like Konstantin advices in his answer) is the best option.
Modifying the .project as described in this thread is not very practical.
I think modifying the .project is a solution if it already checked out.
Another solution is during checkout to define a different name to the project.
Third solution, and the one I use is changing the project name on the source-control when creating a branch.
I also prefer one workspace so that all my preferences are correct and coherent.
I use working sets to separate branches. In the past I was closing and reopening the projects of branches, but window working set is a better approach and most views support it quite good.
Related
At my workplace, I have managed to install and use locally Tortoise svn, to easier trak the implementation of the tools. For the new projects, it's easy because I start from scratch with the version control.
Now, for the past projects, I have copied the entire folder to keep a versioning.
It looks like this:
TempProject 20.07.2017
TempProject 21.07.2017
TempProject 22.07.2017
....
Is there a possibility to integrate all this changes with Tortoise?
Meaning , I want to have a base, than commits, for each version
Thank you...
I have managed to solve it.
I copied, one by one, the content from each folder (TempProject 22.07.2017 etc.) into my working copy folder, then I opened the project and committed the changes.
Maybe it's not the most efficient method, but at least it wasn't very complicated
How do I have a Project Explorer's Working Set be built automatically from the contents of .gitignore, and then kept in sync with .gitignore?
I am working on a C++ AutoTools project which, as it is common for AutoTools projects, generates quite a lot of files during the build stage. I do have them .gitignored already. Now I'm trying Eclipse on that project, and found that I'd have to carefully pick files to ignore again.
You cannot. This feature does not exist.
The working sets functionality was implemented a long time before GIT appeared, and it was a method for removing clutter in large projects, and what is important, it was was a method that resided in the UI domain.
In fact, A working set extension point documentation shows it is possible to create a self-updating working set, and the search over the egit codebase returns no results.
As I have said, this feature is not implemented.
However, you can create your own plugin that will do what you want. It is not very complicated, and should not take more than a day or two. Or just open a feature request in the Eclipse bugzilla.
As for your underlying problem, you could try using the derived resources mechanism. It was added to make possible to prevent team providers (CVS/GIT) from managing files that are a result of a build.
Just a word of warning - GIT won't allow you to ignore further changes to any resource already under its control.
I am working on several projects in Eclipse. The projects are checked out from an SVN repository. The projects also depend on each other. Currently, if I want to commit them, I have to mark each project and then call Team -> Commit.
Is it possible to commit everything without selecting particular projects? That's quite annoying. It is especially difficult to remember which projects were changed today and which were not. I tried doing this with working sets but I do not see any option of committing them.
Any ideas?
You can only commit them together if they are all part of the same working copy. If you checked each project out individually via Eclipse, this will not be the case.
Unless there's very tight coupling between the projects, you normally should not be committing multiple projects at once. It's not about making things less convenient to you, but about making your commits smaller, self-contained "units".
I already have a repository with the classical structure
/branches
/current
/beta
/tags
/1.0
/2.0
/trunk
I would like to switch from my current editor to Eclipse but how many projects should I create ?
One for the whole repository ?
But the auto-completion will find multiple occurrences in the /trunk or /branches/* folders.
One in /trunk and one in each /branches/* ?
In that case how can I keep the hierarchical structure of the repository in my workspace ? Is there an other solution than :
/workspace/trunk
/workspace/beta
/workspace/current
Thanks.
I suggest having a separate eclipse project for the trunk and each of the branches.
I found it's much easier to merge & tag when the branches are separated. Also, updating a single project will take longer than having separated projects as you will have to checkout the new tags you're creating each time.
Another note is that Eclipse is java based. Checking out the entire codebase as a single project will significantly effect your system performance. When the projects are separated, you can just close the branches you're not working.
#aporat has good advice, though sometimes switching workspaces is pretty slow. I tend to check out multiple branches in the same workspace, overriding he name in te .project file at checkout- usually by appending the branch name.
Be sure to close any copies you're not actively working on- will save resources on your workstation.
I use a mix of thi approach and having 3 to 5 workspaces.
In VS, it's simple. Everything the project needs is stored in the project folder and all VS settings are stored in one place. Eclipse, however, stores Eclipse settings with the project and keeps a .metadata at the workspace level which is needed to detect the projects in the workspace. Thus, I can't simply branch a project and then open it in Eclipse. I need to set up a workspace, branch it into that workspace, copy over all my workspace settings (settings import/export doesn't even work right in Eclipse) so I have the same Eclipse settings, then do some kind of import to get the project in the workspace. This is what I generally refer to as a pain in the freaking neck, and it causes me to not branch any Java projects and to keep them all in one folder. This is also a pain.
Is there any way I can get a setup where I can just branch a project and open it in Eclipse, while maintaining the same Eclipse settings?
UPDATE: The current state of the question is expressed by the comment to soru's post.
Pretty sure you want to:
Keep the same workspace for all projects (or maybe a few, at the level of say 'hobby' and 'work').
switch between different branches in the same project by using the features of your version control tool/plugin
if you want to work on multiple branches at the same time, just create two projects, and manage them both as above.
if you want to temporarily hide the inactive version, use the 'working set' feature.
The main limitation is that you might want to have projects with the same name, but you can't. So sometimes you have to make up a project name different from the underlying folder name.
In general, mapping between VS and Eclipse:
Installation <-> workspace
Solution <-> working set
Project <-> project or folder or VC system branch or working set node
Refs:
VS object model
using working sets in Eclipse
working with branches in subclipe
Well, I'm not a fan of keeping any IDE specific settings in the repo, but when I do I keep only .project, .classpath and .settings.
You can also keep you settings at the workspace level (Windows->Preferences),and not on the project level (Project->Properties).
Also why do you create a seperate workspace for branches? You can keep it in one workspace, no need to create another one.
You could also use "switch" in subversion (I don't know if that's what you are using, but other revision systems should have something similar) and go to the branch you have created.
(of course if you wan to work concurrently on more than one branch then it doesn't help)
I can't speak to the Eclispe problem, as i'm only a n00b user, but I can speak to the secondary question.
I've been working in systems for a number of years that ended up needing to have various branches of the same code done for a variety of reasons.
One of the best reasons for keeping specific settings in project-specific locations is that so the various compiler / sdk / etc. settings & files can be specific per-branch and not collide between branches.
This allows, for example, for the work to upgrade a code set to a newer sdk/compiler to be done without impacting the ability to work on the existing "main line" code set with the previous sdk/compiler should the need arise.
In my experience in the computer game industry as a core technology wog, this happens a LOT.
I'm sure the same situations occur outside the computer game industry, maybe just not at the same pace.