Is it possible to merge 2 different team project collections under TFS 2010, while keeping all version history (changeset numbers can change, since else there will be overlap problems in the numbering). e.g.
Team Project Collection A
Team Project A
Team Project B
Team Project Collection C
Team Project C
And I want to end up with:
Team Project Collection A
Team Project A
Team Project B
Team Project C
And keeping the version history (all different checkins) of Team Project C, so I can still revert to a previous version if needed, view changes etc.
As a follow up: is it also possible to split Team Project Collection A in 2 seperate collections (again keeping the history).
I can see several scenarios in which the setup initially planned fails to meet all requirements after a while (like common code for merging or size/seperation of concerns to split up).
You cannot merge team project collections in TFS 2010. There are two many conflicts: changeset numbers, work item IDs, builds, test results, etc.
You can split a team project collection to multiple collections though. Here is the MSDN topic about organizing the team project collections.
TFS Integration Platform may help you to move projects but as the documentation clearly states, "it is a lossy transfer"
Related
I have a requirement to split one big Team project in Azure DevOps to multiple team projects, as you know there are work items, iteration , repositories, test plans and CI/CD pipelines to move across. What is the best way of achieving this - apart from manually moving them across ?
Currently, there is no default way to move sources from one Team project to another. You can check OpsHub Visual Studio Online Migration Utility which can migrate source code, work items, etc.
Meanwhile, there are move work items (select some work items > Right click > Move) to another team project, move git repositories between team projects, move items in TFVC features that can help move sources.
New to VSTS, but not Git. Our small team has the usual mix of web apps, windows apps, other misc applications/services and we keep our database objects in visual studio sql server projects as well. So there are 15-20 or so different sets of code to deal with. Currently, each would have its own Git repo.
Was reading this post regarding single vs multiple "Team Projects".
Then, I posted this earlier but was specific to backlog items, but I suppose my real question was about the bigger picture regarding the idea of a "team project"
What would be a good structure for a small team with this number of applications. Assuming each application generally is worked on independently, but you might want to build 2 or more of these applications together.
How about one team project. Multiple "teams", one per "application".
Its the terminology that is throwing me off.
Can different teams each use a different repo?
Can each team have a different set of build definitions? eg. dev/prod etc
A team project is a container for a portfolio of related applications. A team project can contain one or more source code repos (Git/TFVC), builds, releases, test cases, work items, etc. All of these entities have ways of defining security around who can view/modify them.
A team is just an organizational structure within a team project. You can use security permissions to limit certain repos, builds (or build folders), etc to a certain team.
The generally accepted guidance is to keep everything in a single team project. There are lots of things that don't cross team project boundaries, such as repos. Work-arounds usually exist, but they are typically awkward.
The one requirement you gave ([we] might want to build 2 or more of these applications together) is actually slightly tricky regardless of whether the repos are in one or in multiple team projects -- a build definition can be hooked up to a single repo. If you need to bring in additional repos, you'll need to use submodules or add an extra build step to clone the second repo. I can almost guarantee it'll be easier if everything is in the same team project, though.
The one-word answer to the two direct questions you asked is "Yes."
How you set up your structure is really depending. There are many ways to organize it. Single repo, multiple repos.
If you are using CI builds, have in mind that the get sources task in your build will download your full repo. So if you have a single repo strategy your build could take longer to run. In this scenario you would also have more work to setup your builds and specify path filters to trigger only the correct build on your CI process.
Can different teams each use a different repo?
Yes they can.
You can create a security group for each team.
Then, on you team you can remove it from Contributos and add your new group as part of Member of:
After that, in your version control settings, add your new security group and remove or deny access to Contributos security group. This way, only your team security group will have access to the repo.
This is optional. You only need to do it if you want to isolate access to your repos.
Can each team have a different set of build definitions? eg. dev/prod
etc
You can setup a build for each of your repos.
If you need to isolate who has access, you can do it by changing the security on each build, removing contributos and adding your security group.
Background: We use a feature branching strategy to isolate change. Here's a quick diagram of what I mean. Nodes are branches, edges are parent/child relationships in TFS:
Most of the time we create feature branches on a per issue basis, so there are a lot of feature branches.
Also, for my purposes, I only care about migrating source control and changeset history. We don't use TFS work items, test cases, or test results.
Attempt 1: When I first ran the migration tool, it ran for about an entire day before filling up my hard drive and failing.
Attempt 2: Thinking that the 150ish feature branches were the culprit for the slowness/storage needs, I wanted a way to migrate only the "dev" branch of my "ecomm" team project collection in the diagram above. I did not see any way in the opshub tool to migrate a single branch.
I accomplished this by creating a new team project collection "ecomm-migration", then branched $/ecomm/dev to $/ecomm-migration/dev. Then I migrated the ecomm-migration team project collection (which only contains a single branch).
Everything seemed to work: I could see all my source files on Visual Studio Online. However, when I browsed the history of the ecomm-migration project that was migrated to Visual Studio Online, the history was lost: everything appeared to be committed as a single changeset, and annotating files reflected this as well.
Why didn't the changeset history get migrated?
Am I doing it wrong?
Does my approach of creating a separate team project collection to reduce the size of the team project collection being migrated interfere with the tools ability to migrate changeset history?
Are there better tools/options for my scenario?
One thing I had previously considered was pruning dead feature branches with tf destroy, but it would be nice to avoid such drastic, irreversible, history destroying measures if possible.
I am using version 1.1.0.005 of the utility.
Can you please also share what is the version of the utility that you are using? You can find that from the About button on the utility left menu pane.
Addressing your concerns in points.
The disk space requirements of the utility is equivalent to the size of your project. A good reference point would be to get the latest version of the project to your hard drive through Visual Studio and see the size. So that SIZE + 20% would be a good approximation of space that the utility will need in your C: drive during the migration process.
While you did nothing wrong by branching your dev branch into a new project. The utility did nothing wrong either. When you migrated to VSO, you might have selected only the newly created project. Now in your VSO, the trunk of your data in the new project is not present. So, the utility converts Branch -> to -> Add. Which is the only sane way to migrate when source is not selected/available.
To get your desired result (of actual history) you will have to select all the projects where branch-merge was done (across projects) for migration. Which of course is nothing but what you did in Step 1.
Hence, we suggest you to migrate your original project, if you want to retain full history. We can work together to overcome the memory/space crunches that you are stuck in.
I am in the process of moving to Git from SVN. In SVN I had multiple eclipse projects in a single SVN repository that is convenient for browsing projects. I was going to move to having one git repository per eclipse project but EGit suggests doing otherwise.
The guide for EGit suggests putting multiple projects into a single Git repository.
Looking at similar questions such as this suggest one project per repository.
Which approach is best practice and what do people implement?
It depends on how closely-related these projects are. Ask yourself the following questions:
Will they always need to be branched/tagged together?
Will you want to commit over all projects, or does a commit mostly only touch one project?
Does the build system operate on all of them or do they have a boundary there?
If you put them all in one, some things from above will be easier. You will only have to branch/tag/stash/commit in one repository, as opposed to doing it for every repository separately.
But if you need to have e.g. separate release cycles for the projects, then it's necessary to have each project in an independent repository.
Note that you can always split up a repository later, or combine multiple repositories into one again without losing history.
Combining is a bit harder to do than splitting, so I would go for one repository first and see how it goes.
I use 1 repo per project.
Some reasoning:
When you discover you messed up something after several commits, it's much easier to fix when it's just one project. Just think about, you did commits to two other projects and now you need to fix the commit you did on the 3rd project.
As Fedir said, your history and log is much cleaner. It only shows the commits for that project.
It works better with the development workflow I have. I have a master branch for production, develop branch for, well, development, and I create branches to implement features (you can read more about it here: http://blog.avirtualhome.com/development-workflow-using-git/)
When you work in a team, and so "share" the git repo, do the team members really need all the other projects as well?
Just a few thoughts, but what it boils down to: Do what works for you.
I have multiple projects (Eclipse projects) and have tried different things to find out what worked best in terms of actual daily development. Here is what I found and I think that most people would find the same thing if they kept track of the results and analyzed the results objectively.
In short applying the following rules will give the best results:
Make a separate repository for each project group.
Each project group consist of a group of projects that are tightly connected to each other, that should be administered together and that cannot be easily decoupled from each other.
A project group can contain a single project.
A project group that contains multiple projects should be examined to see if some of its projects can be decoupled from each other so it can be split into smaller project groups that are still contain projects that are tightly connected to each other, that should be administered together and that cannot be easily decoupled from each other.
The following guidelines explain this process for determining which projects to put in the same repository in more detail:
If a project is not closely connected to any other project (for example, the project can be opened without other projects being opened and no other projects relies on the project being opened when they are opened) then you should definitely place it in its own repository for the reasons explained in the answers above this one.
If a project is dependent upon other projects or other projects depend upon the project then it comes down to exactly how connected are they upon each other, how well they can be packaged together and how easily can they be decoupled from each other.
A) For example a testing project that contains junit test classes to test the classes of a main project is a case where the two projects are very connected with each other, can easily be packaged together and cannot be easily decoupled from each other. These projects should be placed in the same repository for the reasons explained in part C below.
B) In a case where one project relies on another project to provide some sort of shared resources it really comes down to how well that they can be administered together and how easily that they can be decoupled from each other. For example if the project with the shared resources is relied upon by many projects, then it should be put in its own repository because the other unrelated projects are impacted by changes to the shared source code project. In a case like this, the shared resources project should be decoupled from the dependent projects instead of being directly connected to the dependent projects. (For example, it would be better to create versioned archive files [Jar files with a name like "projectName".1.0.1.0.jar for example] and include a copy of those in each project instead of sharing the resources by linking the projects together.)
C) If the multiple projects are connected, can be easily administered together but cannot be easily decoupled from each other, then it depends upon how tightly connected they are with each other.
I) If the projects are put into one repository, then the projects will be kept in sync with each other in the repository each time there is a commit, which can be a real life saver if the projects are tightly connected. However, this also creates the issues noted in the answers above this one.
II) If the projects are put into separate repositories, then you will have to take care to keep there commits in sync with each other and be sure to include some sort of mechanism to indicate which commits belong to the same sync point across the projects (Perhaps something like including the same sync point number in the comments for the commit of each project when a group of commits is done across the projects.)
III) So in cases like this, it is almost always better to put these projects together into a single repository to reduce the overhead of human effort in syncing the commits and to avoid human error should the commits need to be backed out. The only time that it might be better to place them in separate repositories is when only one of the projects is being changed regularly and the other connected projects are rarely changed.
I think this question is related to one I answered here. basically Git by its nature supports a very fine granular structure when it comes to projects/repositories. I have read and been taught that 1 repository per project is almost always best practice. You lose almost nothing by keeping the projects separate and gain a lot as other have been describing.
Probably, it will be more performant to work with if You will create multiple git repositories.
If You will make a branch, only project's files would be branched, and not all the projects.
Small project it will be faster to analyze, to commit. Operations will take less of time.
The log will be more clear also, You could make more granulated configuration if You will have multiple git repositories.
I'm a self-confessed tfs newbie using VS2010 with team explorer. My application uses version control. I wish to rename my current project ProjectA to something else like ProjectA_01. Then after I've made my architecture changes on a new VS2010 solution I wish to check in the new project as ProjectA. A list of steps would be helpful.
Thanks
I'm pretty sure you can't rename a project in TFS. You could create a new project named ProjectA_01 if you wish, but from the sound of what you are trying to accomplish, I think what you want is to work with branches.
Essentially, you put all of your code in a folder under your project. So, on your hard drive it would look something like this:
C:\tfs folder\ProjectA\Main
All of your source code goes in the Main folder. Then in the Source Control Explorer window in Visual Studio, right click on the Main folder and select Branching and Merging -> Convert to Branch. This is your Main branch (or trunk) and you could use it for code that is ready for beta testing or a product release.
Once you created the main branch, you can right click on the branch again and select Branching and Merging -> Branch. At that point, you can name it ProjectA_01 or whatever you wish. Typically this would be your development branch where you do the bulk of your development.
After you make all of your changes in the ProjectA_01 branch and check in all of your code, you can right click on the ProjectA_01 branch once more and select Branching and Merging -> Merge, which will move all of your changes back to the Main branch (which would signify it is ready for user testing or release).
"Hawkke" is correct in that you cannot rename a team project. If you want this feature, you can vote for it here: http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2037605-rename-project-in-tfs. It is currently the #1 voted feature for TFS at this time.
I'm actually having a hard time understanding if you are talking about renaming a TFS team project or if you are talking about renaming a Visual Studio project. Unfortunately they are named the same.
However, usually team projects are very large and you would have lots of different product families, products, and ultimately Visual Studio solutions & projects in the same team project. You can create subfolders, including maybe even an "Archive" folder in this case, inside of the team project to organize your source code better.
Let us know if we aren't understanding your question though.