This may have been asked before but i was not able to address my needs in all previous posts (I've been searching it for couple of hours). All posts are so specific to its special needs. (I've been writing projects for couple of years but a newbie to TFS)
My Need Is:
I have one common helper project under default collection. (simple helper class and functions which helps me to avoid rewriting everything)
I am trying to use this helper project in every tfs project under different collections.
What is the best scenario to use?
Default Collection
-- HelperProj
Collection 1
-- Project 1
-- Project 2
Collection 2
-- Project 3
-- Project 4
Thanks in advance
Onur
Here is a link that may help you with your needs. Take a look at the work-space mapping and branching features to achieve what you need.
Code Sharing in Team Foundation Server
Organizing Your Server with Team Project Collections
My advice would be to use a single project in a single collection unless you have a compelling reason not to.
The reason is that although TFS looks in many ways like one large file-system, there are some things that don't work very well across project and collection boundaries. In my experience putting code into different projects/collections only works cleanly if there isn't (and never will be) a dependency between the lumps of code, so you can work on a single project/collection in isolation.
Our company started off with a TFS project for each "real" project, but we constantly ran up against problems due to this until we reorganised our entire codebase into one collection containing 3 projects, for Documents, Assets, and Code (three distinct areas with no interdependencies)
Within a project you can still organise the code into folders so IMO there really isn't much point in using different projects and collections unless you have very different access/security requirements for the different codebases (which is unlikely if they have no dependencies).
The other approach is to use the 3 collections you describe, but eliminate the "live" dependencies between them by pre-building the libraries in DefaultCollection to provide a shared repository of binaries that you can link to from the code in the other collections. This could also help with versioning, where the library code could be updated but the binary not merged into one of your other collections immediately, allowing the teams that work on the other collections to pull in updates to the library code only when it suits them. This can help stop problems being caused by changes for team A being immediately used by team B.
Related
Scenario. A team has 5 developers and all developers are working independantly on 4 different projects. iOS / OS X. A library has been created which encompasses multiple subclasses, categories and so on for reuse. Each member in this team needs to be able to use this library for each project. The library itself has it's own git repo. When someone makes a change to the library it is handled the same way a standard project is handled and a merge is completed.
Problem I see with this approach...
1. This doesn't seem like common practice for a proper Xcode / Git workflow and I feel a framework or similar would be a better tactic.
2. Although this is great for sharing I can also see this as an issue since one issue with the library will break all existing projects.
3. Adding classes to this library requires each project to be updated to include the new headers.
4. Directory structure can differ on each machine therefore a simple clone of a repo will not work as expected without folder modification.
What is the best way to handle your own library of classes in a Xcode / team environment of multiple users?
If you must have a single library for all this - you can go two ways:
Nobody changes the library, the library is as it is and everyone just pulls it down and then makes changes in their code to make-up for the shortcomings they find in the library.
Everyone changes the library, but the project has A master branch, a stage branch, and a branch for every single project associated with it. Devs change and update their respective project branch, and another person (perhaps one of the project devs maintains the flow from the multipe dev to the single stage to the single master branch). With this approach, it requires much more management but you can slowly improve the main library without potentially breaking other projects as everyone has their own specific know-to-work version of the library in a branch specific to their project, only re-syncing with the master when safe.
Suppose that I have similar apps that share a lot of code. Paid and free versions, whitelabeled apps for different client companies, that sort of thing. In general, the differences between apps would be relatively minor; some images would be different, some text would be different, some kind of flag values would be different--the shared code would check for those values and change behavior accordingly.
A nice bonus, but not essential, would be for each app to be able to add code to extend/override some of the shared code.
I have read of several different approaches--there may be more I haven't considered.
one .framework file used in many repositories
I don't know much about this, but I gather it would be like making a JAR in Java; compiling code to be used as-is by other programs. This might work well for a general-purpose library to be used by many different kinds of apps, but as far as I know it is not suitable for the above purpose (correct me if I am wrong).
one repository, one project, multiple targets
From what I understand, this is most popular for the "one app with paid and free versions" situation, where there is only a very tiny difference between the apps produced--they are essentially the same app.
However, I don't know how flexible this is in terms of changes between the different targets. I gather it's possible to set a different .plist file for each target, and that can result in different text, flags or (through some kind of awkward workaround) different images for the apps, and that is it, correct?
I also feel uncomfortable with using one repository for multiple projects, but when they are this closely related, perhaps it doesn't matter.
one repository, one workspace, multiple projects
Although this seems to be a cleaner division among the projects, I'm not sure if there's a good way to separate resources for the different projects. The most logical solution would be to have different folders for resources for different projects, and include them in the workspace with only one target each--but I can't seem to do that. Apart from that, there seems to be little difference between this and the previous option.
So, what is the right way to make shared code for multiple projects that only have a few differences from one another? Is it one of the above methods (and if so, how do you do it?) or is it something different?
I prefer to have separate projects and a separate folder for each project.
You then bring each shared unit into the project as you need it. Shared features (most features) go in the shared units.
If you want to upgrade one project with the latest Rest.h and Rest.m, you bring it into the project folder. Maybe on the next project, you're not ready to upgrade to the latest.
You will have duplicate files (one for each project), but it allows you to update, test, and finely control each project atomically.
One repository or not, it doesn't matter, since the projects will have different folders and the shared files will be duplicated (possibly different versions in each, with the trunk having the latest shared files).
On a side note, I hope these many similar apps don't all end up in the App Store.
We are trying to move from our current source control to a TFS as a source control. Right now we have all projects as project references. Our organization is small and we have a lot of common projects that are used by various development teams and all teams update these projects as needed. When we migrate to TFS we are looking to use DLL references for these projects but I am wondering if that would make branching impossible and I am also concerned about is there a benefit of having DLL references to the projects that all teams in the company need to make changes to.
Could you please suggest, given our scenario, if it would be good idea to have DLL references to our common projects or to have project references. Any links to suggested readings would also be helpful.
Depends on the size of these projects and how often you make changes there, dll references are generaly used for 3rd party libs, if you own common projects are not often changed and/or changed by small/dedicated group of ppl then it may be benificial to treat them the same way, otherwise its better to have project references.
Im not sure why dll references would present branching problems ? You branch them just like any other code or project, if they dont differ per branch you can save yourself time on updates and keep them outside branch in single location.
In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).
All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:
Is it possible / feasible to use one of the existing projects as the target project for the other three?
How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
Today we have work item links from one team projects into another - how do we keep these links when merging?
What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?
Thanks for your help!
Unfortunately, TFS 2010 doesn't allow you to merge team projects.
Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(
When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.
Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)
Some additional thoughts for each of your original questions:
Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.
It's not the best story for you but hopefully it will help your planning out some!
Is there any guidance about workspace naming and workspace mapping in TFS (2010) ?
I'm not aware of any specific guidance on this, but after a couple years, we've primarily settled on a single workspace mapped to root $/. We've been operating like this for probably a year with 80+ developers, and haven't seen much of an issue.
In my opinion, this is valid, as is the idea of one workspace per Team Project, as long as you don't have a whole lot of Team Projects to deal with.
For the Mapping aspect there is nothing to add to the first answer as- "Map to root $/" approach seems to be the most used.
However, the MSDN Basic Guidelines for Creating a Workspace seem to suggest a different approach:
If you want to work with files from a single folder, map to one that is as close to the level of the team project collection as you can but no closer than you must. That way, you will get all the files that you need without getting many that you do not need.
I would tend to say that workspace naming conventions are only helpful if you need to create multiple workspaces on the same workstation. That would be the case if you need to work on different codebases hosted in different team collections or on different branches of the same codebase.
Like mentioned in previous feedback, I did not find a reference specifically addressing the topic, but the "Naming your TFS workspace" article from the old TeamPrise Explorer documentation has some good suggestions:
(...) give workspaces a name that includes your machine name, your deliverable, and branch if applicable.
"Deliverable" is organization specific, but can likely be related to a single team project so that the name of the project could be used to correlate the workspace to it (rather than using a different name for essentially the same thing).