Web Edition and Version Control Format

For those of you that use the Version Control Format (VCP) for your Real Studio projects you should be aware that I do not recommend using it for Web Edition projects.  I discovered (and logged) several bugs today in 2011 R1 that will bite you.

The first is subclassing a WebControl in VCP format results in it displaying in the IDE with a black triangle indicating that it doesn’t know what the control is.  Thankfully the control still works, it just looks funny in the IDE and doesn’t seem to affect the final build.

<feedback://showreport?report_id=16518>

The second is that WebStyles do not read properly after saved in VCP format.  This will result in controls not adhering to their styles after the project is loaded again.  This does affect final builds.

In both cases it could be a write or read failure.  Not my job to figure out which one.

If you use Web Edition and version control you should make these bugs part of your priority list.

<Rant>  This is the third release in a row with serious issues with the version control format that keep me from using it.  For my consulting business I need reliable version control.  The only way to do that is to have a rock solid version control format.  It has to work in EVERY release.

Binary format just isn’t acceptable for my business.  I need to track changes on a line by line basis – sometimes my livelihood depends on knowing what changed, and when.

It ‘s obvious, to me anyway, that RS doesn’t use Web Edition internally for anything big, important, or that requires multiple users working with it.  If they did, they would have spotted these problems a long time ago. </Rant>

We now return you to your normally scheduled broadcast.

