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.
Related
I am scripting a mass rename of ~100 TFS 2018 U2 projects by using the REST api, as a setup event to the project deletion that will occur in 2 weeks.
So, I'm renaming ~100 projects from foobar to TODELETE-foobar.
The rename is going great using the PATCH against /_apis/projects/$($project)?api-version=4.1, but I'd like to be able to get rid of the automatically created alias that lets TFSCOLLECTIONURL/foobar redirect to TFSCOLLECTIONURL/TODELETE-foobar
Nobody should be using these old projects, and getting rid of the redirect will help me ensure that they're not - this helps me cover employees that ignore my notifications.
Thanks!
This is an X/Y problem. You have a problem:
People shouldn't be using legacy projects that are scheduled for deletion.
Your solution:
Break any existing links to the projects that shouldn't be in use.
However, as you're seeing, that's not an effective way to manage the problem, because people ignore or otherwise miss notifications.
The correct solution to your problem is a lot simpler and removes the possibility for someone to miss the memo that they shouldn't be using a project:
Make projects that shouldn't be used anymore read-only.
Bonus points: Put a link on the project's homepage via a README.md file that points to the place they should be working.
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've got a VS/TFS2010 project in which we use a generated file. Here's how it works:
There's a pre-build event that creates the file (foo.cs)
The file is included in the project.
The file is NEVER added to TFS version control.
It works great, except... People have an unfortunate habit of accidentally checking in the file. This, of course, breaks the system.
Are there any good ways to prevent this from happening? Can I at least set up some kind of watch mechanism to alert me if it does happen?
You'll need to install the Team Foundation Server Power Tools, which will include the "Forbidden Patterns" check-in policy. This will allow you to prohibit a file from being checked in based on regular expression applied to the server path.
This will allow you to simply add the full server path of the file you wish to ensure does not get added. For example:
^\$/TeamProject/Folder/foo\.cs$
I was researching this exact issue today and found this, which may be of some help: How to ignore files/directories in TFS for avoiding them to go to central source repository?
Not sure if 2010 has made this easier or not.
(Apologies, this should probably be a comment, but I don't think I have enough rep to comment.)
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).
Moving source control files to another project is easy but what is the best way to move Work Items (with history) to another TeamSystem project?
I have a number of projects that I actually want consolidate into one TeamSystem project so we have one central Sharepoint portal and to make reporting easier.
Ugh I used excel but lost the history. I found this link after
http://blogs.msdn.com/granth/archive/2008/06/26/how-to-move-work-items-between-team-projects.aspx
Good Luck