This conversation (about version control for LS projects worked on by teams, 
not really about BAF at all at this point) is beginning to go over my head. 
Long ago I worked in enormous projects (not far off 100 people) without 
comprehensive version control, and I guess we did something like 
Brahmanathaswami is describing here… frankly I think one has to be scared of 
systems which require command-line gnomes to operate them; likewise one has to 
be scared of team-support systems that don’t have some form of 
regression-testing and integration framework available as well as pure version 
control. 

To me the ideal is a system which can be explained to a team in an hour and 
which everyone can then stick to. My (fractured) reading of this conversation 
gives me the idea that we are approaching Gnome-ville, where really nothing can 
be explained in an hour.

I suppose this semi-rant is a plea to keep us less nerdy folk in the loop by 
explaining all the concepts of LC-working-in-a-version-controlled-context in a 
non-jargon-filled way. Any takers?

Graham

PS Just going back to the BAF, where does object-oriented programming come in, 
and what does it do to the current model in which LC operates? I think that’s 
another thread: it’s certainly another source of confusion.

> On 13 Aug 2015, at 04:37, Brahmanathaswami <bra...@hindu.org> wrote:
> 
> Richard Gaskin wrote:
>> So lets dive in with lcVCS in v7 today, and with any luck the project will 
>> attract enough contributors that they'll be able to handle at least some of 
>> whatever work may be needed to port it to v8 later, allowing you to maximize 
>> the time you spend on your externals which the community depends on as well. 
> Good positive move to take the energy from this somewhat tense thread to pour 
> into a useful direction. Though I still think it behooves Kevin to consider 
> VCS for the whole community --  it would be "HUGE" for his goals to make LC 
> one of the world's top languages.
> 
> I did study the Git book and that level of code control, played with it for a 
> while using some scripts on the web server... I found myself spending more 
> and more time on the cmd line than I would have liked. No doubt one who is 
> using GIT a lot will become very efficient.. It certainly is a powerful tool. 
> But for one level of user it's a bit time consuming and feels like it gets in 
> the way...
> 
> Meanwhile... I guess what I'm saying is, a full blown GIT management of 
> scripts is scary to me when I would be content with "document" control... 
> where a stack is a document and in some contexts it can simply be shared with 
> someone else  or "checked out" they work on it and "check it back in" ... 
> while it is "check out" I can't touch it. If there were some way to regress 
> and view changes that would be super, but not necessarily required. A simple 
> approach is, Person A gives it Person B and B makes improvements. If nothing 
> is broken... keep on going.. if person B messes up... we delete his version 
> and regress back one and keep going...
> 
> I made my own "magic carpet" in-house for InDesign document RCS and our team 
> loves it. We have, in 4 years since we abandoned Adobe's version control, not 
> lost any work or the the ability to regress to a previous version. 12 people 
> working on the same document repositories on the LAN server.
> 
>  It would be simple for me to adapt my model to include HTTP calls to the 
> server. The model is super simple: document is archived and checked in... if 
> it is checked out by someone else, you can't touch it. When someone else 
> checks it back in, another copy is made both on the server and locally. At 
> anytime something breaks (iteraton21.livecode) there's copies of the last 
> revision (iteration20.livecode)  in 3 places, on user's A hard drive, the 
> server and on user B hard drive. We can always recover.  Its simple but 
> robust "pass the baton." RCS
> 
> I realize that the super coders would find that simply too limiting... but I 
> think it works for a lot of not-so-edge cases.
> 
> A strong Video screen tutorial on lcVCS might be useful. I want to see if 
> that's where I want to go, or resurrect Magic Carpet... Perhaps there is, 
> within lcVCS a way to keep it that simple.
> 
> Monte... do you have documentation I can read somewhere?  I have a need 
> coming up here soon. I'm in the middle of working on a mobile app, and will 
> shortly reach my limits and then I'll want to pass it off to others to 
> improve, re-factor my code if necessary and fill out the features that are 
> beyond my competency.  So I'm scratching my head right now about just how to 
> do that. Methods now are painful: FTP to server... send someone an email. 
> manually change file names etc...
> 
> Maybe we need to move this to a new thread?  Anyone ever hear from Chip in 
> Texas?  (author of Magic Carpet)  Altuit.com not longer seems to be up.  
> Chipp seems to have moved on to other planets: http://blog.chipp.com/
> 
> Cheers from Hawaii. Monte, I hope your farm is not too cold down there!
> 
> Brahmanathaswami
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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


_______________________________________________
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

Reply via email to