[sldev] LSL SVN

[Argent Stonecutter]

On 01-Nov-2007, at 09:16, Brandon Husbands wrote:
> I think interceptinmg the save button is a good idea and save it out
> and let a external SVN like tort handle it.. I am just tired of
> loosing my work :P

Yeh, modifying a few methods in the script editor itself would get  
everything that the client actually needs to provide the glue for  
scripts at least.

After thinking about it some more, I can see two approaches:

First: treat the file system as priority. In this model you have to  
explicitly load and save files from "file->load from disk" and "file- 
 >save to disk", and when you click the existing save button it would  
save it to a separate directory tree based on the in-world location,  
as a backup only. You'd get similar snapshots if the script window is  
open on a modified file when you exit SL, and possibly even snapshot  
every change or periodic changes.

Second: the in-world environment is primary, when you click "Save" it  
also saves to Scripts/[Avatar Name/]inventory-path/script-name.lsl,  
or if it's in a prim it saves to Scripts/[Object Name/]Prim Name/ 
script-name.lsl, and the same safety snapshots go to the same name  
with something like ".tmp" appended.

The "Avatar name" part could be just "Inventory", depending on how  
you want to manage it. The root of the source-code control tree could  
be anywhere, it wouldn't have to be in Scripts, so you could have a  
"Scripts/project-name" folder in your inventory.

Either way:

You could also have a "bulk download" tool to grab the script assets  
from a prim or part of the inventory, and bulk-upload to upload all  
the LSL scripts (without compiling them... they'd be saved with no  
bytecode and not running) in a directory.

Once either framework was in place, making other assets you have full  
rights to saveable and restorable would be an obvious extension.

Also, in either framework, you could implement "#include" (this is  
obviously an extension, but not really a hard one):

     #include <scriptname.lsl>  // comments here

would actually insert into what gets uploaded the literal text of the  
included file, with marker comments:

     // #include <scriptname.lsl>  // comments here
     // #begin scriptname.lsl <date>
     Literal text of ~/Scripts/scriptname.lsl
     // #end scriptname.lsl

The script editor on seeing this in a file, if you actually have that  
file, and it's at least as recent as the date, would remove the  
included text and the comment marker at the beginning of the #include  
line.

     #include <scriptname.lsl>  // comments here

If you don't have the file or it's out of date it would leave it  
intact. You could do what you want with it. For the in-world model it  
would look in the inventory (your inventory in the same folder, or  
the object's inventory) for a script it could use. You'd likely end  
up with something like this:

     #include <standard-funcs.lsl>
     string version = "$Id$";

     integer tuning_var_1 = 42;
     //...

     #include <project/functions.lsl>

     default
     {
     #include <project/main.lsl>

     #include <project/timers.lsl>

     #include <project/misc_events.lsl>
     }

     #include <project/sit-state.lsl>

     #include <project/transition-state.lsl>