Asset Sharing - Splitting up a big fla for easier teamwork

Question

Hello,
(This contains:  A question for best practice + feedback and bug-reports for Author-time Sharing)
I'm currently working in a game project with Flash Pro CC. It actually consists of multiple games (a handful) that all use one fla as asset-source. So it has mixed content, all game-specific assets + general assets (e.g. lots of re-used ui components).
We are trying to split up the fla into one general fla and distinct game-specific flas (or "sub flas").
The specific flas shall also contain the assets from general fla, but changes to the general fla shall also affect the lib items in the specific flas. And an auto-update is also needed (for convenience).
So the target is 'importing a whole library' from one fla into another. Is there an "easy way" to do this?
NOTE: the general source-fla with the files to share has a size of 35 Mb and contains about 600 symbols that are to share.
Here are my efforts / experiences so far:
On your help pages are communicated: Runtime Sharing and Author-time Sharing.
I thought that the first one, Runtime Sharing, is no good choice, because it comes with bigger preparation effort (urls) + RSL-symbols have to be AS-linked also, which is not needed for much of our symbols. And then it seems to be focused rather on client's experience (e.g. loading times).
So I tried out Author-time Sharing.
First I noticed that one must manually declare the origin-target-relationship of each single symbol that shall be linked to a source file. (meaning to adjust properties and browse to sourcefile + symbol in its library).
Is it a bug? In CS4 this was done automatically (simply on paste of a symbol of different fla). The whole workflow is so inconvenient that I have the feeling that a large-scale of this feature is not suggested. Or am I missing something?
Anyway, I wrote a jsfl-script that takes care of that (for all wanted symbol items).
It seemed to work well within a small test case (fla with 250 kb, 13 MovieClips, 7 images).
But when I applied it to our project (35 Mb source file, 600 symbols) the script will not come to an end and Flash consumed increasingly more RAM.
The duration of sharing just one symbol seemed to take over 10 seconds already.
But there seemed to be also a bug that caused that some of the "want-to-be"-shared assets were not properly replaced, but instead created anew and were put into a directory "Duplicate items".
After a little trying I found out, that this regularly happens to nested symbols, whereas these were not shared before that 'parent' symbol was shared. At least I guess so.
As I found out there is an undeniable connection with source-file size and complexity of symbol structure.
So, is this feature only recommended for slim source files with a few symbols of low complexity, meaning "no nested symbols"? (This would be a real pity for us.)
Machine Details.
Flash's Latest Updates are installed, Windows 8.1, 64 bit, CPU: 2 x 2.2 GHz, 8 Gb RAM
Best Regards,
Yves

Answer 1

Thank you, Mohan.
Sorry for my late reply, I was a busy with other stuff the last days...
To the topic:
Yes it helped a lot already... I should have read better.
It is a bit less intuiitive than I had expected, but this will work. The problem with the "duplicated items" folder is gone.
However, I still wonder about how changes of the root clip (in origin file) take effect in the sharing files.
I made some tests, and these are my observations, of how lib items are updated:
folders:
empty folders- not (of course, the are no symbols)
full folders - yes - originals remain as copy (with 0 uses in target-sharer)
symbols
moving and renaming in origin file is recognized in target file. however, "old" library items (as they were regarding their name and path) are retained, with 0 uses (if they were not used elseweir in the target file), and new lib items are created with the new names / pathes
But IF they are used elsewhere in target file (e.g. as instances lying on stage) their origin will not be updated, and in properties they still point to the original symbol with the names they had before moving / renaming (which is not existent in origin file anymore)
A not so good thing is, that if such symbols had an AS-link, they would exist twice in target file, both retaining their AS-link. So there is potential for conflicts...
This behavior is still a bit inconvenient. One had to remove the deprecated symbols and (before that) swap the already-in-use symbols.
I made 3 example files for you to reproduce what I have encountered.
1 origin file, and 2 target files, which contain some remaining library items, that should have been deleted / swapped.
In case of the 2nd target file, the rootclip lies in folder with different name. (though I have observed no difference in their behavior)
https://dl.dropboxusercontent.com/u/3161948/ATS_TheOtherRootClipExample.zip
And again the question: Am I doing something wrong? Or is there a way one can avoid this?
(Changes to the source file, like renaming and moving, will be definitively needed!)
Thanks,
Yves