Context: I'm currently working as an intern at a company which has made the move to TFS 2010 from VSS. TFS has been in use here for a couple of months now, but in the early period after the move some 'mistakes' were made in setting up the projects. After while the need for a custom team project template was recognized. The template has been developed and is now being introduced into the organisation. (small web development company, many small projects)
Question:
We're trying to migrate old projects to the new template by setting up new pojects with the custom template. We'd like to move the sources of the old projects into projects making use of the new template. The history of the sources should be preserved for support reasons. It is undesireable for the old projects to appear in the Team Collections' Team Projects list, so we'd like to hide them if deletion is not an option. (to reduce the garbage in the list)
I have some solutions on my mind to get the job done, but I'm unsure if they'll work out. (even after spending some time researching the issue on the web)
1: Doing a branch from the old project into the new and then deleting the old project. I think it should keep the history of the the old project has been deleted. Some people over here are very vocal about this not being the case causing some strife. Before pushing this option I'd like to be sure this will work
2: Hijack the migration tool to migrate sources between projects (possibly via via a temporary Team Collection). I have read this could be an option, but the details of how to execute such a move are still unclear to me. It seems this has a lot of caveats attached to it and can be cumbersome to execute. (I'm no superman when it come to these matters, but so is noone else over here)
The Migration guide seems to suggest that this might be possible, but I can't determine if this scenario is supported, and how to recover if things go wrong.
Maybe it is possible to set up the new projects and hide the old projects from the team collections' team projects list without deleting them? (I wonder if there is some kind of inactive setting for team projects, I can't seem to find any such option after exploring the tfsconfig tool of the admin console)
An explanation of how to best apporach this problem and possible solutions would be much appreaciated.
Doing a branch from the old project
into the new and then deleting the old
project. I think it should keep the
history of the the old project has
been deleted.
I'm pretty sure if the old team project is deleted, the part of history that is associated with that team project will also be gone, see here for more details. You can confirm this by doing a quick test move if you want.
Maybe it is possible to set up the new
projects and hide the old projects
from the team collections' team
projects list without deleting them?
You can mostly achieve this by denying read access (GenericRead) to most of the users on the old team projects. Of course for the Project Collection Administrators who have this permission by default on all the team projects, the old team projects still appear in the list for them.
Good luck!
There is no firm relationship between a team project and a particular part of the source control tree. Let's say you have a team project named "Mistake". You have source at "$/Mistake". You can now create a new team project named "Got It Right", and specify to use the sources at "$/Mistake".
Use the source control explorer to move a solution between projects. Here is how the projects and solutions appear before moving a solution.
The move selection is found by either
right-clicking the solution, choosing Move from the drop-down menu
Selecting Move from the Source Control menu found under File in the drop down menu
Related
We have been using Domino on a large project for years without any real source-control (other-than server backups). So, I was rather pleased when I noted the latest Designer 8.5.3 has potential integration with SVN.
I was unable get SVN working just by following the original instructions for as already noted on Stackoverflow the update sites have moved. The solution posted on OpenNTF, only half worked, with Domino still croaking at GEF, Mylyn and some other missing plugins. After finding and installing them, I still do not seem to have source-control integration.
What I have now is the ability to create on-disk projects but I do not seem to have any source-control features. I was expecting to see menu items for commit, update, revert …etc – is this how it works in Domino?
I can of course create a repository to commit the on-disk project to but I was hoping for integration inside of Domino. Whilst having years of experience in programming I’m a novice with Eclipse. I assume that I’ve done something wrong with installing the plugins? it was certainly a complicated process trying track down missing plugins.
Has anyone tried this recently and succeeded? What files do I need to install, setting tweak, …etc, to ensure this works? I’m happy to install my Designer fresh and follow a list of instructions.
Also, am I understanding how the integration works? Will I get command integration within Designer or do I have to work separately with the on-disk projects? I was really hoping for this be easy to integrate into normal workflow so I can convert the team to using it (adding too many extra or complicated steps is unlikely to create a conversion).
I posted a screenshot of my installed plugins in case this is helpful.
Mercurial? As an aside, has anyone used Mercurial instead of SVN with Designer? I would rather use Hg as I’m using this for related Dojo projects and will be easier for the team to use one system. However, I will settle for SVN as any source-control is better than non.
Update: This is answer is now out-of-date. It is useful in that it should point users in the right direction but it isn't really a working answer anymore. I no-longer develop on Lotus Notes so I cannot update it to a current solution.
I managed to figure this out eventually but will post the solution, just in case anyone else has the same trouble.
The answer by Per Henrik Lausten was very helpful as it showed me the route to follow through the menus. The main problem is that I'm not used to how Eclipse works so I didn't realise you had to go to the "Team" menu and "Share Project" after creating the on-disk project. When I did this I discovered that both SVN and CVS were already available.
I found that SVN did not like the file:// protocol (perhaps a windows issue?) Since, I could not arrange for an SVN server on our network, I decided to go down the Mercurial route. This was better for us as our other projects are stored in Mercurial.
Setting-up Mercurial with Lotus Designer 8.5.3:
In Domino preference (File -> Preferences), set: Enable Eclipse Plugins in the Domino Designer section to ticked.
Also in the preferences set: Use Binary DXL for source control operations to unticked (File -> Preferences, Domino Designer -> Source Control). Without this ticked I was not getting text for my Lotusscript agents and it would be difficult to compare changes.
Go to File -> Application -> Install:
Select Search for new features to install and click Next.
Click Add Remote Location button
Add the url: http://mercurialeclipse.eclipselabs.org.codespot.com/hg.wiki/update_site/stable/ and give it a suitable name
Once you've added this, ensure it is ticked in the location list and click Finish
Design will then search for updates and give you a list. Untick "Only show latest version of a feature per update site"
Tick MercurialEclipse 1.6 from MercurialEclipse Stable Releaes. I found that the latest version does not work, however a previous Stackoverflow conversation indicates that version 1.6 does work.
Click finish and allow it to install.
You will be asked to approve various plugins and then to restart.
MercurialEclipse, should now be installed!
To start using Mercurial with a Domino Application:
Right-click the application in the Applications tab, select: Team Development -> Set Up Source Control for this Application.
Give the project a name and choose a location for the project to be stored.
Designer will then do a DXL export of the database to your chosen location. A Navigator tab will appear next to Applications.
Right-click your new disk-project in the Navigator and select: Team -> Share Project...
Select Mercurial from the Repository types and allow Designer to create the repository.
You should now have access to various Mercurial functions via the Team menu. (You need to make your first commit.
When you make changes you want to commit to source-control, you need to:
Right-click the application and choose: Team Development -> Sync with on disk project...
Go to the Navigator tab and right-click your on-disk project, selecting team.
Most of the above steps should be obvious but decided to post full details in case anyone struggled like I did with Eclipse and how to use it properly. Once I figured it out, it really was quite easy.
Keith Strickland has created a series of blog posts on using source control with DDE. They might help you:
Keith Strickland: source control in DDE part
1: http://www.keithstric.com/A55BAC/keithstric.nsf/default.xsp?documentId=B236F39DEAF6C52F85257A72001157BF
Keith Strickland: source control in DDE part
2: http://www.keithstric.com/A55BAC/keithstric.nsf/default.xsp?documentId=B5D76A6DA163DCB585257A7C004802B6
Keith Strickland: source control in DDE part
3: http://www.keithstric.com/A55BAC/keithstric.nsf/default.xsp?documentId=C2C46D278948A24985257A7D0055D25E
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.
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.
My team is looking to migrate many of our tools (SCM, bug-tracking, builds, testing) to TFS. We're considering moving each system in stages. For example, move source control first, bug/feature tracking next, etc...
Since we have to choose a process template to use source control (or anything in TFS) how locked in are we with the decision? I'm looking to avoid having to create another project later (or is that not as bad as I think it would be?).
I know I can in theory customize everything the process template configures after the fact (right?), but how feasible is this in practice?
Here is how I see things happening:
We migrate our source code. We choose Microsoft's CMMI template.
We create a new work item (or check-in note) that is a simple link to our legacy bug tracking system.
We work for awhile.
We wait until the powers that be (we're a decent sized software company) to work out a new TFS development workflow. This may be a simple collection of new work items or an entirely new template that configures all sorts of stuff.
We try to migrate our TFS project to this new system without loosing our history.
Will we be sorry we didn't just wait until all these decisions were finalized before using TFS?
So, you are right to think about your process template as there is a certain amount of "lock-in" however it isn't too severe. It's like you are stuck to your process template with honey rather than super glue.
Personally, I would start with the MSF Agile template. It is much lighter weight and contains less work items - so you more likley to want to add things to it (very easy in TFS, very well supported) rather than take them away (more complicated and not entirely satisfactory).
However, if the power's that be decide to go down an uber process definition process and magically come up with a new process template in 12 months time that they want you to use then it isn't completely lost. If you find that you want to create a brand new Team project, as long as it is on that server (or Project Collection in TFS 2010) then you can either branch your code over to the new team project (which means that history is somewhat obscured in current versions of the TFS clients) or you can create a new Team Project with an empty folder for source control and then move the child folders over from the old team project to the new one. This will preserve history perfectly as TFS maintains history for moves on the same TFS instance. Your work items from before the move will be stuck over in the old process template though and you'll need to decide if you want to copy them or just leave them to get closed out naturally.
Obviously, by actually using TFS for 12 months on real projects, when the powers that be come knocking you are also going to be in a much better position to know what you want your shiny new process template to look like - and I've often found that this is an excercise that just never happens and most people are happy tinkering around the edges of MSF Agile or pick something more prescriptive like Scrum For Team System.
Hope that helps,
Martin.
I have a client who is using one TFS project just for source control only and now wants to manage work items in a totally different TFS project, using a different process template, and intends to link changesets to work items across TFS projects.
I know that this is possible in TFS, but don't know what the limitations or issues that come with this configuration. e.g Build Summaries, Reporting, etc.
I would prefer branching the code into a new TFS project and managing code and work items together in one project, but need to know how the above method stacks up.
It'll work - I've occasionally had to associate checkins with work items from other projects. I haven't noticed any issues with reports or the like, that said this seems like an overly complex arrangement with little benefit.
Seems like a strange set-up to me. While it will work, TFS is designed for the check-ins and work items to be in the same team project so you won't really get the full benefit of the TFS features. Does the client know that they can modify the process template of the existing team project or do what you say and branch or even just move the source into a new team project.
We used this model to allow us to have separate projects but against the same source branch. It worked for a while but once we started being more adventurous with branches the model broke down. So as others have noted, there's no reason why technically you can't do this, it's not standard.