Question on .rev file format
Steve Gehlbach
steve at nexpath.com
Sat Aug 2 17:03:01 EDT 2003
Thanks for the careful reply.
I am not sure about XML, some reports on the net indicate is has bloat
tendencies, but I have no personal experience. It it already done, so
that is a plus.
The comments on version control were over my head, but as I continue to
learn RR maybe the fog will clear.
-Steve
Jan Schenkel wrote:
> --- Steve Gehlbach <steve at nexpath.com> wrote:
>
>>Thanks to all who replied, your comments are very
>>useful.
>>
>>I guess I am not completely convinced that the
>>pluses outweigh the
>>minuses regarding the Revolution binary format, but
>>I will try to keep
>>an open mind.
>>
>>Some other reasons for text formats:
>>
>>- managing groups of engineers: you can look at the
>>nightly checkins to
>>CVS and see how many lines of code have changed.
>>Also can more easily
>>find when and by whom a bug was injected and how to
>>fix it.
>>
>>- CVS puts a version code in the text based on
>>triggers like $Id$ etc,
>>which is very useful when managing various releases
>>and finding which
>>version of code you have. This would of course
>>corrupt a .rev file. I
>>have managed to get around this for many other tools
>>(CAD programs,
>>document programs) since most have an optional text
>>mode, such as .rtf
>>in Word. But they also frequently have bugs so the
>>binary format is
>>Truth, and the text mode is only close to the same.
>>.rtf is pretty
>>good, though. Revolution needs a pure text mode
>>option, but only if it
>>really works.
>>
>>Since the .rev file is 95% the Transcript code in
>>pure text form, I am
>>not convinced of the speed of loading issue. One
>>eye blink or two?
>>Were it tokenized, as Basic did once long ago, I
>>might be more convinced.
>>
>>In general, binary source code formats are the bane
>>of the Linux world.
>>
>>-Steve
>>
>
>
> Hi Steve,
>
> Sorry to arrive in the discussion at such a late time
> but I had other things that needed attention. In the
> meantime, you've received a whole range of interesting
> answers.
>
> All in all, it is perfectly possible to export a
> RunRev stack to XML and bring it back afterwards. And
> I'm sure that Geoff Canyon's MCRipper is an excellent
> place to start.
> You can iterate over the substacks and their cards and
> so forth, and thus export all the information of all
> the controls. This should work fine if you
> base64Encode() the binary bits such as imageData.
> We know what's in the built-in properties, so the only
> problem I see is in determining whether a custom
> property is text or binary data. Of course you could
> base64encode by default, but that won't help much in
> the editing department.
>
> On to version control then ; you can always make
> setProp handlers for your own custom properties, and
> thus write changes to these to a log file.
> Unfortunately you can't trap changes in the built-in
> properties ; unless of course you use the following
> trick : make a library stack to start using or place
> in a backScript with the following handler
> --
> setProp uLOG[pProperty] pNewContent
> -- see whose property we're changing
> put the long ID of the target into tTarget
> -- now update the real property
> do merge("set the [[pProperty]] of [[tTarget]] to
> [[pNewContent]]"
> -- and log the change somewhere
> WriteLogEntry tTarget,pProperty,pNewContent
> end uLOG
> --
> Now whenever you want to update a built-in property,
> and have the change logged, just use
> set the uLOG["rectangle] of field "Foobar" to \
> "100,150,300,300"
> And whaddayakow, your field gets updated, and you have
> a log of the change.
>
> Of course it would be wonderful if the good people
> over in Scotland could somehow tie the engine right
> into CVS ; but in the meantime we're not without means
> ourselves.
>
> Hope my ideas help someone,
>
> Jan Schenkel.
>
> =====
> "As we grow older, we grow both wiser and more foolish at the same time." (La Rochefoucauld)
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
More information about the use-livecode
mailing list