Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cross Platform Version Control Systems?

Posted by Cliff on from the writing-your-code-on-more-than-one-system-at-a-time dept.

ignipotentis asks: "I've been given the task to find a multi-platform (windows, macintosh, linux) version control system. Currently, CVS is being used, and it isn't working quite as we expected it to. We are creating large Flash files and CVS is having problems keeping everything straight. It apparently doesn't like the large file sizes. I was wondering what other decent version control software is available that doesn't require a huge sum of money?"

5 of 34 comments (clear)

  1. Hmmm... perforce? by j.e.hahn · · Score: 3, Interesting

    I like and use perforce. It's a great system, and there are mac clients (both OS X and otherwise) although those come with some extra restrictions (on file names and the like, due to mac platform issues.)

    However, it's not cheap. It's about US$600-700 per user to start and goes down as you add more users. It's worth it, but if you can't afford it...

    Subversion promises to be good, but it isn't there yet and I don't know if their client runs on windows or mac (or if there are any plans to port).

    There's a host of others, but I'm not familiar with them and thus won't comment.

  2. Make sure treating as binary by prenagha · · Score: 3, Informative

    You are probably already doing this, but just in case... Make sure you have CVS setup to treat the flash files as binary.

  3. Compress? by Lumpish+Scholar · · Score: 4, Interesting
    We are creating large Flash files and CVS is having problems keeping everything straight. It apparently doesn't like the large file sizes.
    CVS (and the underlying RCS files) can't effectively store diffs for binary files.

    Still, a binary file is a binary file; so why not keep compressed versions of your files under source control? If you have something like a makefile, have it generate a (read only!) copy of the uncompressed file as necessary. Provide an editing script that (1) uncompresses, (2) launches the editor of your choice, (3) detects when the uncompressed version hasn't been updated (and bails out of the previous steps), (4) recompresses, and (5) either removes or touches the uncompressed version (I haven't thought this through too carefully).

    You'll cvs rm the uncompressed version. The old versions will still live in the repository if you need them. (You'll also get some immediate gain from using smaller ,v files, especially at first.)

    CVS is remarkably good for cross platform source control for Ascii files. I used it for four years in a Solaris / HP / Windows environment; good stuff.

    And in case you didn't look:

    http://www.google.com/search?hl=en&q=cvs+large+bin ary+file+OR+files

    http://www.google.com/groups?q=cvs+large+binary+fi le+OR+files&hl=en&lr=&sa=N&tab=wg

    Good luck!
    --
    Stupid job ads, weird spam, occasional insight at
  4. If you don't need to track differences... by EvilTwinSkippy · · Score: 3, Interesting
    Since you are tracking binary files, CVS is the wrong tool. (It's great for ASCII so you can see the differences in source files.)

    What you are looking for is something to just keep the different versions straight. A few shell scripts (Tcl/Tk works on Mac/PC/Unix) and an SQL database (MySQL also works on Mac/PC/Unix) are all that are required. Ok, a scripting language, an SQL database, and a central file store.

    You add new files via a checkin script. The checkin script creates a simple naming convention. (I start at [thefilename].zero and work up.)

    The [pick your]SQL database gives you a little extra information than something file based. For instance, say you yank a file, but don't want to extinguish it. You simply mark it as deprecated in your tables. Say you need a certain version of each file for a demo. You link them together into a "Release".

    Again, this approach is primarily for binary data where you don't care about the differences between files, but you do care about keeping distinct versions.

    Is the implementation involved: yes, but only slightly more than trying to adapt off-the-shelf tools.

    --
    "Learning is not compulsory... neither is survival."
    --Dr.W.Edwards Deming
  5. Perforce or bitmover by Will+Sargent · · Score: 3, Informative

    Personally I like Perforce; it's simple, flexible, straightforward, and it's pretty aware of what its job is and isn't. There's a gui client for Windows, and a command line for Unix, and it handles multi-megabyte binary files just fine. But it doesn't do binary diffs well, and it's not set up for different media types. I've heard it can be pretty cheap if you talk to Perforce Sales right (floating head? Don't ask me.)

    One system that I've heard game developers rave over is alienbrain, which has built in support for a bunch of different media types and basically assumes it's dealing with a bunch of binary files or images from the get go.

    At 10K for ten users it's not exactly freeware, but from the reviews it looks like some game designers love it like their G4 powerbook. But that's probably too expensive.

    So another alternative is BitMover, which at the cheapest will cost you $400 a head. But there's also a leasing option that could work out better for you, and you get the warm fuzzies by supporting the software that keeps Linus calm and happy.

    Or, finally, you could talk to some CVS consultants. The guys at cyclic could certainly help you out with your problem, and probably more cheaply. At the very least, they should be able to tell you if your problems can be fixed in CVS, and at that point you should have a better shopping list of what to buy in a new system.