Version Control

[MrWizard]

I have Googled and searched the runrev site and forums with no avail . Is there no way to save a runrev project in a version control friendly format. That's a really big problem for projects of any size.

Thanks.

[FourthWorld]

How many other programmers are on your team? There are some solutions available, so I'll be we can point you in a useful direction once we understand more about your team's needs.

[MrWizard]

It's not a question of team size. It's a question of being able to see the code differences between various versions. If a bug shows up in a certain feature, it sure is nice (ie. imperative) to be able to go back and see what has changed since that feature worked.

I would like to use subversion...which is fine for actually keeping history, but I can't use any diff tools to compare the different versions.

Actually, I suppose the question isn't really version control, but more version comparison that is the issue.

[mwieder]

At the moment diff tools are DIY addons. If you're using glx2 or tRev you've got automatic archiving of versions available. If not, Chipp Walters has an altArchive plugin you can install and use. Then the only snag is dealing with the fact that rev doesn't allow you to have two stacks of the same name in memory at the same time, so you need to rename one temporarily before loading the second to compare.

[MrWizard]

If I knew the structure of the .rev file, I could break out the internals independently and commit them to subversion. Then, I could diff the non-binary parts with whatever tool I like.

It seems this is a major stumbling block to rev getting traction in too many large scale products. Even REALBasic figured that out and now offers two different project file formats to address this exact problem.

I am a C/C++ programmer, and I have been chomping at the bit to move to higher level languages for everything that I can; but this is a real problem.

[mwieder]

Believe me, I feel your pain wrt version control integration. But diffing and checking in/out parts of a stack isn't that difficult. If you're interested in diffing the scripts then just use

put the script of <someObject>, as in

put the script of this stack
put the script of button "helloWorld"
repeat for each control tControl of this card
put the script of control tControl
end repeat

Getting more into version control, you can also describe a control by listing its properties and saving the result.

[MrWizard]

Thanks for the suggestion. I suppose that approach would be a good start to a rev plugin that could be used to generate "source files"....I need to ponder that.

Believe me, I feel your pain wrt version control integration. But diffing and checking in/out parts of a stack isn't that difficult. If you're interested in diffing the scripts then just use

put the script of <someObject>, as in

put the script of this stack
put the script of button "helloWorld"
repeat for each control tControl of this card
put the script of control tControl
end repeat

Getting more into version control, you can also describe a control by listing its properties and saving the result.

[malte]

Would anyone be willing to tackle a SVN upload and compare plugin for rev?

Describing a stack in another format is not that much of a problem. It just has a few stumbling blocks. Would XML be a good choice to export? Right now it would be output only though, as in current versions of Rev, the ID of a control can not be set. Future versions of rev might be able to do so though, then recreating the stack from the XML would be possible. At least for the non binary parts. Images could also be contained, if the imagedate gets base64 encoded. Embedded Audioclips and Movies would be problematic though. Anyone around who would want to write a div analyzer for such an output format? Or something that could be used to throw it into SVN from rev directly?

All the best,

Malte

[MrWizard]

I would prefer a system agnostic approach (not everyone uses subversion). Frankly, the rev project needs to be broken up into smaller components as well. Otherwise multiple programmers can't easily work on different parts simultaneously.

If I were at rev, this sort of thing would be HIGH on my list of priorities...maybe the guy that was working on iPhone support could work on it. (Damn you, SteveJobs)

[FourthWorld]

It's not hard to architect in a way that supports multiple programmers for the sorts of projects Rev is well suited for.

In my 20 years of developing I've only managed one team that had 14 people working on stacks, and most of my projects have between two and five developers sharing work. All of them have been managed by making each UI stack and code library a separate stack file, easily handled with an ad hoc system you could make in a couple hours or save the time by using Chipp's.

Separating code into sets of related functionality in libraries, and making each UI stack separate as well, lets you assign tasks to the best person on your team without needing to work at any finer level of granularity. Such a workflow also encourages a well-factored code style, in which the various components have well-defined inputs and outputs, and what happens in between can be regarded as a black box.

With the advent of agile methods such a well-factored small-team workflow is ever easier to adopt, supported by a wide range of available literature.

[MrWizard]

You're preaching to the choir when it comes to modular software design. However, I'm very new when it comes to runrev...having only really played with it in my 'free' time. It is not obvious to me how you split a project up into multiple stacks and actually save them separately. Unfortunately, googling doesn't seem to yield any useful results. (Another hurdle to runrev adoption is the comparable lack of resources.)

[FourthWorld]

As with any dev environment, a useful architecture separates code, UI, and data. In Rev, this can mean factoring your code into libraries which are called from your UI stacks, and those UI stacks could be as simple as one stack per stack file so they're easily shared among different members of the team.

You can have up to 50 libraries at runtime, which is usually more than enough for even a highly-factored project. I tend to group related functionality into each library, so that I have one for managing the data store, one for search, another for input validation, another for document handling, etc.

