Home AMX User Forum NetLinx Studio

Version Control Systems

Hi Folks, is anyone using some sort of version control software system like Subversion or CVS?

I'm working in an environment where there is more than one programmer and we are starting to get batches of files spread all over the place with potentailly disastrous consequenses.
We want a central repository where we can keep everything but so far the systems available, like the ones mentioned above, seem to be overkill.

Surely there are plenty of folks who work under the same constraints, what are people using to do this with AMX?

Something windows based would be best for us too as most of the available systems seem to be linux based.

All help and suggestions greatfully appreciated.

Cheers, Mark Gibson
University Of Wollongong

Comments

  • filpeefilpee Posts: 64
    We use VisualSVN on our server with TortoiseSVN on the client machines.

    Sure it might seem overkill but it seems to do the trick.
  • a_riot42a_riot42 Posts: 1,624
    CVSNT + TortoiseCVS because its free.
    Paul
  • Spire_JeffSpire_Jeff Posts: 1,917
    I have also started using TortoiseSVN. I currently only have me working on the code, but it helps me migrate code changes between projects and also gives me another backup. I got a free SVN server and client from them and everything is running on Windows based platforms.

    Jeff
  • Spire_JeffSpire_Jeff Posts: 1,917
    I have a new reason to explore hosted Version Control platforms. Has anyone used any hosted solutions they feel comfortable recommending?

    Thanks,
    Jeff
  • a_riot42a_riot42 Posts: 1,624
    Spire_Jeff wrote: »
    I have a new reason to explore hosted Version Control platforms. Has anyone used any hosted solutions they feel comfortable recommending?

    Thanks,
    Jeff

    You mean send all the projects offsite to some website to maintain? I wouldn't do it myself. But it likely sounds like a good idea to management, especially if it means a smaller IT budget (usually it doesn't work out that way), so I can see the appeal.
    Paul
  • truetrue Posts: 307
    Every company I have worked for that has had a programming position - whether it be an actual progrmaming house or AMX programming - didn't have version control when I started (shared FTP on production with file renaming? yes. windows synced folders? yes. vcs? no...), and had it when I left. Usually they would keep it after I left though completely screw it up somehow.

    The company I work for now still doesn't have a server. I use subversion/kdesvn or git for dev at home, subversion with smartsvn or tortoisesvn at work.
  • a_riot42a_riot42 Posts: 1,624
    true wrote: »
    Every company I have worked for that has had a programming position - whether it be an actual progrmaming house or AMX programming - didn't have version control when I started (shared FTP on production with file renaming? yes. windows synced folders? yes. vcs? no...), and had it when I left. Usually they would keep it after I left though completely screw it up somehow.

    The company I work for now still doesn't have a server. I use subversion/kdesvn or git for dev at home, subversion with smartsvn or tortoisesvn at work.

    At work I ended up converting an old dusty desktop that had long been forgotten to a CVS server. Installed a new drive and it works like a champ for our minimal needs. I've gone the "synced folders" way as well, and just had too many problems, and CVS works so well I can't really see investing in another paradigm.
    Paul
  • annuelloannuello Posts: 294
    We're using Subversion, with TortiseSVN and WebSVN front ends. Once it is set up it works rather well. WebSVN has good online read-only diff-ing of text files (.asx, .axi) which is useful to review changes between versions. We also use Subversion for our documentation (Visio, PDF, Word, Excel). I haven't figured out if/how we can review/diff Word docs online, but it is still good for version management of such files.

    The important thing when migrating from "shared file" collaboration is for everyone to understand that the files on Subversion are authoritative. If you have important changes locally, commit them to subversion, otherwise they are not authoritative. It can be a bit of a culture-shift for many, but it is well worth it.

    As for filesystem structure in Subversion it is probably worth having one person decide the layout and perform the initial creation/population of the filesystem, prior to granting access to others. This gives you a chance to put everything in logical places, and new-comers can then follow the pattern. I had exclusive access to ours for approx 9 months before we extended access to others. Lucky me...

    I haven't tried it on mine yet, but you can apparently set up Subversion on a ReadyNAS (www.readynas.com). Not bad for a few hundred dollars, though you may need some Linux skills or at least some patience to read all the gotchas first.

    Roger McLean
    Swinburne University
  • AuserAuser Posts: 506
    filpee wrote: »
    We use VisualSVN on our server with TortoiseSVN on the client machines.

    +1. The Windows based authentication in VisualSVN makes managing permissions for users easy.
    annuello wrote: »
    As for filesystem structure in Subversion it is probably worth having one person decide the layout and perform the initial creation/population of the filesystem, prior to granting access to others. This gives you a chance to put everything in logical places, and new-comers can then follow the pattern.

    Agree, but it's still possible that you won't get it quite right first time round. Opening up a sandpit server to users prior to switching over to a production server a few months down the track is a possibility that should be kept in mind.
  • annuelloannuello Posts: 294
    Auser wrote: »
    Opening up a sandpit server to users prior to switching over to a production server a few months down the track is a possibility that should be kept in mind.

    That's a good idea. I guess it depends on the size of your organisation and how much "damage" can be done by mis-use. The other two points I forgot to mention are:
    1) When using TortoiseSVN, users will have to adapt to a few changes, particularly with renaming & deleting files. These should be done using the TortoiseSVN sub-options rather than Win32/64 native options.
    2) Subversion systems are not a substitute for communication in your team. When there are clashes during file check-in, staff really should talk to one another to resolve the issue. Do not expect the system to fix it for you.
Sign In or Register to comment.