CODEWITHSUNDEEP
version-control
jamiecon
jamiecon

Reputation: 1812

Appropriate Source Control solution

I have started a new job, where one of my first responsibilites is to import an ASP codebase previously maintained by an agency and now being taken in house. This codebase is currently stored in a Perforce repo.

My new company has a single Subversion server running on a Windows XP desktop machine. This is used by some of their internal developers as a basic code repo for small projects.

I have the opportunity to create an entirely new source control server for the company's entire codebase.

Once I have imported and got their developers running on their ASP codebase, I will also be commencing a new project, in C#, using Visual Studio which I will also wish to keep under source control.

I am completely open to any solution. We have a VMWare environment here, so anything's possible. I'd like to be able to import the history from Perforce using a tool if possible. I'd like good integration with Visual Studio, but there should be a standalone client or shell integration for developers not using VS.

Most of the company's developers do not currently use source control, so it's probably going to be a slightly uphill battle to persuade people of its benefits - thus, 'friendlier' solutions might be better recieved.

Cash is not necessarily a problem, but obviously cheap or free is a plus.

Upvotes: 2

Views: 186

Answers (2)

lbuchy
lbuchy

Reputation: 135

You could also try git. There is a tool to migrate perforce version controlled code to git called p4-git.

I've had good experience with hosting it on a Linux server with gitosis. It has great integration with visual studio as well as plenty of other IDEs (eclipse, netbeans etc.). For those developers using WinXP, there is also the very friendly git-extensions program (a gui for git on windows), or the native git-gui that ships with git. For those who like to do things in the shell, there is also that option.

Upvotes: 0

Brian Agnew
Brian Agnew

Reputation: 272277

If your new company has a Subversion repository already, I suspect they're already familiar with this.

I think that's a good reason in itself to go with Subversion (barring any features it's missing which are essential). Otherwise you're going to introduce another tool, developers will face a (possibly small) barrier of having to learn both, plus you'll require an administrator to look after both. I find there's an enormous benefit in teams using the same tools (even at the expense of missing a few features).

Upvotes: 4

Related Questions