Multiple Programmers in Software Development. How do we work on the same code and it always be updated??

Question

This seems like something I should know by now, but for whatever reason I do not. I also am not having much luck searching on the topic.

A friend and I are starting a simple project together away from work, both of us are very young in the programming world and want to take on a simple educational project for our free time... My question is, we want to be able to work on the same project, and the files be updated accordingly, without us constantly having to share files with each other. I am certain that there is software out there that exists just for this purpose, or some kind of sharing client that we could use. Problem is, I don't know where to start looking.

Some simple advice on how, or what to use to help this project move along more smoothly would be great. And it's a big part of why we are doing it in the first place.

Update:

After some research I settled on Tortoise SVN. The simple right click addon for windows to update/commit files to your hosted server is very easy and user friendly..

Answer 1

Research Source Control. Here's a nice intro:

http://www.ericsink.com/scm/source%5Fcontrol.html

Many can be hosted online free or for a small fee so you and your partner can collaborate over the internet unless you are in a situation where you have a shared server then you can go that route with many source control clients (like SVN with tortoise and such). Otherwise, GitHub (not the only one) is a distributed source control system. May be a bit overwhelming at first but it's an example.

Answer 2

The type of software you're looking for is source control (also called revision control). It's a huge topic, but I would start by looking it up in Wikipedia, and then looking for a type of source control that works with the language and tools you're using. (Example. Team Foundation Server as an option for Visual Studio, SVN for a good all-around solution, etc.)

You're eventually going to ask for suggestions on which source control tool to use. For our team, we use SVN (aka SubVersion), which is a very good free open source solution that works with almost anything.

Wikipedia link:

http://en.wikipedia.org/wiki/Revision_control

Answer 3

"or some kind of sharing client that we could use"

Source control is probably the officially recommended approach, however the simplest way to share files is to install something like DropBox.

You sign up for a free 2GB account with a username/password shared between you and your friend. Then you install the DropBox client on both yours and your friends PC and use the shared account.

Once running Dropbox creates a folder under My Documents named "My Dropbox". Now, anything you do under this folder, such as creating, editing, deleting files and folders, will be automatically synchronized to the "My Dropbox" folder on your friends PC and vice versa. Internet access is all that is required.

You also get history and revisions of your files, so you can rollback and restore to earlier versions if needed. If you both work on the same files at once, just like source control, you will need to manually merge the files, but Dropbox saves a "conflicted copy" in this case.

I have used Dropbox myself for almost a year and am very happy with it's ease of use. I don't work for Dropbox or have anything to do with them other then being a happy user.

A "real" source control system primarily gives you automatic backups, ability to revert to earlier versions and managmenet of multiple users editing source code, but so does Dropbox.

Answer 4

If you are willing to learn a bit about Git then you can host your work at github.com and still both work on it separately.

Answer 5

in the last 6 months, i've moved over to git and am pretty pleased with it. but in general, cvs|svn|git are the most common open source SCMs (source code management) and any one of them should be able to meet your needs.

Answer 6

The simple answer is that you want some kind of revision control software.

The more complex answer is that having revision control is a lot easier than using it, or using it well.

If you're starting out, picking a tool that's easy to use is key. Subversion is a good choice because it's got some great GUI implementations, but still provides a lot of power and flexibility once you start getting into it at the command-line level.

However, which revision control system you pick is less important than cultivating the habits of use that will allow you to actually take advantage of your tools. Experienced developers using the best tools out there can still get themselves tangled up in poorly designed or poorly managed source repositories.

A few things to think about:

• If you aren't updating your repo frequently and consistently as a matter of routine, it won't be much use when you need it.

• Learning what different people have to say about best practices is useful to a degree, but sometimes the most important factor is simply that there is a standard, and that everyone involved understands and agrees to it.

• Repo organization is highly path dependent.
  Setup and teardowns is cheap when your project is starting out. Don't be afraid to be picky about organizational structure at the beginning. It may be the only time you can be.

Answer 7

There are two things that are important when two or more developers work on the same project. First are the tools used, and second is the agreed process.

The tool use, in your case is very simple. Pick a version control system and learn to use it. Choices are many, but the most important factor is the tool support. For example the tortuise type of tools are great for windows users (TortuiseSVN, ToruiseCVS, TortuiseHg) since they integrate into the windows shell and lets you see what happended to each file and directory by applying different icons on them (red exclamation mark for change, green ok and etc..).

The second, most important part is the process. Most teams break on that, and it takes time to adopt one and for all to follow it. You, and your partner must agree on the same process and you both need to follow it.

The process will include the basic folder organization, what will be put and where, how and when you will commit/checkout and what manner of code you will put in.

In my opinion there are two important things here:

1. The code in the repository must be always build able, for the other guy to continue to work without problems

2. Everybody needs to know what to put and where, e.g. one folder will be chosen for the source code, and the other for the database etc.

Here is an example of a simple process:

1. Install a repository server (svn, mercuiral etc.) . For you the only difference is tool support.
2. Agree on a common repository structure (Documents, Source, Extras)
3. Update on the start of each day
4. Commit often, before each commit update from the repository
5. On the end of each day commit