18 thoughts on “Web Edition and Version Control Format

  1. I agree. I am not a RB WE user as of yet. But the VCP format has to be rock solid every single release. Without it we (as professionals) cant use it. Have absolutely zero projects (even when just playing around) that are in the xml nor the binary formats. I wish Real would get more serious about VCP.

  2. What we really need is a single universal format. Binary and XML come from the same code, they one doesn’t require more effort than the other. But VCP is a completely different set of code, so we’re maintaining two sets of code to largely do the same thing.

    Only reason we don’t have a single format is we haven’t been able to come up with one that meets all the requirements: ease of distribution, version control, cross-platform.

    But regardless, yes these are bugs that need to be fixed.

    • XML would be workable if we didn’t have to contend with the tags. Having even a basic version control interface in real.studio that utilized the xml format might meet the needs of a majority of your users.

  3. @Thom, all the IDE needs is a “test mode” in which it writes projects to a temp file (or even into a memblock-stream) in all 3 formats, re-reads them and then checks if they are all equal. And if they do not match, it would make a lot of noise so you can’t miss it.

    I’ve done the same in Arbed to make sure I can read and write its 3 formats safely without loss. It’s probably a day’s work to write the code that compares the results, but then you’d not have the problem that you have no constantly, i.e. forget updates to one of the formats.

    It’s like smart unit testing. If I can do it, you can, too. You “just” have to do it 🙂

  4. Oh, and of course, Arbed can visually compare binary proj files much nicer than you can ever do it with the vcp format. If you use SmartSVN as your Svn client, I could even make it possible that double clicking into binary prj files would launch Arbed to show the difference. (SmartSvn lets you specify which tool you want to use to compare two files – all I need to add is support for passing two files for compare to Arbed via cmdline or AppleScript)

    • Arbed is a great program Thomas. I’m having trouble coming up with a fluid workflow that would integrate it. It seems I’d need to go back to renaming each “save” differently, or check out older versions from my version control and then dropping them on Arbed. The latter seems more likely but still not very optimal. How do you envision people using it in their workflow? Maybe I’m missing something.

      Any chance of adding some Git features? That would be amazing!

      • Joseph,
        I suggest to use Arbed only as the tool to _see_ the differences between versions better, while still using Svn or Git to save your prj file repeatedly.

        I’ve also given thought to adding a version control-like feature to Arbed in the way that it would maintain its own database of changes for your projects, but only very few people seem to be interested in that (most rather rely on git/svn). I’d do it anyway if it was just a few day’s of work, but it’ll be a few weeks to get this working well, and I don’t want to go there right now.

  5. I started using the xml format and checking that into git instead of vcp. I’m a lot happier in many ways. What I don’t like is the obvious xml tags. It’d be nice to have a diff program like Arbed that stripped that nonsense out. It’s funny that this issue is coming up because I just started evaluating Getti and Tower since the GitX program I had been using doesn’t seem to be actively supported anymore. The Tower program allows you to choose your diff program, but it’s from a select list and Arbed isn’t one of the options. If that was possible I’d shell out the cash for both programs.

    So to summarize my stream of consciousness. In my perfect world I’d like to have a decent Git front-end that would open a Diff program that strips out the XML tags. I like the xml format better because I have no interest in commenting the minutia of every single vcp “piece” and, of course, it doesn’t seem to fall victim to as many bugs.

  6. Joseph, there’s also “SmartGit” – give it a try. It’s cross-platform (written in Java), and while not as neat as some native apps, it quite powerful, just like its siblings for Svn and CVS.
    And while SmartGit doesn’t offer Arbed neither (yet), it allows for a free cmdline configuration and I could add this feature to Arbed within a few days. If you want to go that route, contact me and I’ll see that I make a version of Arbed that you could experiment with.

    • Let me try out SmartGit before I commit you to making changes to your program. I don’t program every day so I need a workflow that I can keep straight in my brain. I’d rather have fewer steps than lots of bells and whistles.

  7. Oh, BTW, Arbed has an older feature called the “RBVault” – that’s been developed in the times when RB didn’t have the VCP format yet: It creates a text format similar to XML but with less clutter. You can use Arbed to export your prj to this “rbvault” format, which will write a single file per class into a folder, just like vcp, but with the advantage of being an identical mapping to the binary and xml formats, thus loss-less.

    The workflow would be like this:
    You let Arbed create a rbvault export from your prj, which will end up in its own folder. Then you commit that folder to svn or git. And later, if you revert changes with svn/git, you can also use Arbed to recreate a rbp file from the modified rbvault folder.

    I had made attempts to automate this in the past, but there was close to zero interest, so I gave up.
    But it should still work, as it works on a very low level, where it’s quite independent of any highlevel changes to projects.

    Give it a try and let me know if that sounds useable. If there’s a bug in it, I’m happy to fix that ASAP.

    • Just reading that explanation I can tell you that it’s too many steps to pique my interest. Please don’t read that as being rude it’s just that the whole reason I program with real.studio versus a lot of other cheaper options is that it gives me a simple workflow from code to compile (that is.. until I was evangelized into the version control cult). The vcp bugs aren’t what moved me to xml it was just a side benefit. The xml format is just easier to manage with version control. One checkin instead of a half dozen. That’s the kind of ease of use I’m looking for.

      I do plan to give smartgit a try and see how I can easily integrate arbed. I’ll contact you via email with my thoughts and comments.

      Great presentation at the Summit by the way.

      – joe

      • No problem. I know it’s not too easy right now with Arbed, especially since it’s lacking lots of documentation for all of its features. Working on that.
        At least, I just made it possible to use it as a “difference viewer” by SmartGit/Svn. Not released yet, but if you like SmartGit I can send you a prelim version. Setup for it is easy.

  8. Thomas Tempelmann :

    @Thom, all the IDE needs is a “test mode” in which it writes projects to a temp file (or even into a memblock-stream) in all 3 formats, re-reads them and then checks if they are all equal. And if they do not match, it would make a lot of noise so you can’t miss it.

    I’ve done the same in Arbed to make sure I can read and write its 3 formats safely without loss. It’s probably a day’s work to write the code that compares the results, but then you’d not have the problem that you have no constantly, i.e. forget updates to one of the formats.

    It’s like smart unit testing. If I can do it, you can, too. You “just” have to do it :)

    It would certainly solve some issues, no?

    • It would certainly take care of the current problems at hand that Thom admitted being there, instead of just waiting for a better format rather far in the future. The alternative would be that their internal testing process performs these verifications by hand – but that’s obviously not happening, at least not reliably.

  9. Just for the record: I’ve added documentation showing how to use Git (SmartGit) with Real Studion projects:

    http://www.tempel.org/Arbed/SmartGit

    The part where it uses Arbed as the diff viewer is not working as of today yet, though, as it requires Arbed 1.3, which I haven’t released yet (but it should be out by the first week of April ’11)

Comments are closed.