STACKLE - RSRC for LC Stacks - Are U Interested?

[Brahmanathaswami]

STACKLE: Really Simple Revision Contro (RSRC) l for LC Livecode (and 
perhaps any other document type)

"Pass the Baton/Stack"

Well the day has come. I'm going to build it. I needed this two months ago.

If you are interested, please reply off list. I will create a Google doc 
and invite anyone who responds in the next 72 hours... We take this 
discussion off line (Please don't ask me to renegotiate this decision) 
among those who are interested... hammer out the spec for V1 in a week 
or less and I will get it built)

Once we have a functional tool we will give it to the community, free of 
charge...

GIVEN THE FOLLOWING:

1)  the VCS discussion is for super brains; even if realized may involve 
a level  (GIT) of system management overhead/learning curve that  
developers focused on actual content production --  don't need, have 
time for, nor want to "go there."

2) We still don't have any other collaboration tool

3) We still don't have SFTP.

4) I don't see anything on the open market that does this (except 
Altuits old Magic Carpet which is off the map because it uses FTP and 
not SFTP)

It is here by proposed to build a "pass the baton" style stack 
collaboration tool.

I have this working in house of InDesign Documents. the core of the 
frame work for my app called "Grapple" is very simple. it's been working 
for a team of 10 for five years, flawlessly.

   I am "transpositing" this spec to LC stack but here is how it works

1) there is a repository on central server: e.g. /Volumes 
[public_html]/stackle-version-control

2) Projects are just folders on this server. e.g. 
/stackle-version-control/conquer-dev-isolation

3) there is a local repository on the user's machine with projects that 
match in ~/documents/stackle-version-control/conquer-dev-isolation

4) the server projects folders also have an 
/stackle-version-control/conquer-dev-isolation/archives folder inside 
each one.

The core code uses shell cmds

cp (to copy a file from the local machine to the server, vice versa and 
to copy archive versions)
mv  (aka "rename" files)

The RCS is handle by an old-fashioned RCS string tagged to the end of 
the document/stack file name.

conquer-dev-isolation_r1-co-BR.livecode

where the RCS string indicates, revision number, checked in or out 
status and the current editor.

the new app will use rsync instead...

There may also be a small supporting api requirement on the web server.

4) when a file is checked in the string is appended to the file name e.g

  conquer-dev-isolation.livecode becomes

conquer-dev-isolation_r1-c1-BR.livecode

a copy is made (we make lots and lots of copies!) this is saved in the 
local project folder and the file is posted to the central server in the 
project folder.

To check out:

1) conquer-dev-isolation_r1-c1-BR.livecode on the server is copied to the

/stackle-version-control/conquer-dev-isolation/archives/conquer-dev-isolation_r1-c1-BR.livecode 


2) the "top" version is renamed to

conquer-dev-isolation_r2-co-BR.livecode

and downloaded to the local version control... From inside the UI you 
can launch these documents. Work and save, work and save  (on 
conquer-dev-isolation_r2-co-BR.livecode)

At check in time, a copy of conquer-dev-isolation_r2-co-BR.livecode   is 
made locally and it's name is changed to

conquer-dev-isolation_r3-ci-BR.livecode.  and posted to the server... on 
the server the top file which is named

conquer-dev-isolation_r2-co-BR.livecode  is moved to archives (an exact 
duplicate of the one already stored in archives... redundant, I know but 
you would be surprised what can go wrong where having these is useful)

and the top file is now:

conquer-dev-isolation_r3-ci-BR.livecode

The GUI is really just a clickable "finder" index showing the files in 
on the server folder for a given project.

That's it --  beginning and end of story..  To my existing framework i 
plan to add three additionalal project files

conquer-dev-isolation_discussion.txt # no wikis, no google docs. just 
one simple text file for comments ideas etc.

conquer-dev-isolation_specification.txt # formal spec with V1 features, 
road map etc.

conquer-dev-isolation_time-log.txt # line delimited file

