Git feature branches - one VCS root, or many?
Answered
We are in the process of migrating from TFS to git for our source control, so I'm getting familiar with TC's git features for the first time. The way I have our pilot project set up, we have:
- One VCS root that includes refs/heads/* and refs/tags/*.
- A build config that triggers on "working" branches (develop, feature/*, hotfix/*) to only build and test
- A build chain that triggers on "publishable" branches (master and release/*) to build, test, build documentation, etc. to prepare a deployment package
I've noticed however that the "working" config will show pending changes from master, release/*, and the "publishable" configs will likewise show pending changes from the working branches. Is it recommended to have separate VCS roots limited to the set of branches that will actually be used for a config? If I go that route, is it going to screw up the Change Log tab, or cause any other problems?
Please sign in to leave a comment.
Hi Merad,
There are several options for your situation.
-Stay as you are. The pending changes will show up for all branches in all configurations that use that VCS Root, but shouldn't have any impact on results.
-Have two separate VCS Roots. This would be the clearest and would allow you to easily make changes to one of those (in case you would decide to move one set of working branches to a different type of VCS, different set of branches, or anything) without worrying about any impact on the other one.
-Have a single VCS Root, but use the branch spec with a parameter format that can be altered per build configuration/project. This way, the VCS Root can be configured only once, and have a separate branch spec for each build configuration that uses it. (Also, most other configuration options can be used as parameters as well to be modified per-build).
There is different pros and cons to each approach. Your current one clutters the overview with the "Pending changes" tag but everything is available from a smaller configuration. Two separate VCS Roots require maintaining both in case of changes (Most options can be configured as parameters reducing the overhead here). Single VCS Roots with different parameters might require modifying all build configurations that use some parameters when something needs to be changed (but parameters are inherited, so can be set at project level to reduce this overhead).
Regarding the changelog tab, I guess it depends on your definition of "screw up". Merging into master/release will add to master all information of the commits from the merged branch, so all the relevant info should still be displayed there.