Way to check files in and out with multiple developers_问答_开发者

I am a web developer working with 2-3 people including me. Our current setup is very simplistic. We try to let each other know when we are working on a specific file. We use FTP to edit our files.

Recently we have run into the problem of 2 people accidentally editing one file, or working on a local file then uploading when another person just did the same.

From what I have read I need some sort of control system. I have heard of subversion and mercurial. It seems that these systems may not be what I need though, since its just giving me different versions of the files. I don't know if it solves the issue of two people working on a file and overwriting each others work.

What are your suggestions for solving my problem?

Edit 1: I should mention that I would like to integrate with Netbean开发者_如何学运维s which seems to have plugins for Subversion available.

Edit 2: Is it possible to do this with normal web hosting? (using rackspace cloud site hosting). I do have a server set up at home that I think could handle being set up as a repository. (runs windows server 2007)

A version control system (VCS) is exactly what you need. The developers work off of the files in source control, and when a change is checked back in to the system, if changes have also been made by someone else to the same file, the system will merge the 2 sets of changes (sometimes assistance from the user will be necessary) instead of simply losing the previous set of changes.

Periodically, the website can be updated from the VCS repository.

With a team of just 3 or so developers, almost any VCS you might should work just fine. I've heard good things about Mercurial (though I haven't used it yet - I'm planning to try it out this month), and Subversion is really quite nice.

But I think anything you chose will be a major improvement over using none.

You can use subversion, it acts as a central repository for all your files and also handles the file conflicts.

If two members are working on the same file, and at the time they update the file in the subversion repositry, they will see an error notifying them about the conflict and also allow you to compare the differences between the two files.

Yes, you definitely need to get on some sort of source control. Besides just coordinating changes across multiple developers you'll be able to roll back to previous version of your software. You'll find it enables you to take chances with ideas, knowing that you can always just dump it and go back to a previous version. It can also be invaluable in tracking down bug reports when you've moved on to developing the next version. The list goes on and on, but, once you realize the value of source control, you'll never want the tightrope walking that coding without source control is.

Subversion is very popular, but I'd encourage you to hop over to http://hginit.com/ and read Joel Spoelsky's introduction to Mercurial. Let's just say he was not immediately sold on it, but reading through the tutorial, I'm seeing that it's probably a better way to handle things particularly when folks are distributed.

Yes it does solve the problem you are having. Take a look at the svn book for more details.

All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other's feet? It's all too easy for users to accidentally overwrite each other's changes in the repository.

Another problem this solves is accidentally making bad edits to a file and wanting to revert to a previous version. Subversion will operate against multiple files as a changeset (a set of changes that comprise a version of the code).

I've been in a similar situation (.zip files on network share with batch file that "locks" the zip file). Not fun and definitely prone to all kinds of errors.

Have a look here for a decent free book on Subversion: http://svnbook.red-bean.com/

Subversion is well suited to distributed development.

Each developer works on his own copy and checks in changes. All changes are reversible.

Stay away from source control systems that work primarily off of locking files then they are "checked out". The default mode for SVN is working without locks, merging changes and handling conflicts only when they arise.

Subversion is the most widely supported, with Linux supporting it out of the box, and TortoiseSVN (http://svn.tigris.org) as a Windows Explorer plugin.

Yes, a Version Control System is what you need, but not any VCS. I think you need a Distributed Version Control System. In my company we where using SVN for a long time (a small development team, same as you) but we never were too happy with it. A few months ago we migrated every repository to GIT and all the project management and repository hosting was migrated to codebase. We are very happy with the migration because of repository management and everything is much more simpler and straightforward.

Check the free Progit Book for an excellent introduction to Git.