Source Control

[ Your other post was deleted. --Sneftel ]

[edited by - sneftel on May 4, 2004 1:02:41 AM]

in the other post (the one with no replies), click the "edit" button, and check the "oops! i double posted! delete this post!" checkbox, and then submit.

If it''s just the two of you, and you''re going to be working in separate areas of the code, then it''d probably be easier to just keep everything synchronized manually. Then you''d just need a good diff''ing tool, preferably one that can diff entire directories. I recommend Araxis Merge, but I think it cost $100 the last time I checked. Alternatively, you might want to try Beyond Compare... it''s cheaper ($30) and has a 30-day free trial.

Having said that, using a source control system would be good practice if you ever intend on working for a large company with lots of developers. It really isn''t too much of a pain, once you get used to the check out/edit/submit process. If you want to go this route, you might want to try Perforce as an alternative to CVS. If I remember correctly, you get to set up a server and two clients for free, and anything beyond that costs a fortune. It''s much nicer than CVS, but probably overkill for your project. Worth a look anyways. Good luck.

If you have more than one person working on the same code, then you have no choice but to use a source control system. You can choose to do it manually (a huge mistake), or create your own (a huge mistake) or get something like CVS to do it for you.

CVS is not my favorite, but it''s free and there are plenty of tools and add-ons for it. SourceSafe is ok for small projects. You might try Subversion -- it is new and it is open-source. Perforce is probably too complicated for what you need.

Here''s a web page comparing several source control systems: Version Control System Comparison

---

John Bolton
Page 44 Studios
Current project: NHL Faceoff 2005 PS2

Yup, I''d suggest Subversion for this as well.. Keeping stuff in sync should be pretty easy, as both of you can just work on their own copies and commit them when you''re done, you may have to manually merge a file every now and then but all in all this works pretty well.
If you use TortoiseSVN (assuming this is under windows), it is very easy to use as well, at least after you are familiar with the basic principles.

Subversion!!!!!

And yes, you should keep *everything* under source control. In fact, your whole project should *always* be buildable from a clean checkout from your source control system.

--
AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.
[Project site] [Blog] [RSS] [Browse the source] [IRC channel]

How do you recommend setting up the test builds though?

I mean, when i''m testing the networking code and my friend is testing the physics code, we''ll want two pretty substantially different versions of the client/server.

Is this not as big a problem as it seems?

Try to explain your requirements in a little more detail - I''m not sure I get it.

I think this really shouldn''t be any problem at all.. I am assuming that you are the one developing the main stuff and he''ll just have to make sure his code works with that. Sure, it can always happen that some of your modifications break his code, but in the end the physics will have to work with it anyway.

As long as it is because both of you modified the same part of the code, that''s no problem as Subversion would notify him of the conflict and he''d have to merge those changes. It is definitely easier for him to keep his version up-to-date this way than if he had to manually copy over the files and check which ones have been modified and whether there are any conflicts.

Obviously, some of these conflicts can''t be avoided. I mean, if you were to try out really major things that he shouldn''t get, I guess you could create a branch and later merge it, if necessary, but I don''t really have much experience with that.

Okay, I think I understand now..

I only want to commit changes into the repository once they are permanent, right? As in, my testing code shouldn''t make it all the way to the repository, it should be part of my working copy while I''m editing the functionality, and be removed once i commit the functionality.

That should solve whatever problems I was thinking I would have, thanks.

Testing code should definitely be in the repository, even if it''s not included in (non-debug) builds.

Specifically, if you are working with a reasonable sized team, you should consider making regression tests.

If you can do automated builds, regression tests are the next stage. A very good idea.

So then your process could be:

1. Checkout / synchronise
2. Build & Test (to ensure that nobody else checked in bust code by accident)
3. Write tests for new code mods
4. Write code for new mods
5. Repeat 3&4 until happy, and tests pass
6. Resynchronise with changes in repository
7. Rerun tests & fix any problems arising (i.e. from other peoples'' commits)
8. Commit changes

You will tend to discover that you end up checking in all sorts of non-production stuff, such as test data patterns (example: test levels to test the engine). That is good though.

Mark