source code management questions
Author
My company is about to setup a game dev team (yeah!), but we've not used any source control system before. Here are a couple basic questions -
1) Our team is going to use Visual Studio 2005, what version control tool do u recommend? Visual SourceSafe (seems many ppl say it's bad)? Subversion (does it integrate well with VS)? Others?
2) How do you make team members have limited access to part of the source code of the entire project? The reason I'm asking this is that we don't want to share our source code (which took years to develop) with newly hired programmer, who might make a private copy and then go away. I'm not sure VS2005 or source control tools have built-in functions to handle similar things. My current idea is to divide the whole source into separate modules (say, graphics/network module) and each module builds to a lib/dll. Network programmers only get graphics lib/dll (but not the graphics source code) in order to build/test the project. Do you think this is doable (in the sense of project development)?
Thanks~
Subversion is the way to go.
I do .NET development professionally and personally and use Subversion for everything. Also, you can get paid professional hosting if you don't have the time or expertise to set it up in house (and you can switch to an in house server later if you ever want to). I use www.devguard.com for my paid hosting (the $15 / mo. package covers my current needs), but there are many others out there, www.wush.net and www.svn-hosting.com seemed decent to me to but I don't have direct experience as their customer.
As for clients, the TortoiseSVN windows shell extension seems to be the most used Windows client. I also use the command line client that ships with the base subversion install.
There are 2 Visual Studio integration projects, ankhsvn is a free one that is used by my previous employer (and developed by a GameDev member) and VisualSVN is a commercial one that wasn't really ready for prime time 6 months ago, but seems to be getting there now.
There are other clients and plugins of corse (RapidSVN, subclipse, svnx for mac).
As for permissions, it is easy to have seperate permissions for different repositories, and slightly harder to have different permissions for different places in the same repository, but totally doable.
Do NOT split a repository up for permission reasons, there are many good advantages to having all code related to a product or project in 1 repository. If you manage your different projects as totally seperate development efforts, then perhaps you can use different repositories for them (but don't need to).
I use 1 repository for all of my personal projects, 1 for my work projects, and another repository for the projects I do as contract work for a different vendor. And is only because the code ownership of those 3 categories is different, so I do it for legal reasons - not technical ones.
I do .NET development professionally and personally and use Subversion for everything. Also, you can get paid professional hosting if you don't have the time or expertise to set it up in house (and you can switch to an in house server later if you ever want to). I use www.devguard.com for my paid hosting (the $15 / mo. package covers my current needs), but there are many others out there, www.wush.net and www.svn-hosting.com seemed decent to me to but I don't have direct experience as their customer.
As for clients, the TortoiseSVN windows shell extension seems to be the most used Windows client. I also use the command line client that ships with the base subversion install.
There are 2 Visual Studio integration projects, ankhsvn is a free one that is used by my previous employer (and developed by a GameDev member) and VisualSVN is a commercial one that wasn't really ready for prime time 6 months ago, but seems to be getting there now.
There are other clients and plugins of corse (RapidSVN, subclipse, svnx for mac).
As for permissions, it is easy to have seperate permissions for different repositories, and slightly harder to have different permissions for different places in the same repository, but totally doable.
Do NOT split a repository up for permission reasons, there are many good advantages to having all code related to a product or project in 1 repository. If you manage your different projects as totally seperate development efforts, then perhaps you can use different repositories for them (but don't need to).
I use 1 repository for all of my personal projects, 1 for my work projects, and another repository for the projects I do as contract work for a different vendor. And is only because the code ownership of those 3 categories is different, so I do it for legal reasons - not technical ones.
Subversion is good.
If this is an actual company, you simply can't go wrong with Perforce.
As far as subdividing what people have access to - if you don't trust somebody enough to let them look at your source, don't hire them.
If this is an actual company, you simply can't go wrong with Perforce.
As far as subdividing what people have access to - if you don't trust somebody enough to let them look at your source, don't hire them.
Subversion is really good. We use it at my company.
My friend whom works for DICE (makers of battlefield) informs me that they use Perforce for source control.
My friend whom works for DICE (makers of battlefield) informs me that they use Perforce for source control.
This is not a SCM solution, but if you are working within a large team this product comes in very useful. TrackBack
Actually it comes in handy in any team environment (lone coder even) if you are working with a large codebase.
Actually it comes in handy in any team environment (lone coder even) if you are working with a large codebase.
I was very impressed by Surround SCM from Seapine Software. It's got a lot of features over VSS, and is quite a bit easier to administer than SVN. It integrates well with visual studio, and it's branching and merging capabilities are really good. At my last job, we used it with a root for a project, branches for forks of the project that went to different customers, and sub-branches for each developer as a sandbox. There was a lot more guarding from developers overwriting each other's changes that way. It was still possible, but only through malicious intent (yes, it happened to me, and the guy could have prevented it if he had just taken 15 seconds to do a diff, it really wasn't a difficult conflict to fix, I still hate him for it).
I use perforce at my current job and used SVN at my last. I would take SVN any day over perforce. CVS sucks, Alienbrain is much like perforce last I used it. MSVC integration is something I used to put alot of weight on a few years ago after spending a good deal of time using Alienbrain mostly through its MSVC integration, but these days it means nothing to me. Even perforce, which has MSVC integration I never use the source control functionality within the IDE. It's just not that useful to me.
#2 sounds like you can do with SVN, though I've never used svn externals before myself.
#2 sounds like you can do with SVN, though I've never used svn externals before myself.
SVN is the way to go IMHO. A few years back I worked for a *big* international (non-gaming) company which did a detailed internal review of various source control systems. What it boiled down to was to use SVN or ClearCase. I've not personal experience of ClearCase so I'm not going to recommend it although I've heard good things. I think it might also be too complex if your company is new to source control.
In SVN it is possible to limit access to certain parts (directories) in the repository. Usually you use it to give anon read-only access with only developers having read/write access. You can also give a user no access, which is what you want. All you need to do then is to make sure your 'trusted' developers do a nightly build of the hidden libraries into a lib/dll as you suggest.
That said, I agree with kyoryu totally. If you don't trust them, don't hire them. Also, there should be a section in their contract binding them to not disclose internal company info for a year after they leave your company. This includes finacial and corporate stuff as well as code.
In SVN it is possible to limit access to certain parts (directories) in the repository. Usually you use it to give anon read-only access with only developers having read/write access. You can also give a user no access, which is what you want. All you need to do then is to make sure your 'trusted' developers do a nightly build of the hidden libraries into a lib/dll as you suggest.
That said, I agree with kyoryu totally. If you don't trust them, don't hire them. Also, there should be a section in their contract binding them to not disclose internal company info for a year after they leave your company. This includes finacial and corporate stuff as well as code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement