Enable distributed source control (DVCS)
DVCSs are faster on commit, enable multiple central servers, enable an excellent approach for branching, allow for offline work, and usually come with a better merging system. It also enables us to shared code without having to go through TFS, so I could push and pull changes with my colleagues directly.
Please enable us to work decentralized.
Some ideas for later:
I would not worry with integration with Work Items on the first version, and on a later version you can add the integration via caches. Build should be done on push, not on commit.
On a later version you might enable to push from one TFS repository to another directly.
Allow the version control system to be pluggable. Allow someone to use the built-in VCS, SVN, Git, Mercurial, etc with TFS.
I know many people who LOVE what TFS can do but HATE the source control. I have no problem with the source control but I think you’d see adoption skyrocket!
Derek Licciardi commented
This would be a nightmare for transparency. Most of the products asking to be integrated have no love for anything Microsoft. Open Source Sortware comes to mind. Transparency would suffer. Traceability would suffer. How is work shelved and unshelved as tasks move from in progress to todo and back? What analogies need to be mapped between source control systems for shelvesets and changesets? These are fundamental concepts to the entire TFS system working properly. I can't see how CVS, Git, Mercurial, etc., etc. would map consistently unless each product released a TFS version.
Manish Jain commented
@Giovanni - Yes that's the problem if you don't rebase. I was able to commit each git commit as tfs checkin. Here is the link for more details: http://stackoverflow.com/questions/9088510/git-to-tfs-2008-one-way-migration-with-history
Last time I checked, gittfs folded all my git commits into one big TFS commit. This makes the tool useless to me. Also, I don't think I can work decentralized with other peers, pull from each other, etc...
Manish Jain commented
If you are not aware, here is bridge - https://github.com/git-tfs/git-tfs
And make fast switch of TFS servers and Source Control systems.
Something like Team Explorer but with combobox or treeview of Source Controls servers I plugged in.
So I can just click on it and connect right away.
DVCS branches, at least Git model, don't completely support the multiple environment scenario. With TFS/P4/SVN model, you can run multiple builds at the same time - one for dev, one for QA, etc. With Git, you have to switch your working folder, which precludes that. It's not about preference; if you draw a feature matrix, "traditional" CVCS branches will beat other approaches (repos, GitHub, etc.) Again, branching is slow only on sub-standard CVCS systems, like the SCM engine of TFS.
Yep - after you're done, merge the code and delete the branch. I think it's beneficial to preserve the history in the time line. Even if you delete the branch, you can then go back and look at it's history - "delete" is usually soft, and history of that branch is preserved.
I thought mobile broadband was available in Sao Paulo and other big cities? Isn't it the biggest economic and financial center in Brazil?
You don't *need* to have several repos for qa, dev, prod, etc. You may use regular branches, as you would on a CVCSs, as branches are supported in the DVCS model. But you *may* do so if you want. I completely disagree that using branches is better, I prefer using other repos, but only DVCSs support both models. Don't assume everyone prefers your way. I already exposed why I think branches are not the best option for this scenario on my previous comment.
Creating a branch to share code with a small subset of your team is just waste of effort and it pollutes the repo. What do you do after your work is done? Delete the branch? Also, the source code line is going to be with several old branches that don't serve any purpose anymore.
US, Europe and Urban Asia is not the whole world, please look around and you'll actually see that a lot of development now happens outside this markets. I won't even go there, I myself am not there, and I can tell you that my city (Sao Paulo, Brazil) tops the number of developers in cities like New York or London easily.
Sharing something with a small subset of the team is possible with CVCS - just create a branch, give a few people (or yourself only) access, and voila. It's better to commit to a server anyways, because if something happens to your machine, your code is safe. I do think that temporary local commits should be allowed, for later server sync (to improve speed).
The secondary repo - that brings me back to my original point: lack of proper branching in a typical DVCS system leads to arguable dirty workarounds. CVCS branches do all of that in an easy, consistent fashion - you use one tool to solve a number of problems. WIth DVCS, you use something like GitHub for security, multiple repos for prod/qa/dev separation, and P2P networking for team collaboration - see how complicated it gets?
Regarding connectivity - people who travel should have 3G/4G connection with them at all times, and most of US, Europe and urban Asia is covered these days.
Starting a repo on the go - that's one use case where DVCS is a better approach, since you are not using a central server in that scenario. It is a very rare need, and again, I'm not sure if changing TFS to accommodate that niche use case would justify the effort and complexity for most other users. CVCS' better develop "adapters" to import DVCS databases easily, into a new folder, etc.
The concept of DVCS is that there is no central repo, and anyone can act as a node. This is doable on TFS, where you would have one of the nodes to act as the canonical reference, and the one where we do builds and take reports from. It would still be decentralized, as I would be able to share code with a coworker without having to push it to the server. This is very useful when you are working on a feature that is not yet ready to be shared with everyone, but that a small subset of the team is sharing. This is very helpful and is usually done for small periods of time, and is not possible in any easy way with CVCSs. Also, I might be working by myself on something that I don't want to share, but I do want to commit. To be able to commit to a local repository means I have repository of my own, a kind of DVCS, and then, why not just enable it?
The idea of a secondary repo is very interesting. Let's say you have a dev repo, and you push your changes there, and then it builds and run tests, quick tests. You might have a different machine that would be your qa machine. When you push to it it also builds, runs the quick tests, but also runs the more thorough tests, slower, integrated ones. When it is done testing and everything passes, it pushes the build to a QA server(s) where the QA team would be able to test. This is doable in CVCSs, but only with branches. In reality, we don't need dev and qa branches, we need dev and qa repos. We need branches for v1, v2, v3, etc... or maybe to control different customer versions, etc. Using branching to control how ready you are is pushing the idea beyond where it should be.
Also, you assume an all time connected world, and this is not possible. I am very used to see a situation where people travel a lot, and don't want to use their lame hotel connections to be able to commit. A 1 day interruption of internet or connectivity would stop tens of development teams. This does not make sense.
Also, please consider the idea of being able to start a repo easily anywhere. I have been to events where an idea flourished, people started a git repo and commited there, then shared the repo with history through a pen drive. This is not doable at all with a CVCS.
The idea of DVCS enables scenarios that did not exist until it's creation. I could argue that the idea of a central server is the one that is as old as computing itself.
I do understand that most companies have reliable networking, and people are online most of the time. Still, with a CVCS you lose the ability of easily move code around repos, ease of creation of repos, team sharing, etc.
It looks like we're talking about pretty much the same thing: a central server, and clients that do more than today's CVCS clients do, a hybrid, if you will. That is not a bad approach; but it's no longer DVCS. "Distributed" means there's no central server. What you are describing (and what people tend to do) is using distributed systems in a centralized fashion.
My main problem with that is you're using the wrong tool for the job. If you still need a central server, which is definitely the case, why go about making a DVCS and then use it with a central repo? Why not improve a CVCS' client to handle offline better? Clearly, P4 and TFS have some support for offline - do they need to do more? Definitely yes. DVCS, however, is an overkill.
Performance differs not only depending on the network. TFS has inherent problems with it's data access layer and middle tier - I don't know what exactly is the problem :), MS does. Over the same network connection, P4 is orders of magnitude faster than TFS and Svn. It's even faster than Git when you get to really large repos that contain large binary files, like media content.
Also, with Gigabit networks and soon to be introduced fiber-optic ethernet, with 4G on the go, WiFi on the airplanes, and 30MBs home cable, network speed is just not an issue any more. People stream HD content - when I buy MP3s, I get them in less than a second - sending some code files back and forth is not really an issue these days. My point being, DVCS are solving a problem that existed back in the 90s when Linus Torwalds was young, and maybe exists now in under-developed markets, like Eastern Europe. (not being arrogant here, just stating the obvious)
Usually, network access is severed during such short periods of time and during such circumstances (power outage, vacationing on an island, flying Russian airplanes, etc.), that access to SCM is the least of your worries.
I didn't really understand the concept of "secondary, tertiary, etc." repos. Can you please elaborate? TFS or P4-style branching is more than sufficient for most goals, like dev/prod/qa separation.
Now I understand what you meant on 2d. It is already in works for TFS 11.
You are assuming that github/hosting off-premisses is the only option. You can host it on premisses with security, and it works perfectly.
Also, please don't assume git when I say DVCS. Git is one of them, not the only one.
Hg supports the git branching model and also a model similar to SVN/TFS. And it is distributed. So, no problems there, plus you get the additional feature of not really needing to branch if you just need to experiment, allowing you to have a totally new workflow, just impossible with current centralized systems.
Performance is a problem in TFS, and it will be a problem anywhere where latency is a problem. P4, TFS, SVN, it doesn't matter. I have seen "fast" centralized version control systems that, when they are on a slow network they become slow. And the internet is a problem, as it is the media where WANs go through. I have seen 300ms latency WANs that make it very hard to work with CVCSs. With a DVCS you minimize the problem, as you may checkin offline, and only when you push you'll need the network. And you may do so from a local cache, or from a peer, making everything faster. Also impossible when using CVCSs.
It is no wonder that DVCSs use a primary ("default" is the right name) repository. The difference with DVCSs is that you can have a secondary, tertiary, etc, repositories, impossible with centralized control. So yes, there usually is a central repository. But it is not required, and you may have more than one. For exemple, one for dev, one for qa, one for prod. Impossible with CVCS, as well.
Well, first of all, Git doesn't support security out of the box. Yes, you can work around that limitation by using services like GitHub, but then how do you convince enterprise dev teams to push their lifelyhood - their whole IP - to the cloud? Especially considering that there's a monthly fee per developer and effectively you're replacing a centralized system with an in-house server, with a centralized system with a server hosted elsewhere - adding a new point of failure in the process - the Internet. But aside from Git, the distributed model doesn't support security by definition. In fact, most DVCS proponents argue that all code should be accessible by all, which, as good of an intention as it may sound, is not a workable paradigm in corporate shops.
Secondly, the branching model in Git is very confusing (can't speak about other DVCS). What you have is essentially a "jungle-style tree" of inter-mingled branches and check-ins. Not only it's confusing, but it's limited, too. You can't get previous and check in, for example (that corrupts the database).
P4 is not faster than Git - I never said it was; all I said was that the difference becomes negligible enough to stop being a factor. The reason DVCS seems to be a good approach to solve performance issues is not only due to DVCS' strengths, but in a big part due to TFS' and Svn's weaknesses.
Checking-in offline is not approaching "DVCS" under a different angle; it's approaching "working offline" under a different angle than DVCS. Fun fact: the way DVCS (especially Git) are usually used is by relying on a copy of the repository to be designated as "primary" (GitHub or the manager's comp.), which is no different than a centralized system.
2-d is not the default; all files are read-only and you still have to un-mark it as readonly or check it out.
David Allen commented
I am very much in favor of incremental improvements like allowing us to work off-line more effectively. In particular, we have a prospective client who is a subsidiary of a larger organization. They work on a wide area network that is somewhat unreliable. Currently, if the network were to go down for a couple of hours, disconnecting them from the centralized server, they would be able to use Visual Studio to continue some development. But the techniques for going off-line and doing development in this way are somewhat clumsy. I would welcome any improvements to the version control system that would allow remotely connected satellites to remain productive in the face of occasional interruptions in network connectivity. If you take that even further, imagine enabling a consultant who is doing programming to work productively while they are sitting on an airplane or in a hotel room without adequate network connectivity.
Regarding the more revolutionary improvements represented by a distributed version control system, I'm open-minded and willing to learn. I have no experience with DVCS. But if it offers a superior paradigm, I would certainly consider it. I have worked with TFS centralized version control system and the branching model works fine for me in my context. My context is an enterprise in which we develop websites that are used internally as well as by our customers. We host them all. This is very different from a scenario involving the distribution of a shrink-wrapped package. It is also different from the scenario of an open-source product that may be developed by a large number of volunteers spread out across the world.
One of the challenges of developing any product like TFS version control is being clear about what scenarios you expect the product to serve, and which scenarios it is not designed for. I hope the TFS version control team are clear about this in their own minds and are driven by the usability scenarios they have agreed to serve. Otherwise, they risk creating an overly complex product that has a little bit for everybody but does not serve any scenario well. I have no reason to suspect this is the case. And I'm not trying to be critical. I'm just raising a caution because I am having trouble imagining a version control product that is optimal for both centralized and decentralized operation. If that can be achieved it would be pretty impressive.
I believe that one reason I found the centralized branching patterns easy to use is because the ALM Rangers provided excellent documentation in their branching guidance. If Microsoft were to introduce a new paradigm, I hope they would collaborate with the Rangers to ensure that we get equally clear instructions so that those of us who are new to this paradigm could train ourselves and others.
When you say DVCS doesn't support security, what exactly do you mean? Do you actually believe that all git or hg repositories are insecure and anyone can pull or push to them? Maybe you should check your facts... Also, even if that was true, there is no reason Microsoft couldn't make a secure DVCS.
The branching model is no more confusing than it is in a centralized system. Actually, you need to branch less in a DVCS because you can, for example, do a quick experiment locally without ever pushing a new branch to the server. If you say it is confusing, you should say how it is confusing. Only saying it is confusing is like saying it is ugly. The same goes for other claims you don't explain.
And saying p4 is faster than git is a joke. It is not, and many benchmarks show that.
Centralized don't allow you to work offline currently. You can't check-in offline. If you could, this would be a nice improvement, as well. But isn't this just approaching DVCS from a different angle?
And 2d you mention is already default on current version.
Items 2 and 3 are already in the works for TFS 11.
I would disagree. DVCS don't support proper security, the branching models are usually confusing, performance gains vs slow centralized systems like SVN and TFS are quickly negated by using a fast centralized system, like Perforce, and same goes for merging and other tools.
Working "decentralized" probably refers to working offline - again, centralized model doesn't prevent you from working offline.
To sum up:
1. Make TFS faster;
2. Improve offline capability:
2a. Allow user to download a portion of the repository's history to local host, for later offline browsing;
2b. Allow offline "check-in", to be sent to server later;
2c. Make the online/offline transition more seamless - don't bug user about not being able to connect to server, etc.;
2d. Adopt SVN model - files are non-exclusively checked out by default, so editing a file doesn't require a server connection;
3. Improve tooling - built-in diff/merging tools in TFS are horrible, aim for Perforce- and Beyond Compare-level feature set and performance;
I think that the integration with workitems makes the TFS version control system stand out of the crowd. Dropping the support for that in a "first version " will make a lot of people very unhappy (Yes that includes me).
A good version control system with offline support that is not standing in my way is a great idea however!
Why don't you guys take a look at Plastic SCM? It is THE dvcs for Windows... www.plasticscm.com
Matthew Mitrik commented
Just to touch base here, DVCS is something that we're planning for in the future. The feedback here provides a lot of good insight, and we'll use this as we develop our strategy.
Program Manager | TFS Version Control
Can this not be done via a 3rd party plugin for VS as has been done for other VCSes?
Adam Dymitruk commented
This is very important for MS to get right. They have to get over "we have to get everything right ourselves". Integrate with git at the very least.