Skip navigation
Currently Being Moderated

Multipal developer working on signal flash .fla file

Apr 3, 2013 1:28 AM

Tags: #air #flash #cs5.5 #flash_professional #flash_cs5.5 #cs6 #flash_cs6 #flashcs6 #flashpro



Any idea for many developer working on signal .fla file at a time.


I found two way, working with .xfl file or sharing library.


what is perfect for us in above both. if you have any other ideas please share with me.


please help me.




  • Currently Being Moderated
    Apr 3, 2013 4:48 AM   in reply to Dhaval (Dotsquares)

    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

    Mark as:
  • Currently Being Moderated
    Apr 4, 2013 12:24 AM   in reply to Dhaval (Dotsquares)

    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.


    Another one from Adobe

    Mark as:
  • Currently Being Moderated
    Apr 10, 2013 12:51 AM   in reply to Dhaval (Dotsquares)

    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 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.

    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points