Distributed Source Control is not for Visual Studio users?

Question

I remember 2 events in SVN history: TortoiseSVN got usable and VisualSVN got usable.

The result of the first: "We will never ever want to use SVN with command line". The result of the second: "We will never ever use SVN & MSVS without VisualSVN"

please understand this correct - we do use SVN command line if we need something that can not be accomplished with Tortoise and we do use Tortoise if something we need is not available from MSVS. But otherwise (99.9% of the time) all you need is right at your hand in the IDE.

Now I do understand and like the benefits of distributed source control, but there is simply no way I'm going to hunt files renamed in the IDE and executing manually hg rename in order not to loose history ("delete + create new" instead of "rename" = no history). Nor I consider blame or file revert to be an action that can not be executed directly on file selected in solution explorer or open for editing. With VisualSVN all of that, and much more, just works!

Conceptual benefits of DSCM are great, but they are no good if simple, daily used features are not available from the IDE!

The question: is there a distributed source control with plug-in that integrates in to MSVS as smooth as VisualSVN does? Git Extensions and VisualHg are no where close to that point at the moment and VisualSVN team refuses to create VisualGit with:

"We can consider this option only if Git changes its license from GPL to BSD/Apache style to allow derivative commercial work."

P.S. A must from IDE:

• File status in solution tree. Parent i.e. folder/project/solution is marked as edited if any child is edited.
• contextual update, commit, history, blame, revert as a one click action from solution explorer/open file with keyboard shortcuts available!
• Automatic tracking and handling of file rename / drag and drop / new file creation.
• An indicator (yellow line) of what is yet not committed in edited file that does not disappear after the file is closed and reopened.

Not much is it?

UPDATE:

1) Tested HgSccPackage yesterday. It sure has more needed features available right from IDE, and they do respect current context i.e. selected/open file etc. Unfortunately it's solution tree status currently is buggy and does not support folder status.

2) Git Source Control Provider mentioned in a reply same as VisualHG lacks at least 2 things:

• for some reason they have tiny amount of contextual actions (blame/annotate for example is NA)
• it seams they both are solidly based on MSVS source control API (unlike VisualSVN) and hence do not provide solution folders status (same thing with HgSccPackage).

3) Charles Bailey pointed out, that git handles renames anyway. Yep, it does. No need for any of IDE support here (Not sure about mercurial). So git MSVS support only lacks good contextual, one click actions and proper tree status support (well there is also a yellow line, but lets say it's very nice to have, but not a must at the moment).

Answer 1

Have you looked at VisualHG as a plugin to Visual studio for Mercurial?
I'm not a visual studio user so I cannot comment on features.

Answer 2

Uh, have you looked at Team Foundation Server, the MS supported source control tool + project management solution? The 2K10 version is pretty solid.

Answer 3

About the Visual Studio integration for GitExtensions. "We" did not add the integration you are looking for because it doesn't work well with the Git workflow. Sinse there are no file-locking or renaming issues, you can just forget about source control until you commit your changes.

Having that said: there is a plugin for Visual Studio that does what you are asking for. You can find it here: http://visualstudiogallery.msdn.microsoft.com/en-us/63a7e40d-4d71-4fbb-a23b-d262124b8f4c This plugin for Visual Studio adds a Source Control Provider for Git and Git Extensions to Visual Studio.

I'm not sure about TortoiseGit, but as fas as GitExtensions there are no plans for adding a Source Control Provider for Visual Studio. This is not a technical or time problem, its already build in the "scc" branch. The workflows that Visual Studio uses are just different then what a typical DVCS uses. If you find a Source Control Provider very important, maybe its better to stick with SVN since this might suits your workflow better.

Answer 4

I've found VS integration for Git pointless. The only time you need to interact with Git is when you want to stage, commit and push to the remote repository.

This is done when you are finished coding and the code compiles and passes tests etc ... It is at this point I use git via the command line or TortiseGit.

I like how the Git work flow, allows me to work without knowing there is source control, and only comes into play when I need to share my work, or commit at a safe point.

We've been using Git and TortiseGit at my company for a few months now, and even the VisualSVN users don't miss it.

Answer 5

My answer: No.

2 weeks spent on researching and testing various tools and plug-ins. Resume: at the moment of writing there is not a single free distributed source control that integrates in to MSVS as smooth as SVN with VisualSVN does.

SVN is not distributed, and VisualSVN is not free, this is why I was in search for something different.

2 weeks of research is not a minor investigation for me, this is the only reason why I post this answer - hope it will be useful for other out there "on the edge of change".

Also do note, that I review all of my questions, and answers to them - whenever someone prove me wrong i.e. when there will be decent tools available, I will remove this answer, and will mark a better one as "the answer".

---

P.S. the future is in Distributed Version Control systems. If you must select one today - just pick any. You will not miss much anyway. Today I would probably go for Git. But that's really only me.

Answer 6

Well, that's actually what we've tried to solve with Plastic SCM. While it is not just for "windows users" and actually not "just for Visual Studio", we've to admit VStudio is our primary IDE down here. http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html