I think I need to clear something up, because I forgot to explain it first.
@morganw, your idea sounds as a good "final" goal, perhaps for AGS 4(?), but I am concerned of the amount of work it will require, to develop, test and polish (and to teach users "new ways").
Frankly, my intention was to make an "intermediate" change, which would require relatively small effort, and get this into 3.4.2 update (or 3.5, whatever it be called), saving some trouble to people using source control with AGS games.
Taking into consideration what fernewelten said above, about sprite cache may take time to compile, I've changed my original suggestion a little. So this intermediate step could look like:
- The workflow stays generally same (import commands and menus);
- Game.agf stores references to all source files, if necessary - to which part was "cut out" to make a tile;
- if sprite was imported without source file (from a clipboard) then Editor creates it on its own, giving some dummy name (like spritexxxx.bmp).
- sprite cache is preserved and updated all along with import etc commands, BUT Editor supports full recreation of sprite cache from source files (assuming they are present). To keep it up-to-date with files modified on disk it will need a way to know when sprites were changed. For simplicity it could use same technique as with AudioCache: compare file's modification time. That's far from ideal. In the worst case sprite cache could be recreated with "Rebuild all files" command. (If that's too bad, then... hash?)
- question about deleting sprite from the editor... in which case the actual source file should be deleted? For example, game could have a note saying that particular sprite is autogenerated.
From this stage, it would be possible to move further into the system you suggested.