Our project is using TFS for both source code and all project requirements, design and management documents. We have set up numerous TFS groups to control read/write access for our various project roles. We have been having a lot of problems with novice business analyst users attempting to add documents from outside the local folder areas for which they have write access priveledges in the corresponding server folder areas. TFS responds to these attempts with varying cryptic error messages that has led us to spend time verifying and changing our TFS group setup and folder permissions only to find out later it was "operator error".
I am always apologizing to these users because in my opinion and experience it should not matter where the documents come from, only where they are going (to live in the SCS). These source docs sometimes come from shared folders, My Docs, USB drives, etc.
Why does TFS force this restriction on the location of source documents being added Yes, this can be overcome with training and practices. But this detracts from usability and is one more (unecessary ) deviation from how we have used VSS all these years. We are in a precarious position using TFS B3R for our project when we see these kind of problems (me finding out in a team lead meeting that users are getting bad error messages and not being able to add documents for three days running). We were trying to WSS for these user's documents but that had a whole other suite of issues. Please explain this TFS behavior and whether you can change this in future versions. Thx.
TFS Mapped Folders
renching
Fred Krusemark
Sounds like you need to create a few more working folder mappings to accomodate your existing file structure. For example:
$/TeamProject/designdocs/feature1 c:\path\to\my\documents
$/TeamProject/designdocs/feature2 c:\wherever\these\are\stored
$/TeamProject/designdocs/feature3 c:\yet\another\local\path
Then you can grant the correct permissions to $/TeamProject/designdocs and let permission inheritance do the rest.
Once you have a workspace set up in a way that works for you, other people can use it as a template:
tf workspace /new XXX /template:KnownGoodWS;youralias
SHutch
Thanks for the idea but that does not address my issue. Are you familiar with SourceSafe To add a document to SourceSafe you do not have to create a working folder for mapping the source location of the document. The source document could be coming from anywhere, all kinds of folders on my machine or elsewhere (code module in a downloads folder, share folder someone created just to send me a file, in a one-time decompressed temp folder, etc.). The tool does not care where the file came from, only where it is going. Of course I have to have permission to add files to the target location (in SCC) and that is it.
I cannot anticipate all the places a user might store or receive files so that I can configure "standard" multiple workspaces. Nor do I want them even having to deal with setting these up and managing these workspaces.
Why does TFS care where the new document is coming from Why do I have to tell it in advance where I will let that happen from
As far as workspaces I prefer to map just one at the root of my project tree ($\ProjectName = C:\ProjectName) for each project/machine combination and let everything inherit from there. Setting up multiple working folders in for the same project tree in SourceSafe was often a sure way to get unpredictable and sometimes conflicting results.
The bottom line is that I am hearing that TFSVC is difficult to use from these users. I agree - more steps to simply add a file and greater possibility of a problem given that this operation makes no sense. They forget they have to add from a mapped folder because they should not have to.
Amandeep Mann
Yes, we did. SharePoint lacks the rigor of a true document management or version control system. I have a long list of things wrong with it - at least using the standard UI (can't move file without losing history, no labeling, no tree view...). It is not a credible tool for managing critical project documents.
Scott VanDelinder
If the users are trying to copy files from outside of the mapped folder(s) directly into the SCM, it sounds like they're viewing the SCM as their working folder.
Even for Team Explorer with projects, the actual working folder appears to be the user's mapped folder ... not the SCM. Sure, the server becomes the authority, but shouldn't the organization start at the client (...and then be managed by the server)
Z Z
[Hind-sight: when I first posted this one, it sounded good; but on review, it doesn't. I didn't mean to imply that the user's directory would be the authority on the file ... the SCM should definately be the authority on the file. I was trying to refer to where the user uses the file.]
[ ... content retracted per inaccurate ... ]
Carlh62
I'm not sure I agree with Andrew's conception of SCM. For example, the Source Control Explorer we ship with TFS is always a server-centric view of the repository; you cannot configure it to mirror your on-disk file structure. Feel free to think of local files as "home" if it's helpful to you, but that model is not a major guiding factor in our designs.
hsiceo: I agree there should be easier ways to add a file that's outside your current mappings. Some parts of TFS already support this -- e.g. the Add Solution/Project To SCC feature examines the solution/project, and if any of its constituents aren't mapped, it will create the necessary mapping(s) for you. Unfortunately the regular Add dialog isn't nearly as intelligent. I'm confident we'll improve this experience in a future version.
Kaniri
OK, I see what's alarming about the way I said it: it makes it sounds like the users' folders would be the authority on what the file is and should be. Sorry about that...not what I meant to imply.
Yes, the SCM should be the authority. ...the place you go to get the reliable copy of the file and the central repository of holding file information.
But the users' working location need not be the SCM. As far as the users' work practices, the place they see the file as being available to them probably should be their working location. Then, they would copy the file into their location and add it to the source control from there....instead of expecting it to go directly into the SCM from anywhere. That should be more structured overall ... and on both the user and SCM sides.
...hope I managed to say it better this time.
isha_2
Chavdar Angelov
Tesic Goran