Run the same stack from two LC installs

[trevix]

Hello.
My standalone acts as a socket client or as a server: the standalone in a cell phone, opens a connection to the same version of the standalone in a TvBox and the twos talk to each other (communication scripts are on 2 substacks, server substack and client substack).

In order to debug my scripts, I usually run a copy of the same stack on two Macs with to LC installs, connected with WiFi. One is acting as client and the other as server.
When I debug, I often need to sync the scripts of both stacks: that is, update the server scripts or the client scripts, so to be sure that the final stack will always be updated...mmmh confusing to explain.

The point is: can I put the main stack on a shared HD and run it, in the same time, from both Macs, updating, saving, etc?
And, if yes, what should I be aware of? For example if I fill a global in one LC, are there going to be 2 (different) instances of the value or both LCs will share the same value?

Thanks
(PS: script only stacks, at this point of development, are not an option for me.)

Trevix

[richmond62]

I have a feeling running the same stack from 2 machines is going to cause a huge problem.

If, for instance, you make a change to a stack from machine A, how is machine B going to see that change?

[Cairoo]

Machine A will not know about machine B's changes and vice versa. If machine A saves its changes, and then machine B saves its changes, machine A's changes will be lost.

[trevix]

Machine A will not know about machine B's changes and vice versa. If machine A saves its changes, and then machine B saves its changes, machine A's changes will be lost.

I think you got the point.
Too bad.

I guess that this thing, that would also allow multiple developers to work on the same project, is different from, for example, a DB server or excel traffic handling, having LC to hold everything in memory.

Any suggestion?

[FourthWorld]

Machine A will not know about machine B's changes and vice versa. If machine A saves its changes, and then machine B saves its changes, machine A's changes will be lost.

I think you got the point.
Too bad.

I guess that this thing, that would also allow multiple developers to work on the same project, is different from, for example, a DB server or excel traffic handling, having LC to hold everything in memory.

Any suggestion?

Explicit check-in/check-out would allow parallel development, if not concurrently.

[jacque]

I do this all the time, though only on a single Mac running two different versions of LC. Since LC loads the entire stack into RAM it's quite do-able. But it's tricky if you aren't careful for all the reasons above. It's easy to overwrite changes from one copy of LC when saving from another copy. Also, changes from one copy won't automatically show up in the other.

But regardless, here's what I do. Make changes in copy 1, test, and when satisfied,, save. Immediately switch to copy 2 and run "revert" in the message box or from the File menu. The revert command just means "reload from disk, " so the newly saved stack will be reopened in copy 2.

You really do need to be careful because it's easy to lose work or forget which copy is most current. Keep backups. On the other hand, if you really screw up the copy you're working on and you haven't saved it yet, you can revert it to the last-saved one from the other copy.

[AndyP]

Interesting topic.

As you already have a client/server running between the two computers, can you not after a save on one computer send a "saved" message and have the second computer on receiving this message action a revert command to keep both in sync?

[trevix]

As you already have a client/server running between the two computers, can you not after a save on one computer send a "saved" message and have the second computer on receiving this message action a revert command to keep both in sync?

The two LC are not always connected and debugging the connection/disconnection, in my case, is the most time consuming.
Doing a "revert" command manually would not be such a problem, but this command restarts the main stack (my launch script takes a while), so this is not something that you can do to sync small things in the code.
To fix a single line of code, as of now, I have to fix it in both LCs (prone to errors) or save the fixed stack, close both, copy the fixed one on top of the other computer, restart both LCs.
After all, I guess using the revert method is much better...

[richmond62]

I do this all the time, though only on a single Mac running two different versions of LC.

I would be extremely interested if you could explain the rational behind that.

[jacque]

I do this all the time, though only on a single Mac running two different versions of LC.

I would be extremely interested if you could explain the rational behind that.

"All the time" was probably an exaggeration but I do use the method frequently. The reasons vary but are mostly due to laziness, from not wanting to make duplicate stacks (which would be safer but more confusing; which one do I want?) or to avoid trawling through backups to find something.

I guess the most frequent usage is to test modifications of a complex script and then be able to revert to one that worked previously after making a mess of things. Other reasons:

• Copy/paste controls that I want to revert without losing new script revisions.

• Copy/paste handlers that I want to revert without losing other new handlers that do work.

• Reverting new layout experiments that don't work out right.

Basically it comes down to wanting old behavior after messing up new ones. I don't usually plan ahead and open the stack in two versions of LC immediately. What generally happens is I get myself into a bind and then open the stack in a different LC version to find the parts I need to revert, unless I want to revert the entire stack at once. Of course, if I've already saved the stack then I have to do the tedious thing with backups.

[stam]

