How do you track your source code?

ID:103942
 
Oct 30 2010, 9:21 am
Keywords: game_management

Poll: How do you track your source code?

Local PC Only 60% (57)
Private Remote Storage (Private FTP) 3% (3)
Shared File Synchronisation Service (DropBox) 18% (17)
Centralised Revision Control (CVS, SVN) 12% (12)
Distributed Revision Control (Git, Mercurial) 5% (5)

Login to vote.

For the interest of developers of supporting tools for BYOND, and looking into currently accepted practices, I have posted this poll. The main aim of this poll is to establish how source code is currently controlled by various developers on BYOND.

If you use multiple mechanisms for differing projects, please select the option that best demonstrates your preferred or most used mechanism. For the sake of useful results, I have decided to group certain proprietory mechanisms into general types:

  • Local PC Only - You have no cause to share most of your projects, and they exist on the local system only.
  • Private Remote Storage - You again have no need to share the code, but have opted for an off-site backup solution. Self-sent emails and private locations on hosting you only have access to fit here.
  • Shared File Synchronisation Service - This is your DropBox type services, where-by multiple users can "sync" files that are stored centrally on a server.
  • Centralised Revision Control - This is your CVS, SVN etc. This option fits both local only deployments, and shared deployments for collaborative work.
  • Distributed Revision Control - This is your Git, Mercurial etc. The prime distinction is that these revision control systems have no formal central master copy.


With this information, other developers looking to provide BYOND specific development services can target their products to best fit people's working practices. Thank you for your time and have a good evening.
Oct 30 2010, 4:53 pm
I <3 SVN. I've always used it to keep track of everything, and with a fancy-pants web interface, you can't go wrong (just kidding, but it is pretty neat!).
Oct 31 2010, 2:32 am
DivineTraveller wrote:
I <3 SVN. I've always used it to keep track of everything, and with a fancy-pants web interface, you can't go wrong (just kidding, but it is pretty neat!).

Do you happen to use a particular project structure at all? For example, a common one is the trunk/branch/tag structure.
Oct 31 2010, 2:54 am
I personally use the tree-named structure myself for 2 seperate projects, but I use Local-PC for the other dozen or so projects I have.

When I first began work on The Saloon, I had planned on adopting my own structure(not knowing much about SVN at the time), but quickly scraped it in favour of the trunk/branch/tag.
Oct 31 2010, 3:39 am
Stephen001 wrote:
DivineTraveller wrote:
I <3 SVN. I've always used it to keep track of everything, and with a fancy-pants web interface, you can't go wrong (just kidding, but it is pretty neat!).

Do you happen to use a particular project structure at all? For example, a common one is the trunk/branch/tag structure.

I never really used a lot of trunk/branch/tag when I started with SVN, thinking "oh, what's the point." Then I saw a successful usage of it. In my most recent project, I'm changing it to be a branch/tag/trunk structure, but all prior projects put in there are just often the folders of whatever they represent.
Oct 31 2010, 7:50 am
Am I the only one that also saves a copy of the source at various times during development instead of just updating the previous files stored in PC, Remote Storage, etc.?

It creates a lot more storage usage, yes, but I get cautious at times and wouldn't want an error to come up where for some reason the newer files would be erased.

Such as, building an update that significantly changes a bit of the project and compressing the folder to save using one of the four mentioned ways.

If so, how do you determine what should be archived like this?

I generally archive my projects development by date, and I save roughly every update unless it's a very minor update. A minor update to me is one that doesn't have a lot of code changes, or small visual changes. I'm not an artist so art isn't very high-priority to me. Code is only high-priority when it changes how the project is ran, or it improves a previous system.

Also, do you save a description of the version details within the project or is that done in a separate development log?
Oct 31 2010, 8:07 am
Maximus_Alex2003 wrote:
Am I the only one that also saves a copy of the source at various times during development instead of just updating the previous files stored in PC, Remote Storage, etc.?

No. I have numerous USB drives which I occasionally use if it's not annoying and is prudent to do so. However, it's usually just easier for me to go "tag this as a new version," and new copy it is.
It creates a lot more storage usage, yes, but I get cautious at times and wouldn't want an error to come up where for some reason the newer files would be erased.

Such as, building an update that significantly changes a bit of the project and compressing the folder to save using one of the four mentioned ways.

If so, how do you determine what should be archived like this?

A "landmark" is achieved (new system created, new part of the map completed, etc).
I generally archive my projects development by date, and I save roughly every update unless it's a very minor update. A minor update to me is one that doesn't have a lot of code changes, or small visual changes. I'm not an artist so art isn't very high-priority to me. Code is only high-priority when it changes how the project is ran, or it improves a previous system.

Also, do you save a description of the version details within the project or is that done in a separate development log?

Yes. When you commit to SVN, you are optionally (or, can be forcefully) given a "log message" to describe what was done with this revision. If you choose to use it, it can be a pretty useful thing. I used to never use them, and now I try to always summarize what I've done with an update. It helps if you choose to jump back a few revisions because something broke, or you want to test if a bug was present in prior revisions (then you can check the differences between each revision, and narrow down where a bug is), or things of that nature.
Oct 31 2010, 8:32 am
Revision control archives all commits. So you put your work in SVN, then do a few changes, when you're happy with it (the smaller the changes the better), commit it. So a large change to your game can be done as a number of small commits, and you can revert back to a given version that you were happy with, if something goes wrong. As DT mentions, commits come with log messages, which are displayed when you are selecting a version to revert to.

Mikau's Saloon project has a reasonable example of this:
http://code.google.com/p/thesaloon/source/detail?r=46

Not sure if Google Code does it, but SVN can display full difference between any two given versions, including deletions.
Oct 31 2010, 9:11 am
Ah, nice.

I'm more of a Local PC/Private Remote Storage so I don't deal much with SVN.

I have used it in the past to transfer files to multiple people, but I didn't like how some SVN programs got past my start-up blocks. Now that I have a more reasonable computer, I wouldn't mind using something like TortoiseSVN again.

Edit - I suppose taking certain resources like computer access and computer power affects which process to utilize.
Oct 31 2010, 9:35 am
The further expand on what Stephen was mentioning:

If you take a look at Revision 47, it will show you v0.01 with a message of what happened there, and a log file.

Now, if you jump to Revision 49, you'll see a new log file with a different version of the code. You'll notice those are both in the tag section, those are working copies of the source that can be downloaded, compiled, and ran as-is. They aren't fully functioning, but the purpose behind trunk/tag isn't that they're complete, just that they're working versions. Trunk being most up to date, and tag being a storage been for version numbers.

You can actually jump between both versions, although I wouldn't recommend it unless a version is broken for some reason.

I may make a post in Dream Makers fully explaining how SVN works, maybe get some more of BYOND's community using it. I think it would be interesting to see more open source projects on BYOND that we could take a look at, even if we can't participate.
Oct 31 2010, 9:50 am
I fully agree, Paul. It opens up the possibility for other developers to attempt to create and send patches for these projects, if the lead developer wants to accept them.

In an environment where people remain positive and constructive about code review, this can only be mutually beneficial.

I suspect as you noted, a lot of people just need revision control sold to them a little. Explain it's benefits in both collaborative work and just being a well documented backup mechanism. Too many projects get needlessly scrapped due to a poor backup regime I feel. You can post it here if you like, or Dream Makers. If you need some peer review, you can stick a draft on the forum here, and we'll provide some feedback for you.
Oct 31 2010, 11:52 am
Stephen001 wrote:
If you need some peer review, you can stick a draft on the forum here, and we'll provide some feedback for you.

That will likely be the best way to go about it, that way others can correct and expand on stuff. I like to think that I know SVN really well, now that I've been using it constantly for multiple projects, but I'm smart enough to know that's not the case. Best to let multiple people tackle it.