Team Foundation Server: Why is changeset history shared among separate projects?

Question

I've been using TFS for a few months now and have a few separate (unrelated) projects on the web interface, and linking the associated projects in Visual Studio 2012. The anomaly I'm experiencing (at least I'm perceiving it that way) is that checking in the code for Project A increments the changeset sequence number (say, to 124) for all other projects, such that when Project B is changed and checked-in, it gets the next changeset number (e.g. 125). To me this is bizzare: if projects A and B are completely independent (aside from the fact that I'm using the same TFS account for both projects), why are they both sharing a common changeset history sequence? Have I done something wrong in the setup of my TFS?

Thanks!

Answer 1

A changeset is a snapshot of the entire version control tree - that is, $/. This is because your projects may have interdependencies; you may check in to both projects in a single changeset and that changeset needs to be atomic.

In other words, the reason you want two files in one project to be committed with a single changeset is the same reason you want two files across two projects to be checked in with a single changeset.

Answer 2

No that's right. One thing is not the other, all changesets get stored in one place and each associated with an ID. You can if you wish check multiple projects/ solutions at the same time. At that point a seperate id per project would have a real problem.

Answer 3

Team projects are not independent from point of view of source control. The reason is simple - you can copy (preserving history) from one team project to another.

So a changeset of TeamProject1 will have references to some content of a changeset in TeamProject2.

With independent history that would be difficult.