We have one large project in TFS. We currently have a few development groups: let's say for this example there is DevTeam1, DevTeam2, DevTeam3. Our current TFS project is laid out as follows (assume there are 100+ projects and about 10 DevTeams):
Master Project
|----- Common
|----- Project1
|----- Project2
|----- Project3
DevTeam1 works (makes changes to) on Project1, Project2, Project3 and Common (everything).
DevTeam2 works on Project1 only but would like read-only access to Common.
DevTeam3 works on Project1 & Project2 and would also like Read-Only access to Common.
Assuming that if a certain DevTeam is not working on a project and they shouldn't see the project at all, how would you set this up in TFS?
PS: We looked at setting up "Areas" but not clear how it all goes together after you set up an "Area" or whether this is the right path.
Follow the link on TWA for your project
http://servername:8080/tfs/collectionName/masterProjectName/_admin/_versioncontrol
then click the source control directories of the projects. On the right side you can add your teams and give the permissions seperately to the directories.
Related
I have a solution that includes multiple projects. I am making changes to the database that require a different schema and connection string while I'm working on this.
The Solution Explorer window looks like:
Solution
- BLL project
- Website project
- DAL project
- Console project
- Second website project
The actual directory structure actually looks like:
\Source\Workspaces\TeamName\BLL
\Source\Workspaces\TeamName\Website
\Source\Workspaces\TeamName\DAL
\Source\Workspaces\TeamName\Console
\Source\Workspaces\TeamName\SecondWebsite
\Source\Workspaces\TeamName\SolutionFiles
I can branch the individual projects that are being changed easily enough. It's at this point that I get stuck. Most of what I have found on SO and other online resources do not explain how to switch projects within a solution to the branched version.
Do I just need to create a new solution file for the branch and replace the projects within it with their branched versions?
Branch the entire TeamName directory including the solution and all projects.
I have a single Subversion repository containing all my Visual Studio projects. The repository is organized as follows:
repository/
branches/
project1_branch/
...
tags/
project1_tag/
...
trunk/
project1/
project2/
...
When I right-click on a particular solution I have open in Visual Studio 2010 and choose Subversion --> Branch Solution the default From Folder/URL is the trunk directory.
How can I create a branch of just the specific solution/project I am working on?
Thanks in advance for your help.
I wonder if AnkhSVN is assuming a slightly different repository folder structure. If I'm not mistaken, the "recommended" structure suggests that a trunk folder represent a given project's stable/current code base, rather than as a folder that aggregates multiple project's trunks. That is, I would expect to see a structure more like:
repository/
project1/
branches/
tags/
trunk/
project2/
branches/
tags/
trunk/
If you look at it from that perspective, the AnkhSVN behavior of branching from trunk makes a bit more sense - it just sees the subdirectories as part of the structure rooted at "trunk," but doesn't know or expect those are discrete projects' trunks.
I would respectfully suggest building a top-level project folder from the repository root for a "test" project, organized as illustrated above, then exercise it through AnkhSVN, and see if perhaps a going-forward change to your repository structure might serve you best over the long term.
AnkhSVN tries to guess in what place of the tree your project is rooted. In most cases this is the root of your working copy. (You didn't check out at the working copy root, didn't you?).
If you checkout ^/trunk (where ^ = your repository root), AnkhSVN will suggest merging that to ^/branches/something.
(Checking out at a different level can be very expensive and breaks the Subversion pattern where branching is cheap. When you update you would create all 'cheap' copies on your local machine)
If you want AnkhSVN to branch at a different level, you can set the project root via "File->Subversion->Change Source control". And then select the option on your solution.
I'm managing a mid-size project in VS2010 (and TFS2010). We have separate teams for different parts, and a team for a "common" part which will provide frameworks and such. Source structure:
Common
+--- CommonLibrary1
+--- CommonLibrary2
+--- etc.
Part1
Part2
etc.
Requirements:
A dev in the "Common" team should use Common.sln that contains only Common code
A dev in the "Part1" team should use part1.sln that contains part1. It references stuff from Common, and should be able to build that stuff (same for part2, etc.)
If a dev in the "Common" team create a new "CommonLibrary3" project, I only want to update Common.sln - I don't want to touch Part1.sln, etc.
TFS build should always build everything
Non-requirement:
TFS-build of just Part1. All of this is a single project, and is always released together.
Separate management of parts.
Sub-optimal solution I know of:
Add Common.sln to part1.sln - seems like VS just copies all project from Common.sln into part1.sln, so projects later addede to Common are not included.
Replace solution files with MSBuild target files - http://sedodream.com/2010/03/19/ReplacingSolutionFilesWithMSBuildFiles.aspx. I guess that would work, but I want the devs to update solutions from VS, not hand-edit MSBuild files.
The TFS Guide books I found calls this a "Partitioned Solution", but doesn't specify how to actually achieve it.
Any recommendations?
In TFS 2010 build definitions you can refer to:
Multiple source control folders to include in your build workspace
Multiple solutions files to build in your build process
So (if I understand your question correctly), regarding TFS team build you have no issues.
The only challenge you have left is that (maybe) on any development system of part1 or part2 developers, that developer should be able to also build the Common.sln. As long as that developer has read access to the common branch, the local workspace can contain both source code bases and both can be build by the developer.
So:
Common developer has RW access to Common, only R access to Part1 or Part2 (to test impact of changes),
Part1 developer has R access to Common, RW access to Part1 and no or R access to Part2,
Part2 developer has R access to Common, no or R access to Part1 and RW access to Part2
This should enable your scenarios.
I've got some questions and here's the scenario:
I've got one big Sitecore CMS website (Proj A) that has a ton of native dll's as well as custom ones that we've created to enhance funct on the site.
The custom dlls are generated by individual VS projects (Proj B, C & D) that we manually compile and then move the finished product (dll) to Proj A bin directory.
We currently have Proj A repositories for PROD, Integration, Public as well as every developer typically clones a copy of PROD to work features/fixes.
Proj B, C & D are not setup under version control as of yet because we havn't found a way to easily integrate it's release into Proj A.
Using the integration manager workflow, we let everyone do their feature/fix and then we merge it to an Integration repository. At this point we're ready todo the following:
Recompile Proj B, C, & D
Robocopy release files from each project to the Proj A bin folder
Recompile/build Proj A and deploy to Integration server.
Questions:
Would you include Proj B, C, & D in the directory structure of Proj A? If so, when compiling each project, would you make the release directory for the each project the Proj A Bin directory?
How/when would you automate the inclusion Proj B, C, & D "dlls" into Proj A bin directory.
Can you recommend a way that would streamline the integration of these files?
NOTE: I've researched Reps within Reps as well as submodules but not sure if i need just a hybrid of both.
Any recommendations would be greatly appreciated.
Thanks and have a nice nite.
foxtrotzulu
We have a similar situation with an ASP.NET Web application that depends upon other projects.
Our solution has been to create the Web application and each dependency as a separate VS solution in a separate repository, then define the repositories for B, C, D as submodules in the repository for A.
The VS solution for A includes the copies of the projects B, C, and D that are provided by the submodules, and these projects are project references in the project for A.
This solves 1 and 2 because you can just build project A in the normal way and B, C, and D will automatically be built from source and the DLLs copied into the build directory for A.
If you create a solution you can add your website/webproject and your other projects to this solution. if you then add references from the website/webproject to those "custom dlls" the dll's should get copied over (by default, otherwise there is an option for this iirc).
I would automate them if they were specific for Proj A, if they are things like internal APIs, utilities etc that all projects use, I wouldn't include them in the Proj A solution.
Not sure if I would recommend this way, but if you have the custom DLLs built somewhere automatically (using CruiseBuild or the like) and then committed to the repository you could add an External "update". But this could just as easily be a problem, if new changes would break Proj A often.
This is by no means a complete offer, but maybe a partial answer to your question.
Dont know if this helps anyone but just wanted to followup my own questions:
Questions:
Would you include Proj B, C, & D in the directory structure of Proj A? If so, when compiling each project, would you make the release directory for the each project the Proj A Bin directory?
We decided to keep proj A (Sitecore web) as a separate repository inside a Sitecore rCS folder.
This folder contains repositories and a DLLs folder:
dlls
dev1_PUBLIC
dev2_PUBLIC
dev3_PUBLIC
INTEGRATION_STAGING
PRODUCTION_STAGING
To start a feature/fix all developers install a vanilla Sitecore and do a PULL to update there local master from PRODUCTION_STAGING
Checkout a local feature branch, naming it according to ticket/project. Run local updateDll.bat to pull down updated dlls.
Do work, commit often, test and verify
PUSH local master
PUSH to "xxxx_PUBLIC".
Contact Integration manager so that he/she can PULL from public to INTEGRATION_STAGING.
IM pulls to Integration (QA), runs local updateDll.bat, notifies dev to go ahead and test integration to Sitecore or other project
If test is verified, IM will schedule PULL to PRODUCTION and run local updateDll,bat. If Production is good, IM will PULL changesback down to PRODUCTION_STAGING so that a fresh copy is ready.
We decided to have proj B, C and D (C# components) have their own repository per project inside a dotNetProjects folder.
Each project folder contains a number of repositories:
dev1_PUBLIC
dev2_PUBLIC
dev3_PUBLIC
INTEGRATION_STAGING
PRODUCTION_STAGING
To start a feature/fix all developers CLONE a copy of PRODUCTION_STAGING to there local pc.
Checkout a local feature branch, naming it according to ticket/project.
Verify output folder for project points to "releasedlls" folder in dotNetProjects projects. Do work, commit often, test, verify and build project. verify dll datetime stamp.
PUSH local master
PUSH to "xxxx_PUBLIC".
Contact Integration manager so that he/she can PULL from public to INTEGRATION_STAGING.
IM pulls to Integration (QA), runs local updateDll.bat, notifies dev to go ahead and test integration to Sitecore or other project
If test is verified, IM will schedule PULL to PRODUCTION and run local updateDll,bat. If Production is good, IM will PULL changesback down to PRODUCTION_STAGING so that a fresh copy is ready.
How/when would you automate the inclusion Proj B, C, & D "dlls" into Proj A bin directory?
Output folder for each project is set to dotNetProjects/releasedlls folder which is not a repository, just a folder to house dll related to SItecore.
Developers adding features/fix to sitecore must run updateDll.bat locally to get the newest version of the dll. Here is the simple script:
xcopy /E /Y "\\servername\dotNetProjects\ReleaseDlls\*.dll" C:\development\sitecore\WebSite\bin
NOTE:
Steps 4-8 are identical above, the
editor was giving me a headache so I
just left the redundancy.
With all the dlls involved, in regards to Sitecore, we still wanted to gitignore dlls because it could be a headache for our business users. So to maintain dlls as an ignored file our workaround is the quick fix above. This is not what we'd like it to be but if it
works for you, use it, if not, disregard.
I am adding my code to source control (SVN). I am trying to organize my projects and solutions to fit with the SVN best practise. I obviously don't want to add junk and stuff that changes for every user. What exactly does the MyProject folder contain. This seems to be something that Visual Studio creates and maintains. It seems to contain assembly and reference information. I assume that this should be under version control. I have looked at other question but no one has mentioned the MyProject folder.
Last Thing. I have two projects in my solution. One for the code and one for the unit tests. This creates a bit of a weird structure and naming problem for SVN. SVN best practise suggests
repo
|- Project
|-trunk
|-branches
|-tags
Which leaves me with
repo
|- Project X
|- trunk
|- Project X
|- Unit Tests
|-branches
|-tags
Now I have project X repeated in the repo structure. Not a train smash but it feels untidy. Is there a way to reconcile visual studio solution/project layout with the SVN repo layout. Should I just rather try to rename the either the project in visual studio or rename the lower Project X to source?
Or should I just live with it? Any suggestion would be most welcome.
The My Project folder definitely should be under version control.
From SVN's standpoint, your "project folder" should be the parent folder that contains My Project, along with bin, obj, your .sln file, etc.
This parent folder should also have svn:ignore set to the following:
bin
obj
*.user
*.suo
Furthermore, this "project folder" should be what goes into your trunk, branches, and tags directories.
Regarding your last question about the structure: I think it's fine that "Project X" is repeated in the structure. The first instance (above trunk, branches and tags) is the project name in a general manner - it doesn't necessarily have to be the name of your Visual Studio solution.
Under trunk you will have all the Visual Studio projects that are part of your solution. In a small project it might look like your example, but as the complexity increases you will probably split your codebase into several VS projects.
Example:
repo
|- Blog
|- trunk
|- Blog.Web
|- Blog.DomainModel
|- Blog.Tests
|- branches
|- tags
You can still put the project in.
As long as you filter out all the user settings with the svn:ignore property