with file name, check-in date stamp, developer name and time spent on 
the stack/file (prompt on check in for developer: "How much time did you 
spend on this iteration")

This last file can be used for billing purposes, download, parse and 
invoice/pay  -- but V1 of STACKLE will not offer any further accounting 
"tools"

More details:

REQUIREMENTS:

WHO:

Admin=  LEAD(in charge)  HOST(just offers server space) CLIENT 
(corporate entity, manager, admin dev)

collaborators (works under lead)
participants (kinda open source on hosted files)
Paid devs (working for client)

But STACKLE will not  know and does not want to know who is who. A 
project may have a LEAD/CLIENT with some helping probono and other on a 
paid basis, but the app doesn't care.. that's a private arrangement

SERVER:

Admin - LEAD/HOST/CLIENT   must have a web server with root access admin 
rights, or at least be able to install SSH keys to the version control 
directory.

Collaborators/Devs must be able to generate SSH keys and send to LEAD

OUT OF SCOPE (What STACKLE will never do, at least not V1-3)

NO LOGIN/ACL FRAMEWORK

We do not provide any way for user to register, set user name, password, 
etc ... nothing.. LEAD must get ssh keys from DEVS (or grant them SFTP 
access and log into the server if that level of trust is part of the 
relationship: but STACKLE doesn't know and does not want to have 
anything to do with LogIn/ACL.

NO DELETE OR HOUSEKEEPING FUNCTIONS

The never ever offers any commands like this

rm
delete
put empty into url... [whatever]

copies just pile up everywhere. there is no opportunity for any user 
ever, to "blow it" by deleting any version. We have "super redundancy" 
Worst case scenario: server dies... no problem, collaborators have 
latest copies on their machines.  admin  + clients are responsible for 
their own housekeeping (you can accrue gigabytes of archives very quickly.

NO ADDITIONAL RESOURCES MANAGEMENT

Some mobile apps will only work with adjacent resources

SuperCoolWidget_r5-ci-BR.livecode
     /img
         /photos
         /audio
         /icons
     /data

STACKLE doesn't know about these.. it will be up to LEAD/HOST/CLIENT to 
give these or a subset of these to
collaborators/participants/devs.  LEAD/HOST/CLIENT may also give SFTP 
access to dev the server... STACKLE doesn't know about this and doesn't 
care and doesn't want to be part of any of that.


CAVEATS:  The long ID of the stack

if you are hard wiring the string which is the name on disk of your 
stack, which is in the last segment of of  "the long id of this stack" 
in the code... it will break, because the file name on disk is 
constantly changing. I stay away from that myself

I'm not sure how to get around that one, or if it even matters.

stack "/Users/Brahmanathaswami/Documents/_Gurudeva Memorial App 
Development/Gurudeva.livecode"

will constantly be updated to

stack "/Users/Brahmanathaswami/Documents/_Gurudeva Memorial App 
Development/Gurudeva_r5-co-BR.livecode"
stack "/Users/Brahmanathaswami/Documents/_Gurudeva Memorial App 
Development/Gurudeva_r6-ci-BR.livecode"

... so that's one caveat


If interested, email me off list soon.  I have more to add to the above 
spec, but will save it for the Google Doc.

After I invite the initial "crew"  we will close the door on that until 
V1 comes out.

I realize that some of this way of operating goes against the "open 
community"  way of thinking, but as a "production manager: (my official 
hat here)  I am tasked "getting the job done" and not with endless 
talking about something we need that never manifests, so we have to 
establish constraints to move forward efficiently. I want to  have this 
build the next 30 days. Once we get rolling I can't be dealing list or 
forum posts...  and if you want some input it will be appreciated... ten 
pairs of eyes are better than 2.

If it succeeds and is useful we can put it out there in the wild...

Swasti Astu, Be Well!
Brahmanathaswami

Kauai's Hindu Monastery
www.HimalayanAcademy.com