Distributed Version Control for Visual Studio - Suggestion | The Coffeehouse

xgamer
Two Sides to Everything

Me and My friend are developing some application in Visual Studio (.net) . I have used Visual Source Safe and on smaller scale Subversion for Version control on my PC. However, as we both are working on the same applications and are going to travel around during this period, was thinking of using some kind of distributed VCS.

I checked Git and msysgit which looks interesting. Has somebody used these tools or is there any other suggestions for Version Control in such situation ? How is the integration with VS or it needs to be done manually ?

As its a project currently on smaller scale I would like to go for free or opensource or less expensive solution.

mawcc
Make it so

Why not continue to use Subversion? The combination of TortoiseSVN and AnkhSVN offers a lot of functionality, is stable and works over HTTP(S).

xgamer
Two Sides to Everything

In reply to mawcc

#Jun 28th @ 11:08 PM

One of my primary requirements is to have our own CVS on our laptops. The laptops may not be continuously connected to central server and we would like to synchonize our code server when the laptops connect to the server.

This way we can have ability to write and checkin/checkout code when we are travelling. I am not sure how TortoiseSVN and AnkhSVN can be used in this respect. If you have suggestions in this regarding let me know.

Thanks

LeoDavidson

In reply to xgamer

#Jun 29th @ 12:17 AM

You may find Git worth looking at:

http://git-scm.com/

It allows you to have your own local repository, which you can do commits / diffs etc. against without being connected to the net. When you are connected you can choose to sync your changes either with other people's repositories (peer-to-peer) or with a designated central repository (like more traditional version control).

From what I gather, it's like having a staging area that you commit to, and then later you commit that staging area to everyone else.

You can also do branching etc. all on your local, disconnected machine. Copies of all of the commit logs and history are stored locally so you can see how/when files changed in the past while offline. It also means that every copy of the repository is a full backup of it.

Apparently it can emulate SVN so that SVN clients can talk to it, too.

I have not used it myself but several large, well-known projects do (see the list on their page) and people who have used it seem to be very positive about it.

Turbodad

I currently use Git for all my development. Git-svn talks to our corporate Subversion server. I use command-line Git implementation, as I feel more comfortable being closer to Git porcelain (fron-end commands)—I don't particularly like when SCM integrates into IDE which tries to isolate me from "complexities". I had problems with msysGit (and it currently doesn't have a working git-svn implementation), so I'm using Cygwin Git. Git is really the next step in SCM, it is really good and has many features the old-style VCS (Subversion, CVS, Perforce) don't.

Edited: Apparently, msysGit now does have a working git-svn implementation, just used it successfuly.

wkempf

I personally have never used Git. It was never designed to be portable, and so the Windows versions, when they work at all, do so through "hacks", IMHO. I suffered through Cygwin for other things for a long time, and I don't want to go back there. msysGit at least doesn't require Cygwin, but it's a third class citizen without full feature parity, and still requires various POSIX tools.

I've used Bazaar (bzr), and quite like it. Mercurial (hg) has a larger following, and more support by third partie (such as Google), and I'd consider using it as well, if I weren't already happy with Bazaar. Both of these have Explorer integration via Tortoise, but AFAIK they don't have VisualStudio support. Personally, I'd prefer to do things on the command line in any event. I generally don't install Tortoise, and I wouldn't install a VS plugin if one existed.

LeoDavidson

In reply to wkempf

#Jun 29th @ 7:59 AM

I didn't realise Git required Cygwin / MinGW. I wouldn't use it either based on that.

Ubuntu

In reply to LeoDavidson

#Jun 29th @ 8:05 AM

Cygwin = GNU+Cygnus+Windows (Don't leave UNIX without it)

wkempf

In reply to Ubuntu

#Jun 29th @ 9:05 AM

What makes you think he doesn't know what Cygwin is?

LeoDavidson

In reply to Ubuntu

#Jun 29th @ 9:05 AM

You missed out Big+Slow+Complicated (compared to native apps) and a few other things. Smiley

I've used Cygwin before for a couple of things (most recently compiling the Rockbox DAP firmware to get gapless playback on my iPod before Apple's official firmware was fixed*) and my desire to avoid it is based on my experience with it.

It's not really Cygwin's fault. The problems with it are somewhat inherent with what it does. I imagine if I used Linux for my desktop then I'd feel the same way about running software under WINE: Great that it's there for when you really need it, but I'd very rarely choose to use an app which required it when there was an alternative native app.

(* I say "fixed" becaue gapless playback isn't a feature of music players; lack of gapless playback is a bug. A bug which, sadly, afflicts almost all of them, but a bug all the same. Smiley )

wkempf

In reply to LeoDavidson

#Jun 29th @ 9:57 AM

A lot of my complaints with Cygwin are with Cygwin, not the fact that it's a POSIX environment (I actually like most of POSIX). Cygwin does a horrible job of integrating with Windows, and fails miserably in emulation in several areas. I found SFU a much better POSIX environment, even if it did lack a lot of the GNU ports. If Git ran under SFU, I might consider giving it a shot... though I still wouldn't recommend it for the average Windows developer.

LeoDavidson

In reply to wkempf

#Jun 29th @ 10:09 AM

Yeah, that may be true. When compiling Rockbox under GCC I remember it was horribly slow. I wasn't sure if that was because Cygwin was implemented in an inefficient way, 'or if GCC's compiler for the CPU I was targeting wasn't very optimized, or if it was just inherently slow to translate between the two APIs given the way GCC used them.

Most of all, though, I don't really want the complexities of two OS instead of one. (I know Cygwin isn't as complex as a second OS but hopefully what I mean is clear: It's a lot of extra configuration and knowledge to take on board just to run one or programs.)

Ubuntu

In reply to LeoDavidson

#Jun 29th @ 10:18 AM

You claim it's big. Let me show you how much the default installation + some of the additional packages I've added take:

- size of the archives: 225 items, totaling 44.5 MB

- size of the installation: 10,440 items, totaling 164.3 MB

That's not big by OS emulation standards no matter how you want to spin it.

LeoDavidson

In reply to Ubuntu

#Jun 29th @ 1:13 PM

That is absolutely massive by "stuff added on to an individual installer/application just to get it to run when you don't care about emulating an OS and just want the damn app" standards, no matter how you spin it. That's an order of magnitude larger than most apps.

As I said, I don't want to emulate another OS. I just want to run some additional tools/apps to get a job done. I would never choose an app which requires Cygwin if there's a similar alternative which doesn't.

Would you consider using a source control system for Linux which required WINE when you could use one which didn't and still met your requirements?

Bass
www.spreadfirefox.com/5years/

In reply to LeoDavidson

#Jun 29th @ 3:49 PM

I use Git as my primary VCS. I do most of my development on Visual Studio + Windows. I'll tell you the secret! I run Windows in a virtual machine on top of a Linux host. All my projects are stored on a shared folder which is actually on the host machine. Any time I want to commit changes I just minimize the VM and go into a terminal and type "git commit -m "blah blah changes blah blah"".

I'm no expert in Git but I notice it's ridiculusly fast. Commit takes like a second or less. But really everything about git, updating and what not, just feels really fast. That plus the DVCS functionality makes me like it a lot more then SVN.

xgamer
Two Sides to Everything

Thanks all Bass, Leo,mawcc,wkempf,turbodad for your replies.

The discussion also seems to have to started a mini-fight over usability of cygwin Smiley

Anyway from the disucssion i can make out that DVCS is the solution for my requirements and there isn't a visual studio well integrated solution till now. Personally though I like command line, from a team perspective I would go for windows or VS integrated scenarios (Note currently its only two people but I expect team to grow). I feel SCM is a tool around development and if it can keep "complexities" down for normal developers at initial stage that would help and as they get used to it they can learn more about it.

Anyway I am thinking starting off with Bazaar with TortoiseBzr. Let's see how it works. Will update this thread with my feedback. Meanwhile keep your suggestions coming.

Thanks again niners

Turbodad

In reply to Bass

#Jun 29th @ 3:57 PM

Git is lightning fast, but only on Unix (Linux, Mac OS X). On Windows it is passable, Cygwin Git is faster for me than msysGit.

contextfree

In reply to LeoDavidson

#Jun 29th @ 3:49 PM

Before Powershell existed I found Cygwin pretty indispensible in general for development/miscellaneous IT stuff when I was (as I felt at the time) unfortunate enough to have to work on Windows. The impedance mismatch is definitely a pain, though.

wkempf

In reply to contextfree

#Jun 30th @ 2:54 AM

My problem with Cygwin isn't that it's POSIX. I'm very comfortable with POSIX, even if I dislike the cryptic command names. I also appreciate the raw power (though you're correct that PowerShell provides as much power). Unfortunately, IMO, Cygwin is a poor emulator of POSIX on Windows. I hated using it, and I lived in it for 3 years, 40+ hours per week. Sad

As for command live vs. integrated in the IDE or Explorer... the integration always turns out to be far more complicated than command line usage. I realize people have an aversion to the command line, but once you've got them using the DVCS through one of the integrated options, introduce them to the command line. If you get them to use it for even just a few hours, I'm willing to bet you can convert them to command line users. This is especially true of IDE integration. With some VCSs IDE integration is a must, because you don't want to have to switch to the command line just to check out a file to work on it. With optimistic VCS systems (i.e. no checkout required) however, you only have to jump to the command line to commit changes, which is not a big deal. All of the DVCS systems mentioned here are optimistic. All of them also contain a "status" command that makes it easy to see the status of all files in the tree (modified, added, removed, and unknown), allowing quick and easy maintainance. Where as, with IDE integration you often get files in your tree that the IDE doesn't know exists or doesn't know the correct status of. At least, that's my experience with numerous different integrated VCS systems.