Well, I have a non-best practice success story, if that's any help.
I have a very unorthodox setup, but it works really well considering. I
have a home office linux server running off a cable modem. I run all the
standard linux goodies off it including Subversion. Pretty much all
users are on Windows and run TortoiseSVN. I make repositories by hand on
the command line. Holding all assets in the repository takes up a lot of
space. Using the repository for video work is not feasible. We worked on
a multimedia cd-rom, and the entire repository for the 300MB of work
files is approx 1.8GB. Most repositories aren't that big. I also
*blushes* have a single classpath for all clients. This is because when
I first started using Subversion it was for my own personal use. Now we
can't see how we ever worked without it. I haven't used Trac, nor do we
have any post-commit hooks for mail or anything.
Based on my non-best practices setup, here's what a best practices setup
would be like:
Crunching assets can take a while. Get a dual cpu setup to crunch those
big flas.
Make sure you have a good terabyte of space, its a disk hog, too.
Use post-commit hooks for email, and use detailed log messages to cut
down on communication overhead.
Write some shell scripts (or whatever you like) to handle the creation
of repositories, users, and hooks. This may sound hackish, but the
reason I put this as a best practice is because I don't think any
pre-packaged solution can come close to a good shell script here.
Based on the best practice above, naturally you should be running all
this on a Linux/BSD box.
You really should have someone as a designated subversion admin who
knows the ins and outs. You absolutely need someone there who is
available and can provide training wheels for new subversion users. It
ain't going to be easy.
Have a classpath folder for each client, along with a separate
repository for your core classes. Use inheritance heavily. Example: You
have a Menu class such as:
com.company.gui.Menu
You customize this menu for a client:
clientMenu extends com.company.gui.Menu
But you also use com.company.gui.Menu for a bunch of other projects. So
have a 'main' classpath repository that contains all your core classes,
and use inheritance for your individual client needs by having a special
classpath within the project's repository. Yes, this requires two
updates, but it is a better solution.
I think the main issue with version control in a web/flash environment
is workflow. Getting project managers and designers to all comprehend
the intricacies of version control takes finesse. I just tell project
managers to 'right click and update'. I tell designers its like ftp,
only cooler. And programmers just get it.
I hope you find this useful, but more importantly, I hope it creates
some discussion. I don't pretend to know a lot about version control,
and perhaps there are others out there who can give me some good schoolins.
Robert Sandie wrote:
On my fourth large flash project and have yet to come up with a sound
CVS system/workflow for Flash. Does anyone have any best practice
stories regarding version control and integration into web development
projects? Would love to hear.
Robert Sandie
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
--
_________________________________________
< __ __ ____ >
< | | \/ ___\ Chris Hill >
< | | / /_/ > [EMAIL PROTECTED] >
< |____/\___ / http://ubergeek.tv >
< /_____/ The Smell of Geek! >
<----------------------------------------->
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
