At work, we are using ASP.net 2.0 and VSS. VSS is a beast, we are continually having issues with people checking out files and there is no branching - makes it crazy. I know SVN/GIT is mainly used by open source developers, are there any downsides to ASP.NET developers using it? I have been pushing for SVN internally, but am thinking GIT might also be a great option. Our team is spread across 3 continents.
+2
A:
We are using SVN for a couple of ASP.NET projects, and it is working fine.
We have initially been working with AnkhSVN as the VS plugin, and it basically worked well for me, but company-wide it has caused some problems. We have now switched to use VisualSVN which seems to be more reliable.
awe
2009-09-15 11:48:00
We're also using VisualSVN and have found it works well for us in a small team environment. I can't compare with other SVN options but we got up to speed with it quickly and haven't had any major problems so far.
Simon Forrest
2009-09-15 13:39:52
+9
A:
I've used Subversion in a corporate setting before with great success. I haven't personally used Git in a corporate environment, but with distributed offices it sounds like a good fit.
Expect a big "hump" while everyone gets up to speed, but moving off VSS is definitely a good idea. We never looked back when we moved from VSS to SVN. I would encourage you not to skimp on training up on the new system. Get a few smart folk to read the documentation for whichever system you pick - and read it thoroughly. Then work out how you're going to use that, and communicate that appropriately. Suggest which bits of the documentation everyone else really needs to use, and give them enough time to read it. Source control shouldn't be done on a "press return and hope" basis :)
Jon Skeet
2009-09-15 11:48:01
We're also doing something similar here - were there any particularly humpy bits that we should look out for?
Paddy
2009-09-15 11:52:54
"We never looked back when we moved from VSS to SVN." - I agree ! I can also point out that the learning curve in using SVN after VSS is very fast.
egapotz
2009-09-15 11:59:09
About the humps - you should define a very clear folder structure at an early stage and document it so that everyone knows what it is and WHY it has that structure. Follow the basic recommendations in the SVN documentation, and select the proposed structure best fitted for your need (SVN proposes basically 2 structures based on the nature of the projects).
awe
2009-09-16 06:55:07
Another important thing to remember is to always do an update of the file you are going to commit right before you commit it. This is to make sure SVN has control on the difference between the file you edited and what is currently in the repository (someone might have changed the same file since the last time you updated). You will normally get an error if this is the case and you did not do an update before commit.
awe
2009-09-16 07:00:09
A:
I'm on SVN as well. I use Tortoise, but there are VStud add-ins as well.
kenny
2009-09-15 11:52:16
+1
A:
I think TFS is the way to go. Tortoise svn isn't good enough, and i don't think there even exists a decent visual studio add-in for Git. I haven't tried the commercial svn vs-add-ins they might be worth looking into. But the integration and every other feature in TFS makes it excellent with visual studio.
AndreasN
2009-09-15 11:55:17
That the intregration into visual studio works.That people don't have to learn a new tool, can just rigth click folders, and everything is automatic without bugs is important to get the rest of the organisation to adopt the tool.
AndreasN
2009-09-16 06:35:44
TFS gives an advantage of automatic builds and test - you need to do just pair of clicks. In SVN you can do this, but you need much more effort. Nevertheless, I'm using SVN because their SCM model better suits my needs.
flashnik
2010-01-07 06:36:48
A:
Git is the best version control tool I've ever used, and many that I've used have been better than VSS. So yes, I'd say switch, and switch to Git.
Lee B
2009-09-15 11:56:24
A:
My recommendations are:
1) Use Git, it makes really easy to create and merge branches
2) If you can't use Git, Use Anything But SourceSafe
DaniCE
2009-09-15 12:39:19
A:
SVN, no question about it.
- More widely used than other modern source controls. So likely your new hires will know it.
- Stable.
- Full of great features over CVS. (atomic checkin, global revision #s, external projects)
- Great UI (TortoiseSVN)
VSS is horrible. It is at best a functional "revision control system", but there is nothing concurrent about it.
Xerion
2009-09-15 13:26:58
A:
I have used both SVN and GIT. Both are far superior to VSS. If you are currently using VSS, SVN will require getting to intimately know your software. GIT will require even more understanding.
SVN can be operated by a few proficient users and non-proficient users just learn to update and commit. GIT will require everyone to understand branching, merging, shelving, and more.
Chris
2009-09-15 13:33:36
+3
A:
We're a 100% MS development house (C#, ASP.Net, SQL Server, IIS, Visual Studio, Office, etc), and we wouldn't touch VSS with a 20 foot pole. SVN is great. Get the free Ankh add-in as well.
Neil N
2009-09-15 13:37:42
@awe: I doubt it. I've heard they have a fairly involved proprietary system of that integrates version control, bug/issue tracking, automated testing and automated builds. They only threw together the POS that is VSS to appease corporate customers.
Neil N
2009-09-16 15:31:11
MS uses TFS. VSS wasn't too bad 20 years ago, but then again EVERYTHING sucked back then.
David Lively
2010-04-15 17:24:35
+1
A:
We've been using Git for ASP.NET development, thanks to Git Extensions, and have only two issues - the learning curve with Git, and handling complex dependencies between projects. Otherwise, it's been an absolute pleasure. Git Extensions provides the Git CLI utility, a Windows GUI, and Visual Studio integration, and we use all three interchangeably.
A lot of the complexity of Git comes from the fact that it is amazingly flexible, and the graphical interfaces can't really mask that. IMO, even though you don't need a repository admin you will need at least one person on the team who is interested enough to learn the concepts of Git, so that they can help others with more advanced features or when cryptic messages appear.
Our dependency management issues really arise from .NET, rather than Git. Our applications share a set of common custom assemblies which are interdependent on each other, and we are currently using nested submodules. Git works correctly, but it requires an effort to keep the pieces in sync. If we were larger I would definitely implement a build system here.
If you have a large team or code base then you need to think about the issue of integration so that you can smoothly pull things together. The way that Git enables you to create and link together repositories at will is incredibly useful, as is the wonderful branching and merging, but these features make it even more important to be systematic about your code management and build process.
We used Subversion with TortoiseSVN and AnkhSVN previously, and I would not recommend it. I used Subversion happily on *NIX, but it was grief with Visual Studio. Renaming items in VS screwed things up fairly frequently, and each time it was time consuming to fix. In addition, Git just does everything faster and better.
Stuart Ellis
2010-01-21 14:55:01