Basically it comes down to wanting old behavior after messing up new ones. I don't usually plan ahead and open the stack in two versions of LC immediately. What generally happens is I get myself into a bind and then open the stack in a different LC version to find the parts I need to revert, unless I want to revert the entire stack at once. Of course, if I've already saved the stack then I have to do the tedious thing with backups.

Is that not the very definition of version control?
That is the exact reason I use git - I can go back to any previously committed version, on any machine. Works fine with binary files like stacks - and even better with scrptOnlyStacks as it’s mainly aimed at text files.
Of course that does mean you have to commit versions, but with GitHub’s desktop apps that’s a doddle… and free

[richmond62]

I have an auto-save routine that saves stack backups with the name + the time: and, yes that does result in 'clogged arteries', but as I auto-save onto 1 of a pile of external PATA hard drives I bought for 10 Euros each . . .

[stam]

I have an auto-save routine that saves stack backups with the name + the time: and, yes that does result in 'clogged arteries', but as I auto-save onto 1 of a pile of external PATA hard drives I bought for 10 Euros each . . .

I have suffered enough critical hard drive failures to never trust a hard drive. Ever.
The other limitation is that you are bound by the drives - you have to physically have them with you for these to have any value.

OTOH, GitHub is free cloud based drive the remembers each individual version you save there and you can roll back and forward as you please, without having to resort to creative file naming. That means I can be at work, and check out a stack and work on it and recommit it, and then when I get back home, I can continue working on the same version, while having access to all previous versions in case I screw things up. GitHub does offer a handy desktop app which makes all of this process much more intuitive…

Of course, ideally, livecode would have an integration with GitHub, so that commits happen automatically on save for example. Maybe we’ll see that in the future…

[jacque]

Is that not the very definition of version control?
That is the exact reason I use git - I can go back to any previously committed version, on any machine.

The difference is that git is similar to backups; you have to know which saved version you need and it is all or nothing. Typically I only want some part of the original, usually while experimenting. It's easier to keep the last working version immediately available so I can grab the pieces I need quickly. Once I have everything working I do a save, update the other copy, and then continue tinkering where I left off.

Like I said, it's mostly just laziness. Having the last working stack open and ready is fast and easy. I also have TIme Machine automatically backing up to multiple hard drives, and Google backs up my important files to the cloud as well. The downside is that it's easy to confuse the two copies and you do lose work if that happens, which I have done. So tread carefully. My method probably isn't for everyone but it can be handy in certain situations.

[mtalluto]

I thank LiveCode, out loud, every day, for script-only stacks. Without them, version control would not be as valuable. I have been around long enough to remember the days before. I am much happier now that we can place our code into text files.

We have options when it comes to version control. We ended up using GitHub.com to hold all of our repositories. It takes a little getting used to when new. But, the benefits are far reaching. Yes, single-developer studios will have a reason to develop this way.

To maximize the value, breaking an app into logical behaviors and libraries is essential. It is easier to do this with new apps. Large legacy apps not actively developed may not be worth the work. All new apps should be made this way. There are many reasons to break your app into smaller text files logically. For one, the granular design allows multiple developers to work on the same app and rarely bump into each other. Should you bump into someone, that is ok. The compare routines are phenomenal in helping to resolve merges.

If a particular push breaks the app, you can quickly revert to a previous version of that section of code. The service provides tools to see who submitted the push. This allows you to contact the developer for clarification and, ultimately, a solution to a bug. You can go back to the very beginning and see every change in between. We have adopted submitting code as often as reasonable. When a feature is done, we like to submit it before working on the next item on our list. You can see the differences visually with the GitHub app for desktop. This will help you push only those files that address a particular item on your list.

Our workflow is to have a GitHub folder with each project in its sub-folder. You work off that directory from LiveCode. Quick changes can also be done from a text editor. You load your app as you would from any directory. This makes it easy to submit your work to the repo. You can even use the GH app to see what you have done since the last push. It is great for reminding you where you left off when you walk away from an improvement or bug fix after a day or more.

Each push allows you to provide comments. These are useful for reminding you what changed in a few words. We write our comments in such a way that we pull from the programmatically to build our change logs. We may write Fixed, Improved, Added as the prefix to every change in the push. We reserve Internal for comments we do not want in our change logs. They are for the team only. It may include other handy labels from [WIP] (work in progress) comments to more detailed information that would not be useful to our users.

You can pull the complete work of your project from any point in time. You can pull just a single file as well. This provides a lot of flexibility when you need it. Sometimes, I may highlight some code in a previous push and paste it into my working code to revert or compare a previous behavior.

If you are on a team of two or more developers, there is no better way to work on the same project simultaneously. No matter your team size, it is almost criminal not to use this tool. You owe it to your well-being, team growth, and, most importantly, your clients to manage your code with a version control system. The result is better software.