views:

193

answers:

8

Currently our team (web devs, one designer and one copywriter) all work on separate workstations but do our changes on the same dev environment (we all mount the same shared drive), it's a marketing site and not a web application, so no builds or deployments, we just push changes to the live site once they are done, but I think it's important for us to keep versions of files, especially serverside code, even if it only makes up a tiny percentage of our content (mostly static pages).

I'd like to use version control for our work setup, but I'm not sure if SVN or GIT will play along with more than one person checking in/out from the same dev environment. I've got existing experience with SVN, CVS, GIT, Perforce and PVCS but have always worked with individual dev environments.

I'd like a solution that doesn't require us to run separate dev environments as we lack the infrastructure.

+4  A: 

Most, if not all, version control implementations are intended to be used by more than one person. Both Subversion and GIT will happily do everything you require but you might find Subversion easier to get up and running with quickly. If you intend to host it in a Windows environment, take a look at VisualSvn Server.

The major difference between GIT and SVN is that GIT is a distributed system whereas SVN relies on a central repository. In software development, there are good arguments for using a distributed system but the needs you describe would be easily served by the much simpler SVN implementation (I think).

Another good reason for using SVN (under Windows) is that the TortoiseSvn client is one of the best examples of a user interface to any version control system. It is extremely easy to learn how to use and well documented as well as supported by the OS community.

It may also be worth investigating the various providers of hosted version control systems if you don't want the overhead of maintaining your own source control servers.

grenade
even with SVN or something they would have to change their working habits or set up a scheduled task to pull the latest version down. It sounds like they are used to changes being reflected on the server straight away.
mcintyre321
Yes, SVN was probably the way I'd go. Does the fact that we'd all be editing in the same file system/directory tree cause issues?
furtive
@furtive not at all. I've just understood what you mean by the filesystem/drive/mount being the same physical location for all users and this shouldn't be a problem, but I think you will find that version control will eliminate your need for the shared mount point. You can still use it, it's just that once you start using svn you'll probably no longer think of the filesystem in the same way.
grenade
@grenade agreed. Easing the others into it will be key. Thanks!
furtive
+1  A: 

You don't need lots of server hardware. Why can't each dev/designer/etc run the site on their own computer? You do have atleast one computer each? :)

GIT or SVN in that case is just a matter of taste.

truppo
A: 

"doesn't require us to run separate dev environments as we lack the infrastructure"

Doesn't make a lot of sense.

Presumably, each of you has a separate workstation. And your workstations are separate from your web server. Just guessing, but that's typical.

You can -- trivially -- each have a private development copy on your workstations. You can then use SVN to synchronize your various changes.

You can tag a version as "good to go".

Someone can -- when you've got everything looking right -- do an update on the web server to get the official version into production.

This doesn't require any more infrastructure than you already have in place.

S.Lott
+1  A: 

the way we used to do this at an old workplace was to give each user an account, and give the "project" and account as well. We would each check out a local working copy. the project (in your case it would be the tools that people in your business use i guess) would check out a copy too. Once the devs were all satisfied with a certain build, we would issue an update to the project working copy.

In your setup you say that you all have the same dev environment. do you mean you each have your own PC on the network, or are you sharing a PC? either way you should be able to each have your own svn accounts and local working directoires, so this would not be a problem.

darren
A: 

With SVN you can have the devs commiting to the server, and have one special user at the server checking out the latest version. So commiting you work involves commiting to SVN, then logging in to the server and do a checkout of the latest trunk.

You can use the same pattern with git and other decentralized version control systems. The advantage with these systems is that they don't enforce the central server pattern. Dev a could for instance push to b which then pushes it to the server.

disown
+1  A: 

Depending upon the amount of data you are talking about, an option to consider would be Dropbox ("secure backup, sync, and file sharing made easy"). It supports versioning, and lets you share folders.

It also has the benefit of providing offsite backup of, and remote web access to, your data.

RedFilter
Interesting idea!
furtive
+1  A: 

With svn, you can have each submit automatically trigger an update of the live site. Still having everyone work in the same directory is somewhat awkward (as it was all the time, anyway …), but old habits die hard and assuming people insist on that, svn does export its repository via WebDAV, so it should be possible to mount it as a network filesystem on the desktop machines.

Christopher Creutzig
+1  A: 
  1. "Currently our team (web devs, one designer and one copywriter) all work on separate workstations but do our changes on the same dev environment (we all mount the same shared drive)" Adding SVN would do away with the need for the shared drive. You would each work in a local directory that is checked in to SVN. Tortoise would be a perfect client for you.

  2. "it's a marketing site and not a web application, so no builds or deployments, we just push changes to the live site once they are done" A simple batch job (ANT script or other) could be written and given to each of you. Once the files are ready for deployment simply execute the batch and have it check out the latest files from SVN and copy to your web server.

Chuck