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 <b...@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 >> <capellan2...@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@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 _______________________________________________ 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
