Is it possible to have 1 workspace which contains different branched copies of the same project? Say I have Project1, and it is in this structure:
/trunk/Project1
/branches/1/Project1
/branches/2/Project1
Can I have 3 instances of Project 1 in the same workspace, where each eclipse project points to either the trunk or one of any branches? Basically I am just wondering if I have to avoid creating a new workspace for each branch.
Yeah you can. Simply right click the desired project you wanna checkout in the svn repository view and select Find/Check Out As... and give the project a unique name.
Actually, I just had to switch to a branch from the trunk for ~30 projects and found that Eclipse is very smart and allows you to do the switch in a single operation.
Select all projects
click Team → Switch to another branch/tag/revision
What it does, it takes the base SVN URL for all of these projects and allows you to change it. So, in my case the common URL for them was ..../trunk and it was enough to change it to .../branches/mybranch.
This thread is a little old, but I thought I'd throw this out, looking for a solution myself. I didn't find a way to have the same project name. But, if you import as a Maven project, there's a dialog that makes it easy to template project names for multi-module projects. I put a screen shot here.
Related
I have different projects in Eclipse linked to them and it's common for me to create a branch for a funcionality that affects all or part of them, is there a way to switch multiple projects to the their branch with the same name?
I see that if you select multiple projects and you right click on them you get this menu:
but even if they both have a branch with the same name it doesnt appear there.
Any idea?
I'm a self-confessed tfs newbie using VS2010 with team explorer. My application uses version control. I wish to rename my current project ProjectA to something else like ProjectA_01. Then after I've made my architecture changes on a new VS2010 solution I wish to check in the new project as ProjectA. A list of steps would be helpful.
Thanks
I'm pretty sure you can't rename a project in TFS. You could create a new project named ProjectA_01 if you wish, but from the sound of what you are trying to accomplish, I think what you want is to work with branches.
Essentially, you put all of your code in a folder under your project. So, on your hard drive it would look something like this:
C:\tfs folder\ProjectA\Main
All of your source code goes in the Main folder. Then in the Source Control Explorer window in Visual Studio, right click on the Main folder and select Branching and Merging -> Convert to Branch. This is your Main branch (or trunk) and you could use it for code that is ready for beta testing or a product release.
Once you created the main branch, you can right click on the branch again and select Branching and Merging -> Branch. At that point, you can name it ProjectA_01 or whatever you wish. Typically this would be your development branch where you do the bulk of your development.
After you make all of your changes in the ProjectA_01 branch and check in all of your code, you can right click on the ProjectA_01 branch once more and select Branching and Merging -> Merge, which will move all of your changes back to the Main branch (which would signify it is ready for user testing or release).
"Hawkke" is correct in that you cannot rename a team project. If you want this feature, you can vote for it here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2037605-rename-project-in-tfs. It is currently the #1 voted feature for TFS at this time.
I'm actually having a hard time understanding if you are talking about renaming a TFS team project or if you are talking about renaming a Visual Studio project. Unfortunately they are named the same.
However, usually team projects are very large and you would have lots of different product families, products, and ultimately Visual Studio solutions & projects in the same team project. You can create subfolders, including maybe even an "Archive" folder in this case, inside of the team project to organize your source code better.
Let us know if we aren't understanding your question though.
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.
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.
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.