Team Development using Run Rev

[Ben Rubinstein]

I seem to be similar to Malte...

>Who is using RunRev in a group development environment? (reply if you are)

Me, somewhat

>How many developers are on the team?

Up to 6

>Are the developers in the same office or are the team members spread over
>different regions or countries?

Same office


>How are you handling "master" stack updates to the server?

Doesn't really apply in our case - we just use SVN (or have I misunderstood
the question?)


>How do you handle "code" (.rev files) check-out and check-in?

SVN

>Bottom line, is RunRev a good tool to use in a production team environment?

Sub-optimal...

Like Malte, I've written an XML exporter for stacks (hmm, I bet a lot of
people have done this - perhaps we should all agree a common format?).
However, I've not attempted to write the corresponding importer; I use it
mainly for diffing, if I've got in a mess with two development branches.  It's
part of my emergency toolkit rather than part of my regular working process.

Our situation is simpler than Malte; we're not yet trying to work seriously
multi-developer on any of our more complicated multi-stack projects.  There is
a category of projects, where we have a complicated app which is customised
for each each client by a single plug-in stack with relevant code; and there
are a few simple one-stack projects.

The way we handle these is by an adaptation to a standard plugin that we use,
which extends the rev toolbar and carries various butttons.  Probably the
first button I put on this extra bar, some five?? years ago when I started
working with Rev in pre-1.0 beta (and found that it crashed a lot, and
sometimes corrupted the stack on disk) - was a button to save the current
stack, first backing up the previous version.

What we've done now is modify this so that as well as saving the stack, it
also saves an XML 'version' of it, in the same directory.  So if I'm working
on "fred.rev", hitting this button (and by now I'm conditioned to only use
this button for saving) saves "fred.rev", "fred.ts", and "(bups)/fred;123.rev"
(backups pile up, we only ever save the single .ts file).

The convention, which by now everyone pretty much does without thinking, is
that when you commit a stack into SVN, you commit the corresponding .ts file
at the same time.

This doesn't allow you to merge; but it does mean that we can easily do
compares in Eclipse etc between versions checked into SVN.  Depending on the
situation (eg if you've got lots of changes in one script) people sometimes
work their way to a dummy merge on the .ts file, then copy and paste this into
their stack.

(The file is called ".ts" because initially we were just doing it for these
plugin stacks, which are really just script carriers, so they just consisted
of transcript code.  In fact we've now generalised it a bit, so the file saved
by the save button has a simple XML format, and may include scripts and field
text.  The button looks for stack properties to tell it what to save, so for
some stacks the .ts file, just saves scripts; for others scripts and field
text; on a stack that doesn't have the property it just does save+backup as
normal, no .ts file.   We haven't used the full XML export, which does all the
properties of all the controls, which would I guess be the deluxe version.
We're also more code-focused than anything else; if we produced things of
beauty in Rev, we'd obviously be more interesed in tracking those elements.)

As mentioned, this is only doing a subset of the full XML export, and only on
single stacks, with perhaps half-a-dozen cards at worst; but the overhead
(the extra time to output the .ts file) compared with doing the normal 
save+backup is imperceptible.

With all that said - we still try to avoid both working on the same stack at
once, just because merging is a hassle.  But at least with SVN we're tracking
all the changes, can view history etc.

What I'd really like is an extension to SVN or to Eclipse (which happens to be
the interface to SVN that we use pretty much exclusively) that would
automatically, when a .rev file is committed, attach an XML export.  Or a
filter for Eclipse, so that attempting to edit/open/compare a .rev file,
generated an XML export on the fly and edited that.  But I haven't actually
wanted this enough to get off my backside and find out how possible that would be.

A possible better solution would be to create (in Rev, of course) a tool for
checking into SVN; which if you dragged a stack on to it, would generate not a
single XML file but a folder with many files and perhaps folders.  For some
setups you might want the tool to check everything into SVN; I think I'd
rather use this tool, then use Eclipse to do the check-in, so that it would
look at all the differences and allow me to deal with them individually.  That
way you could view the stack as a project, and see each script, card, substack
etc (er... tbd) as individual files, so that there could be individual
comments and change histories.

Ideally RunRev would create a mechanism to export and import a stack in this
way, so that you'd be guaranteed complete coverage.  But I think if I was
going to assemble a serious team for a substantial project in Rev, I'd give
some thought to doing something like this.  And of course if anyone else has
already done so, I'd be interested...

HTH,

- Ben