1 person found this helpful
Depends on how many exactly, but the worst choice would possibly working on a singe file.
2-3 devs: xfl
4-5 devs: Shared Assets
5+ devs: svn repository
Thanks for reply.
Could you give me any idea how we can processed with "svn repository", you have any tutorials and any referance.
I know that "svn repository" but how we can bind with xfl or flash.
Waitting for reply...
Here is a tutorial that describes how to make subversion work with flash cs5. cs6 should be no different.
Make sure everyone on your team is commited going the extra mile of using it properly.
It is no No-Brainer, give your Team and you at least 3-4 days to test it, if you are already in the middle of production: wait til your next project.
Notice: The negative outcome of the mentioned article only occurs because two concurrent processes want to commit a change to the timeline at the same time.
If you use your xfl file mostly as a means to sort movieclips and symbols, you shouldn`t run into this problems.
So the main caveat with version control at the moment: Never work on the root timeline, if you try to open an asset in the library that is outchecked by a coworker you will get a warning message, that the current file is in use, thus preventing this problem.
From my experience xfl is a very robust file format, especially if you combine it with a BackupSolution (don`t make the mistake to think svn+tortoise is enough to keep your data safe in any case).
The Solution you mention is in most cases counter-productiv, because while having the feeling your project might be safer when split into different sub-projects, its in fact not, its more fragile.
A typical Usecase for a motivation to use the exact same Library Assets across multiple projects would be that you have differnt teams working on an iphone, android, browser, standalone etc. version of your app/game.
So say you have this 4 different projects accessing the same Library of Pictures, Sound and other stuff: If the mobile team for example messes up one of those files, all other 3 subprojects will not work either.
If you have really the need of using large quantities of assets like in the mentioned Scenario it is in my opinion better to have one LARGE project and use the document class of that as a means to "preload" other classes like main_mobile.as main_android.as etc.
That way you can keep the centralized folder structure and vicious checkout/checkin circles are less likely to appear. It has its drawbacks (longer compile time/size overhead if you don`t avoid the timeline completely etc).
The other option I see is selectively synchronizing the folders/files of the library (svn+tortoise can do that for you) but things can quickly get really messy if something goes wrong, so if you take this road in a mid-tier-sized project be prepared to have one person of the team only monitoring/managing the daily changes that can occur. I can`t think of an easier solution, sorry.
You will eventually have to figure out for yourselves which solution tailors best to the needs of your team and its very likely that you only will learn that in a "real" production work flow and also make some suboptimal decisions upfront.