Visual Studio source control question_问答_开发者

I have a team of two developers. I'd like us to have one source code repository. I am not familiar with Visual SourceSafe, can VSS work this way? I'm asking because I do not know what VS Team is, and we do not have it. We both have VS, one is 2010 beta, and the 开发者_C百科other 2008.

Or, is it possible to have us both use SVN, is that possible?

Can you use the same repo? yes
Can you work on the same project with differing versions of visual studio? probably not.

SVN is unrelated to visual studio other than plugins like Ankh so it doesn't matter to the repo what dev environment you're using.

VSS or SVN are similar tools for multiple people working on the same code. Multiple projects can exist in the same repo.

You can share the VSS archive over Windows file sharing and use it, yes. You can also grab Perforce from http://www.perforce.com and use the free 2 user license. It is seriously free for 2 users unlimited archive size with VS.Net integration and fairly easy to set up. SVN is an okay option, but I don't care a whole lot for the integration into Visual Studio. In my opinion the best SVN integration into Visual Studio is Visual SVN here: http://www.visualsvn.com/

The short answer: you could go with SVN for now since it's free, if you can afford it feel free to try VS Team System, stay away from VSS (all of these support multiple developers with one repository).

You mentioned VSS, VS Team, and SVN. I've used all of them them, so I can give you a bit of information:

VS Team seems to work well, the one issue is price, I believe it currently costs $2000+. I believe in VS 2010 this may be included in the cheaper versions of visual studio, so it could likely become a more popular option.
SVN worked great for me (we used the Tortoise client), and seems to be very popular.
VSS is not recommended and appears to be only minimally supported by Microsoft anymore, most people have gone away from this one.

All 3 are meant to support one or more developers working with the same repository. It may take a little time to get used to this, and there are certain best practices that people find work for them. Here are a few ideas:

If you have shared code ownership, or multiple people working in the same files, you may have more conflicts that have to be resolved on checking code in. This could be minimized by informal communication among developers to better coordinate, etc.
In general, developers should get all the latest code and make sure their changes work to build the code-base before checking in. There are continuous integration servers that will check this automatically.

SVN is great, particularly if using the TortoiseSVN windows explorer plugin. This will let you see which files you've changed via explorer. You can allow access via svnserve which is included if you are working from the same local network. Otherwise you are better off using Apache. There are instructions on this included with SVN.

As far as using 2 flavors of Visual Studio, it is unlikely to work as a long term solution. The issue is that the project files are incompatible, so that you will be unable to share them, potentially leading to code trouble. Furthermore, Visual Studio 2010 contains extensions to C# and C++ that are not available to 2008, and if your partner uses any of them it won't be obvious until you try to compile.

On a good note, Visual Studio 2010 is free to use until April(?) at which point you can upgrade. Otherwise a copy of VS2008 standard is ~$200.

Short answer yes ... but I doubt Microsoft will being doing much with VSS since they are putting out Team Foundation Server (TFS). I think it is fair to say most people are moving away VSS.

You might want to look at other options like SVN or Preforce as others have mentioned. Check out wikipedia article

Also check out Eric Sink's post on source control systems, it is a good primer on what they do in general (his company puts out a source control system so he has a lot of knowledge in this area).

One thing to think about is bug tracking and if you want it integrated with your source controls. Usually when the are integrated (or part of a suite) they call themselves "Application Lifecycle Management" software. So something like TFS has bug\workitem tracking as part of the product, so source code checkin can be associated to a bug or requirement.

tep