Recreating a binary stack from xml text

[gcanyon+rev]

Agreed that a full implementation would be better; I'm just saying that, compared to the present setup, where there is no source control whatsoever, a system that at least allowed merging code in a controlled fashion would be a huge improvement. 

I would hope we can do better than card-level locking, but better that than nothing at all. 

Sent from my iPad

On Feb 20, 2012, at 11:51 AM, Bob Sneidar <bobs at twft.com> wrote:

> Ick. So easy to lose track that way. Having multiple independent copies of a project floating around is in my opinion to be avoided at all costs. In a real multi-dev system, the control would have to update the existing client copies each time an item was checked out or checked in, so that each user would have as up to date a copy as possible. Ideally, when an item is checked in, each user with something checked out would either get a notification that there were updates, and be allowed to choose to update to the latest revision, or it *could* be done automatically. However, due to the nature of the IDE, you would have to account for running scripts on the client end and not update until an idle time. 
> 
> It could be done, but it would be complex. I think at the very least, each user would have to checkout a card, and that card and all it's objects would be "locked" for modification by the versioning system. That is where a database would be handy. A system which used both XML for the object descriptions, and a database that kept track of client checkout, object locking and date/time stamping would be ideal. 
> 
> It seems LC multi-developer systems are trickier than otherwise, because a project is not just code as it would be in a C or Java based system. There are objects which, although typically static, can be altered, and can affect the execution of the code. But if all you cared about was keeping track of changes made, and you didn't care about multi-developer checkout of objects, simply recording changes might be enough. 
> 
> Bob
> 
> 
> On Feb 18, 2012, at 9:07 PM, Geoff Canyon Rev wrote:
> 
>> I didn't store the ID because when I wrote it (and for long after that) the
>> ID was immutable, so there was no need to store it because it couldn't be
>> set.
>> 
>> That said, I'm guessing that a monolithic XML file is not the way to go
>> here. Someone who knows git better than I will correct me, but it would be
>> more useful to store each item as a separate file within a directory
>> (hierarchy).
>> 
>> I'm tempted to say that there are some things that wouldn't be
>> worth/necessary to put into version control. Heck, you could start with
>> just the scripts. So if I'm working on a project with you, we could agree
>> ahead of time that I'm not in charge of design, but just code. You could
>> send me a copy of the stack at some point, and an IDE tool would be able to
>> use basic git commands to refresh/update the scripts of all the objects.
>> But because we agreed, I know that if I move an object, or create a new
>> one, or delete one, that won't be captured. Maybe that's not ideal -- if I
>> find that something is a pixel off, that's a pain not to be able to fix it
>> right there. But it would be somewhat simpler to implement.
>> 
>> On Sat, Feb 18, 2012 at 8:43 PM, Alejandro Tejada <capellan2000 at gmail.com>wrote:
>> 
>>> Interesting enough, it does not include the ID among
>>> the properties saved as XML:
>>> http://www.inspiredlogic.com/mc/ripperoutput.html
>>> 
>>> But adding this, and others new properties, should be a
>>> piece of cake for professionals developers in
>>> this platform. ( Not me! :-D )
>>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode