I'm trying to wrap my head around the TFS folder concept. I've found a lot of explanations of how to create them, how to convert them to branches, how to move folders around, etc. etc. but absolutely nothing that explains what a folder is. When would I choose a branch over a folder? What are the advantages/disadvantages of one over the other?
Any references or guidance would be greatly appreciated.
A folder is just an arbitrary hierarchal organization method. It's no different than your file system. A branch is a type of folder with special properties to support concurrent development.
Related
I have very small and quick question.
Is it neceseary for all the developers that are participating in writing a shared project through TFS, to have that project placed on the same path on each of their machines?
So for example if I have a project "TEST", and I place it in C:/Projects/, does everybody who will be mapping this project from TFS have to place it under the same path, or they can put it in different paths as long as the subfolders of the TEST project are then the same as they are at Source Control of TFS? So in our example, if someone will map that project in C:\Documents\Users\MyUser\VS2010Projects\, will it project some problem with check ins, and getting latest version(by others)?
My small project team has starnge issues lately, and I never thought it can be a problem, but I'm starting to think so and I would appriciate some response from someone who has some expierience in that field.
Lucas
If you have set up your source control paths & your solutions properly this shouldn't be an issue. Let's say that you have a project1 that uses a lib named core. If you set this as follows users can map wherever they want in their local PCs in the content under $/.../Program1:
$/../Project1
/SharedSources
/Lib_branch
Lib.csproj
/Sources
/Project1A
Project1A.csproj
/Project1B
Project1B.csproj
Project1.sln
If you are set as follows:
$/../Lib
Lib.csproj
$/../Project1
/Project1A
Project1A.csproj
/Project1B
Project1B.csproj
Project1.sln
things are more challenging, since - in order for the solution to work in each workstation - both$/../Lib & $/../Project1 have to be mapped in the same level.
I am using TFS. I created a branch for one of folder/project in my solution. Now I have two branches (folders) with the same code. But my solution pointed only one (parent folder-branch. But from now I want to work with newly create son folder-branch.
I found two ways:
Redesign my solution to point newly created son folder-branch. My solution includes near 200 projects and this way will take a lot of job.
Don't change solution but change workspace by clocking parent folder-branch and mapping newly created to old place. This way also very complicated.
May be somebody will give me advise to another way. Easy way of using the same solution for several branches.
Typically you will want to branch and merge at the solution level, not the project level.
I have been following the ALM Rangers' guidance on branching, using their "basic" branching structure:
Created a "$/TP/Main" folder
Converted it to a branch
Created a "$/TP/Dev" folder
Branched from Main into "$/TP/Dev/Dev"
Created a "$/TP/Release" folder
Branched from Main into "$/TP/Release/Release"
My normal workspace maps from "$/TP/Dev/Dev" to my local "C:\TP" folder. That's where I do my day to day work, and the solution files are under there. When I merge forward to Main, and then to Release, the solution naturally comes with it.
The solution doesn't refer to any branch. It contains references relative to the disk location, so it all works in any branch or any machine.
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).
we have a solution with multiple projects that is being developed by a team of developers. Project paths in the solution file checked in initially contains the path that are specific to that developer. Now when another dev gets latest of the solution, some of the projects won't load as the path differs.
What's a better way to manage this ?
TIA
When using VSS, I usually have each developer use a local copy of the solution that isn't kept in source control.
The downside is you have to create a new solution from scratch (or use a template from someone else) for each developer that comes on board, but it does address the problem you're seeing.
The simplest way is to dictate where projects/solutions are stored, for example, ensure/insist that everyone stores their working directories rooted at C:\VSS. That ensures that all paths are consistent between developers and stops things breaking.
Is it just in csproj files and the solution file or are there other files or locations where information is stored? What are those vssscc files doing?
TFS source control generally does not care how the content put in it is stored or structured. The .vssscc files are just a hold-over from the previous Visual Studio integration, and are only used by TFS to list file exclusions from source control (as far as I know, anyway...there could be undocumented uses as well.) Your solution and project structure is defined by your solution and project files. TFS Source control simply tracks the different versions of any file put in it, and provides ways to find and analyze that version data.
JRista's answer is pretty close. I'm not aware of any uses for the .vssscc file other than exclusions. Even within the .sln/.csproj files, there are no explicit bindings, just a bunch of "SAK" entries that tell VS not to do anything special. In the end, the layout of the projects on disk is determined by workspace mappings; the structure of the solution itself is determined by the paths in the .sln file.
Obviously the two need to match. If you have nonstandard workspace mappings, some projects may not load. If some of the paths referred to in the .sln are not mapped at all, VS will create explicit mappings during Add To SCC and Open From SCC operations. This can be problematic -- people who don't map their code correctly in the first place often have unusual relative paths between their projects that can't be easily replicated by people trying to Get their code from source control.