[sldev] LSL SVN

[Brandon Husbands]

Where were these prototypes.. Id love to hear a ll response from this also.


>I've seen a couple prototypes working client-side.

Brandon Husbands wrote:
> I would like to see SVN functionality work for lsl code in game ..
>
> Anything think thats possible?
- Show quoted text -
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>

--
Tateru Nino
http://dwellonit.blogspot.com/


On 11/1/07, Argent Stonecutter <secret.argent at gmail.com> wrote:
> 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>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>