TFS: Создайте новый проект из существующего в TFS
3 ответа
There are really two questions here:
1) Is it better to copy/paste or branch?
I'd venture to say that copy/paste is never appropriate. Unless you are very careful (at minimum, run 'tfpt treeclean' immediately before copying), it's likely you'll end up checking in some inappropriate files to the new location. In addition, you will be using up FAR more disk space on the server, since it must store 50+ full copies instead of just diffs.
There is virtually no danger that branches will "accidentally" become comingled down the line. Merging branches back together involves at least 3 deliberate steps: pend the merge (itself a 4-page wizard), then resolve all conflicts, then checkin.
Nor are you likely to get confused as to your place in the tree. TFS uses "path space" branching. That means branches appear to the user as separate physical locations in the source tree, rather than mere version-tags on top of the same path. Since branches look like folders, you can do all the normal folder operations on them: Cloak (don't download them to your local workspace), Permission (in particular, removing someone's Read permission will ensure they can't even see it), Delete or Destroy (when you're truly done with them).
2) When is it appropriate to create a new Team Project?
This is a more complex topic in general. Official guidance. My opinion.
However, I'd say your case is easy: don't do it. Team Projects have a lot of overhead. There is a finite number you can create on a server...ever. Don't forget about other forms of overhead too, like the time it takes for the project admin to port over all your settings, and the time every developer on your team spends reconnecting his Team Explorer.
All for what? The links above go into great detail about the forms of sub-structure that can be created inside a single Team Project. In short, almost anything is possible. The only areas that are somewhat lacking are Team Queries and Build Definitions, which are restricted to a single container folder, and a few settings like Exclusive Checkout which are all-or-nothing. Unless you have a very large or very diverse team, the benefits of separate team projects per release are very unlikely to outweigh the drawbacks.
Of course, if a "release" is a major event that signals a change in your SCM practices , that's a whole other story. New SCM => new process template => new team project. But I doubt you do that 50+ times a year :)
Я бы рекомендовал использовать ветвление. Создайте ветку для каждого выпуска из основной ветки. Пока вы не объедините ветви, они останутся независимыми. Изменения в основной ветке повлияют только на выпуски, созданные после того, как эти изменения были внесены.
Вы можете скопировать файлы и создать новый проект, но вы можете столкнуться с парой проблем:
- Проекты «помнят», что они были в TFS, есть небольшая ручная работа по очистке специальных файлов и т. д.
- TFS может замедлиться, когда у вас много проектов, по сравнению с одним проектом с ветвями
Это может показаться очевидным, но вам следует создавать новый проект только для «нового проекта». Похоже, вы говорите о разных версиях одного и того же проекта.
Если вы хотите поддерживать отдельные кодовые базы для предыдущих выпусков, тогда, как сказали другие ответчики, ветвление кода - ваш лучший вариант. Это хорошо работает, когда вы хотите объединить исправления ошибок из последней версии и в более старые выпуски.
Однако, если вам действительно действительно нужны новые проекты, вы все равно используете ветвление таким же образом.