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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
