I am looking for some ideas and suggestions on how to implement a class hierarchy type of structure of VS projects in TFS.
Specifically, I want to have a "base" project which will contain all the common functionality the rest of the projects will inherit. When the changes are needed in the "base" project it should be relatively easy to propagate these changes to the rest of the projects which are based on this "base" project.
The obvious approach is to branch other projects from this "base" project and merge up the tree from this root project when there are changes but I've never tried that before and would like to hear from someone who attempted something like this before or has extensive enough experience with TFS to be able to point to inherent issues or pitfalls of such idea...
The projects in source control is actually folders. So your question is somehow the same as how to structure your folders in TFS.
Your base project is the some concept of main in branch which is root folder that acts as a container folder for your main source tree, together with accompanying project artifacts such as design documentation, scripts, and test cases. The Main folder also usually contains your Visual Studio Solution (.sln) files.
In TFS you could convert a folder to a branch.Then you just need to branch your base project to other projects. After have a branching relationship, you will be able to merge changes between the 2 branches. Besides you could also use branches to accomplish the following goals:
Manage concurrent work by multiple teams on the same codebase
Isolate risks that are introduced by different sets of changes to the codebase
Take snapshots and then support subsequent isolated changes (for example, to create a release branch)
Although you can still branch and merge among folders, the best practice for your team is to branch and merge only among branches.
When you perform branch operations, branches have important advantages over folders. Branches support version control features that provide extra visibility into your branch structure and into where your changesets have merged. (For more information, see these wonderful links: Visual Studio TFS Branching Guide)
For inherent issues or pitfalls of such idea, one thing is you might have to resolve conflicts when you get, check in, merge, or unshelve. Another thing is permission. It's better to avoid everyone have permission to merge changes from the “derived” projects back to the "base" project.
Besides you can create multiple teams in the same Team Project and you can nest them to facilitate hierarchy. If you are interested, you could check this blog which shows how to configure that.
Related
I have a class library project to be shared by two different solutions in Visual Studio 2017. The solutions are mapped in two different workspaces. I cannot find a way to get the shared project under source control in both solutions. Any suggestions?
I'm assuming that you have two separate Team Projects, each with its own TFVC repository. Underneath one of those Team Projects (say, TPA), you have a common library that you'd like to share with a solution located in Team Project B (TPB).
You can't do what you're asking to do -- even if you could do it, you shouldn't. You don't want to fork the source code and maintain two copies of it. What you want to do is one of the following:
Map a single workspace containing all of the Team Projects and use relative
paths for references. This isn't great, ideally each Team Project is considered a totally separate entity.
Put everything in a single Team Project and maintain a single workspace for everything.
Turn the shared component into a NuGet package and use a Package Management feed. Each consumer of the shared component can then reference a common NuGet package.
I'd say #1 is already excluded as an option. Each Team Project should be an independent entity with nothing shared between it. Since you have things shared, you've chosen the wrong organizational structure. Stop using multiple team projects.
Option 2 is okay, but it's a little bit clunkier.
Option 3 is the preferred, modern way of managing cross-project dependencies. I'd strongly recommend looking into implementing this pattern. If you adopt this pattern, maintaining multiple team projects becomes acceptable again -- you have one Team Project that acts as a publisher of shared components, and another that acts as a consumer. That's sufficiently isolated to consider them independent of one another, and thus an acceptable candidate for multiple Team Projects.
It's worth noting that the modern thought among most experts in this area is that maintaining a single Team Project for all related applications is the correct approach. I've seen teams with hundreds of members and dozens of applications using a single properly organized Team Project with no problems.
While I agree with Daniel on the fact that this is probably a bad idea and that there are alternatives, it's perfectly possible; there's one restriction though: each workspace must have its own copy of the shared project on your hard drive, they can share the remote copy on the server. This si very similar to a distributed source control model and can work just fine.
To make this work, first create one workspace and map the folders locally:
Workspace 1
$/Common/ => c:\src\1stProject\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Then create a second workspace:
Workspace 2
$/Common/ => c:\src\2ndProject\Shared
$/ProjectB/Solution => c:\src\2ndProject\SolutionB
This way both projects share the same server location and changes made to Shared will directly impact both SolutionA and SolutionB. Locally though, each solution will have its own local pending changes etc.
This solution will work as long as both Team Projects are in the same TFS Project Collection.
The only limitation is that these projects can't be placed in a subfolder of each other, so you can't do this:
Workspace 1
$/Common/ => c:\src\1stProject\SolutionA\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Nor can both workspaces map to the same local folder:
Workspace 1
$/Common/ => c:\src\Shared
$/ProjectA/Solution => c:\src\1stProject\SolutionA
Workspace 2
$/Common/ => c:\src\Shared
$/ProjectB/Solution => c:\src\1stProject\SolutionB
Alternatives
Nuget
Instead of using shared sources directly, add a NuSpec to the Common project and build & publish the NuGet package to the VSTS package management feed of the VSTS account. Add a NuGet reference to SolutionA and to SolutionB. That way the binaries of Common are shared among SolutionA and SolutionB, but common is maintained independently. This way it's also easier to update SolutionA at a different cadence than SolutionB (this is also the biggest pitfall for this solution).
Git & Submodules/Subtrees
Convert the TFVC repositories to Git repositories. That way you can use Subtree or Submodules to reference Common directly from the SolutionA repository and the SolutionB repository.
MonoRepo/One Project To Rule Them All
Merge all your TFVC repositories into a single TFVC repository, that way both projects can easily live inside the same workspace. Technically this isn't needed to put both projects in the same workspace, but it is easier. It results in a very similar solution as described above:
Workspace Single
$/Project/Shared => c:\src\Shared
$/Project/SolutionA => c:\src\1stProject\SolutionA
$/Project/SolutionB => c:\src\2ndProject\SolutionB
Would result in the same as the following cross-project layout:
Workspace Single
$/CommonProject/ => c:\src\Shared
$/ProjectA/ => c:\src\1stProject\SolutionA
$/ProjectB/ => c:\src\2ndProject\SolutionB
Note
In any cross-project setup, the UI of both Visual Studio and VSTS will fight you. The VSTS team has been working on the ability to make individual Team Projects portable across accounts. In order to do that features like these will need to be dropped at some point. The UI in VSTS build, for example, will not show any other Team Projects in the Source picker. If you type the paths manually they will work (as long as you configure the build to have a Collection Level scope).
Advice
The Nuget solution is the most reliable solution for the type of problem you're trying to solve. The VSTS Package Management feature will allow you to easily share the Common project across multiple projects and even across other VSTS accounts is you want to in the future. It's the most reliable solution.
If you need to be able to edit the files in either solution, I highly recommend you look into Git Subtrees or Git Submodules. Git is the future in any case and these features will allow you to achieve what you need in a much easier to sustain way. They do come with a steep learning curve though.
TFS: What are the consequences of converting a source folder to a branch?
I want to create a branch from a folder in which we have our source code and I see the following option in "Branch" dialog in VisualStudio:
"Immediately convert source folder to branch (enables visualizations)"
Do I loose any information (e.g. file history etc.).
Are there any disadvantages to do it?
Thanks and appreciate your help.
Lerner.For.Ever
The release of Team Foundation Server 2010 began a distinction between branches and folders. The following illustration shows the top-level of the folder structure in Source Control Explorer：
As the illustration shows, you can still use folders to organize
branches within a team project's version control hierarchy. However,
folders and branches have a different appearance and different
capabilities. When you right-click a folder or branch and click
Properties, you display different information and different
functionality.
When you perform branch operations, branches have important
advantages over folders. Branches support version control features
that provide extra visibility into your branch structure and into
where your changesets have merged. (For more information, see these
wonderful links: Visual Studio TFS Branching Guide)
Although you can still branch and merge among folders, the best practice for your team is to branch and merge only among branches.
Above points are all related to the difference in TFS and VS, something about Trunk and main, you could take a look at the answer from Jesse Chisholm in Folder converted to branch?
We develop with Visual Studio 2010 (in C#) and migrated a while ago from SVN to GIT. Now we try to split up our repository (which is quite big - ~30.000 files) to many git repositories - one for each solution.
The solutions share some projects, mostly libraries we develop in-house and like to add to from all the solutions.
The new repositories have a flat layout. One subdirectory for each project (shared projects are submodules).
In the big old repo, the projects are in a tree structure.
The Problem occurs with external references in the submodules. In the new repos, the path to a referenced project may be "......libs\someproject", while in the new layout the correct path would be "..\someproject".
We already had some edit wars concerning this and are not keen on more.
Half-baked Solutions I could think of:
use "Reference Paths" in ...csproj.user and exclude this file from version control (has to be redone for each developer and after each reopsitory cleanup)
use branches for each situation and try to teach everyone where "real" commits should go and where "environment-change" commits should go (submodules are already not the simplest concept...)
embed binaries instead of the submodules (but what about developing changes to the submodules? what about different log4net versions?)
Does anyone know of a sane solution?
Since you are asking for a sane solution, I can only advise you to look into setting up your own NuGet service (look at http://www.MyGet.org for inspiration)
http://nuget.codeplex.com/
IF you go down the route of package management, consider OpenWrap. However, embedding the package management artefacts in source code is a bad idea. You can use such tools to update what is actually stored in submodules, but don't rely on them at build time. Expect the binaries to be there from the point of view of your build scripts.
So if I understand you correctly, the problem is with Visual Studio and not with Git? If that's the case, use the old tree structure that worked with Visual Studio. Make your submodules structure a tree structure too. So the top of the tree would be one super repo whose sub modules (the branches) would have submodules of their own, until you get down to the leaves of your tree. It would be a pain to setup at first, but it should just work.
Use one submodule to house all "common libraries". Just one level. But you should move the common libraries as services with well defined contracts. This way you can incrementally rollout new versions with no down time. This way you only have a submodule in each that holds the contracts. These could be interfaces or messages.
I have a similar problem using VS 2013.
I want to use git-svn instead of SVN directly. SVN has a gigantic set of directories. I could not create a single git-repository that would contain all of our trunk folder. Git-always exited with an error and the repository was corrupted. I worked around the problem by doing as follows:
Using git-svn, I cloned the subset of folders off SVN/trunk that I needed by creating one git-repository per folder.
Created a local parent git repository that contains all my git-svn-cloned folders.
Each git-repository was added as a sub-module to the parent git-repository.
The problem with Visual Studio is that it does not recognize the multiple projects outside the main project where I opened the solution. This solution is in a folder that contains the only files recognized by Visual Studio as being under git-source control.
I tried setting the git-preferences to use the upper level parent directory as the location of the git-repostitory without noticing any difference.
If I have a C# solution with multiple projects in it, what would be better, to have the Git repo created in the solution folder, or in each individual project folder? Multiple developers will be working on the projects. What are your experiences with this?
I use several (sometimes overlapping) solutions to contain a collection of related independent applications and shared libraries. As others have mentioned, you really don't want to have a single Git repository containing the source for multiple, independent projects as it makes it much too difficult to track isolated changes.
So, if your solution is structured as mine is then you will definitely want individual Git repositories for each project. This has worked well for me for ten to twelve applications and doesn't create as much maintenance overhead as you might think.
If your solution is truly monolithic (and you're sure you want it that way forever and ever), then it probably makes sense to only have a single repository.
It depends. git repositories are most suited to containing a single configuration item with its own independent lifecycle. If your projects have their own release cycle and are shared between multiple solutions then it might make sense to have them in their own repositories. Usually, though, it is the solution that represents a configuration item with all the constituent projects forming part of the same build. In this case a single git repository at the solution level makes more sense.
git submodule is probably worth consideration here. Each project gets its own repo, the solution gets a repo, and the projects are submodules.
I assume that your solution represents some kind of a product while the projects are just a part of the product.
In this situation I would create the repository on the solution level. This way it is a lot easier to build the whole product at once, especially if the projects depend on each other.
Some though and 3 solutions on the subject can be read on that blog:
https://www.atlassian.com/blog/git/git-and-project-dependencies
package management tool, i.e. nuget in VS, so using reference to a package/compiled module
git submodule (only with command line in VS?)
other build and cross-stack dependency tools
Another solution is just to add a project from the other repo and let it out of the current repo, and latter use the Team Explorer to commit its changes.
Just moved to subversion...from visual studio. I love it already! Can someone briefly explain
Repository
Branches
Tags
Trunk
Do I need to create a new repository for every project? Or a new trunk?
Thanks
You don't need a separate repository, but you can if you want. I recommend reading the book at http://svnbook.red-bean.com/. Grab the pdf version or whatever. It doesn't take too long, and it explains some things pretty well. I read it, and found that I'm glad I did.
Remember that subversion is just a fancy filesystem that supports versioning. Think of a repository as a "drive root" like "C:/".
Each project gets a trunk, tags and branches directory. All of your day to day work happens in the trunk. Experimental code is done in a branch and then merged back into the trunk at a later date. Tags are for when you release the software. These are not to be edited. When you release the software, you create a tag with a unique name based on what is currently in the trunk.
I can't say whether or not you need a separate repository for each project, there are pros and cons. This blog posting details them:
Simplified administration. One set of hooks to deploy. One repository
to backup. etc.
Branch/tag flexibility. With the code all in one repository it makes it
easier to create a branch or tag
involving multiple projects.
Move code easily. Perhaps you want to take a section of code from
one project and use it in another, or
turn it into a library for several
projects. It is easy to move the code
within the same repository and retain
the history of the code in the
process.
Here are some of the drawbacks to the
single repository approach, advantages
to the multiple repository approach.
Size. It might be easier to deal with many smaller repositories than
one large one. For example, if you
retire a project you can just archive
the repository to media and remove it
from the disk and free up the storage.
Maybe you need to dump/load a
repository for some reason, such as to
take advantage of a new Subversion
feature. This is easier to do and with
less impact if it is a smaller
repository. Even if you eventually
want to do it to all of your
repositories, it will have less impact
to do them one at a time, assuming
there is not a pressing need to do
them all at once.
Global revision number. Even though this should not be an issue,
some people perceive it to be one and
do not like to see the revision number
advance on the repository and for
inactive projects to have large gaps
in their revision history.
Access control. While Subversion's authz mechanism allows
you to restrict access as needed to
parts of the repository, it is still
easier to do this at the repository
level. If you have a project that only
a select few individuals should
access, this is easier to do with a
single repository for that project.
Administrative flexibility. If you have multiple repositories, then
it is easier to implement different
hook scripts based on the needs of the
repository/projects. If you want
uniform hook scripts, then a single
repository might be better, but if
each project wants its own commit
email style then it is easier to have
those projects in separate
repositories
I agree, read the svnbook. It's a great resource.
Do I need to create a new repository for every project? Or a new trunk?
Kevin covered the single/multiple repository trade-offs pretty well. When we started with svn, we used one repository for all of our development projects. It worked well and had all the advantages mentioned. However, as the repository got bigger it got more difficult to administer because of the size of the dump file and resulting issues during backup. It also became an issue that projects couldn't easily be archived out of the repository - it's certainly possible but it requires dumping and pulling out projects from the repository. They aren't issues you can't get around but it's something to keep in mind.
Repository
Branches
Tags
Trunk
Branches, tags and the trunk are just copies of your files contained in the repository. It allows you to segregate and check-mark your files at whatever time you feel appropriate (usually at a release or a feature branch).
An important thing to keep in mind about branches, tags and trunk is that they just conventions in svn. There is no functional difference between the three locations, they are just an accepted usage model and they can be changed or organized differently if you have a good reason. I'm not recommending that you organize differently but you'll find that svn is very flexible because there isn't really a forced organizational structure other than convention.
Depending on how many projects you decide to have in your repository, you may organize differently.
You can have the subdirectories with projects under it:
\repo
\branches
\...
\tags
\...
\trunk
\..
or you can have projects contain the subdirectories:
\repo
\Project1
\branches
\tags
\trunk
\Project2
\branches
\tags
\trunk
There are trade-offs that are covered in the svnbook. The first method is usually used if you only have one project per repository and the second if there is more than one project in your repository.
The nice thing is that you can just start using svn and then figure out what you prefer. You should have some sort of organization but, with cheap copies, you can always re-arrange the folders as your situation or workflow changes.
An important thing to remember with SVN, compared to other version control systems like CVS or Git, is that SVN doesn't really have a concept or branching or tagging. As far as SVN is concerned it's all just a bunch of folders and files. So while you'll see a lot of people using the branches/tags/trunk setup, this is not required and you are able to deviate from this if you so choose.
Generally speaking 'trunk' is where you keep your active development going. So this is where you do all your commits. Whether or not you checkout trunk or use tags/branches instead is entirely up to you.
Branches, as I've used them, are usually for when you need to do large changes to your application but don't want them in trunk because you want to be able to continue developing against trunk without deploying your other changes. In this case you may have something like
\repo
\trunk
\branches
\version_two
In this case you can develop in both trunk and version_two separately and, assuming your live site is a checkout of trunk, you don't need to worry about 'accidentally' breaking your live site with your other changes. And when those changes are done and ready you just merge them back into trunk whenever you want.
Tags can be used similarly to branches, in that instead of checking out trunk and just using 'svn up' to update your repository you instead of several tags, each representing one release. So your repo may look something like
/repo
/trunk
/branch
/version_one
/version_two
/tags
/1.0.0
/1.0.1
/1.1.0
In this case the general idea is that when you're ready to do a deploy you do an
svn copy
To copy trunk over to a tag (in this case the next one could be 1.1.1, 1.2.0, 2.0.0, etc). How you name your tags it entirely up to you though and, again, depends on your project and requirements. With this route instead of doing a regular 'svn up' you would have to do an svn switch. So you have to deploy with
svn switch https://svn.yourrepo.com/repo/tags/1.1.0
The switch will automatically do updates, adds and deletes on the appropriate files.
When it comes to one repo for many projects or separate repos for each one I am an advocate of one repo per project. It provides the additional benefits of easily managing access to it. But most importantly it means that each project has a separate commit history and separate logs. This m
Reading your tags I see you started using VisualSVN instead of your old VSS system. (Your question says you stopped using Visual Studio.. which makes VisualSVN a strange choice).
One of the major differences between SourceSafe and VSS is that you can choose different tools to access the same repository (and you can switch every time you like as they all share the same workingcopy).
E.g.:
TortoiseSVN for Explorer integration.
The normal subversion client for scripts.
VisualSVN as Visual Studio frontend for TortoiseSVN
AnkhSVN as real SCC (VAPI) package in Visual Studio.