Grouping by functionality also helps with assigning development tasks to team members: the person most familiar with Internet protocols can work on the connectivity library, while someone with a strong usability sense can work on the UI stuff, and someone with a knack for APIs can write the application layer.

This latter, the application layer, is a fairly new pattern I've added to my setup over the last year, addressing a problem with large applications in which new team members were required to learn the APIs of many different libraries to get stuff done. So now this application layer is simply a sort of one-stop-shopping for the business logic of the application: Most UI code only writes to the application layer library, and that library then handles the data store and other lower-level details. This layer keeps a clear separation between the UI and the underlying libraries that drive it, so that I can, for example, change the data store at any time without needing to alter any of the UI code that uses that data, since the data is handled through pairs of get and put accessors in the application layer - I just change the app layer and the UI code comes along for the ride.

I've started migrating my note about design patterns in Rev from a talk Ken Ray and I gave at RevCon West in '06 to a set of articles at RevJournal.com, which will explore some of these ideas in greater detail. But like the rest of my free work that takes a back seat to client needs so it may be another couple weeks before I post those.

In the meantime this article may help you get started using libraries:

Extending the Runtime Revolution Message Path:
An introduction to using Libraries, FrontScripts, BackScripts and Behaviors
in Runtime Revolution's RevTalk Programming Language
http://www.fourthworld.com/embassy/arti ... _path.html

I put my libraries and UI stacks into a folder named "Components"; on Win and Linux this is in the same folder as the application, and on Mac I put this with the executable inside the *.app bundle.

Not only does this setup make it easy to share stacks among developers, but if I have an emergency need to deliver a quick fix to a customer I can just send them the stack file, they drop it in the Components folder, and they get the fix without needing to download and re-install the entire app (not to mention saving me the time it takes to make installers).

For version control, I tend to store version info for each stack file in a custom property of the file's mainstack using the conventions outlined by the ECMI guidelines at the Rev Interoperability Project:
http://tech.groups.yahoo.com/group/revInterop/

The RIP guidelines themselves are described in " ECMI_10.rtf" in the "Files" section, and in "Additional Tools" there you'll find RIPEdit, a handy tool for quickly editing those properties.

Trevor's DataGrid and his framework also use the RIP guidelines for version info, and with a common discoverable place for these things it's a snap to make simple FTP- or CGI-based tools that manage a mirror on a remote site where team members can get the latest builds. And with a relatively simple control file you could add a check-in/check-out to that to minimize the risk of simultaneous editing of a given resource.

I have a pair of tools in the works to handle both check-in/check-out and general RIP-based updates (the latter will be especially useful for IDE plugins), and while they're moving along well enough as with the RevJournal article they're a second priority over some immediate client needs, so I don't have a specific release date for those.

If you'd be interested in beta testing please email me at ambassador@fourthworld.com and I'll see that you get an early build as soon as they're available.

[runrevGAf68e]

I'm new to LiveCode as well. I like it and hate it....I don't in any way mean for that statement to be a bash of the developers of this app or those that love using it. Quite simply using LiveCode is completely different than the PHP, Perl, HTML, JavaScript world I come from. The learning curve isn't really bad - LiveCode is fairly easy to learn. The "getting used to it" curve is very steep for me.

Alas, I came here looking for Version Control as well. The type of version control I'm used to - diffs,commits, etc. I appreciate everyone's suggestions above. Unfortunately, those are lots of hoops to jump through for what has always been an incredibly easy task in my prior environments.

It's been about 1 1/2 years since the last post on this. In the interim, have there been any big changes in how LiveCode stores files to allow traditional version control?

Again, I don't mean this as flame bait. Just looking for help.

[igorBUSvRhc]

I am currently 'playing' with a trial version of LiveCode 5.5. Like you, I am also used to version control systems, in particular Git.

It is quite possible to use version control to do 'project-wide' operations, like: branching, merging, and reverting to previous commits.

Although the '.livecode' file format is not plain-text, it seems to me that the text of all scripts we write in LiveCode is, indeed, saved inside the files in plain-text format. I have been able - with some degree of fiddling and annoyance - to cherry-pick individual changes between scripts between different commits. Working with diffs this way is less than optimal, to say the least, and you are more likely not to use it, and simply get into the habit of branching more, and committing *a lot more* frequently, rolling back when needed, and merging in full commits rather than diffing.

You also have to keep in mind that the LiveCode IDE does not detect changes to the project folder/file, as you checkout different commits. For instance, let's say you open a stack, make some changes, save, and commit the changes. Then, make some more changes to the stack, test, and realise you don't like the changes. Go to your VCS and rollback to the previous commit. This will put the previous version *files* in your project directory, but the stack file you still have open in the IDE is the one WITH the commits you didn't want. You must remember either to close it, and re-open it, or to choose "Revert to Saved", to force the IDE to re-read the stack file into memory.

I hope this helps.

[jacque]

If you set the destroystack property of the stack to true it won't stay in memory when you close it. Then you won't have to remember to do anything special.

There's a preference that automatically creates all new stacks with destroystack true. I always use it.