I’m not convinced it’s a killer. I just think it needs some special tools. It really wouldn’t be that hard to build a third party code review web app that integrated with GitHub via service hooks. Such a beast would know the export stack file format and present the objects in the same way the project browser does with visual representations etc.
To be fair it is a killer if you do not have such a front-end and want to have multiple people working in a rigorous way on a single LiveCode project ;)
As I said, that option was discussed and I (personally) didn't think it too bad an idea in principal - but it wasn't considered a viable option at the time (it added another required layer to the system in order to ensure it met the requirements we had of it) and it did suggest that perhaps reconsidering the approach was the best way forward to producing a fully cohesive solution. It essentially reduces the git/github choice to being a storage backend which isn't really something for humans to look at. Our feeling at the time was that we really wanted a solution which was entirely 'natural' in GitHub.
Of course hindsight is 20/20 and perhaps the front-ending should be revisited to see how integrated and natural it could be made. GitHub is obviously an important and powerful force in the world of modern software development (whether Open or Closed), but we have to ensure that LiveCode's use of it does not seem 'perverse' - otherwise it just gives another reason for people not to consider LiveCode. (Given that LiveCode already 'goes against the grain' in a number of ways, we don't really want to make the job any harder!).
From the point of view of the work Peter did put into VCS, none of it has been wasted. The 'stackdir' format we came up with is perhaps not the important point (I'm sure Monte, Peter and I could spend many hours finessing such a format to ensure it is bomb-proof, mitigates merge conflicts as much as possible and is actually tractable on modern FSs - Windows being a bit of a bear) - at the end of the day it just an on-disk representation of an in-memory data structure.
From an engine perspective it is probably the underlying 'stackarr' encode/decode which is the critical piece which has much wider applicability and the bit which would be high on the list to finish first. It does for stacks and objects the same thing the 'styledText' array format does for fields - it allows you to naturally manipulate the structure of stacks using arrays in script in a very direct way. Much more easily then having to introspect directly on live objects and the lcVCS or stackdir import/export could be implemented in script based upon it. The 'stackarr' concept has benefits elsewhere too - for example the project browser has to extract the information describing an object to do its job, as does the property inspector; and I know there are lots of tools out there which also replicate exactly the same process in one way or another (lcVCS just being one example).
Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps _______________________________________________ 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
