Re: Team Development using Run Rev

[Mark Wieder]

David-

> That's smart Mark - if I have got you right. That would make your diffs a
> "diff script" - that is a shorter script that you can execute on a stack 
> to
> make an update? Or am I dreaming :)


You could do it that way (and it would be easier to archive them that way) 
but I went the other way around: executing the latest script builds the most 
recent object, and traversing the deltas backwards in time reverts to a 
previous version. That way I don't have to worry about the chain integrity 
losing my entire backup.

If you started with the full build script and then just stored delta scripts 
you could indeed update stacks that way. And diffs would still work. But... 
if anything along the way got messed up you'd have no way of building the 
delta chain to get to the most recent version.

-- 
 Mark Wieder
 [EMAIL PROTECTED] 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Ben Rubinstein]

On 5/3/08 17:31, David Bovill wrote:

On 05/03/2008, Ben Rubinstein <[EMAIL PROTECTED]> wrote:

On 3/3/08 15:30, David Bovill wrote:

I use a similar technique for storing stacks in SVN. When scripts are

saved

I have hooks which also export text files to SVN and write out metadata

for

indexing purposes.


Hi David,

Just to clarify - are these hooks in your Rev IDE, or hooks in Subversion
or
Eclipse?



They are in the Rev and galaxy IDE's.



Got it - thanks.

- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[David Bovill]

That's smart Mark - if I have got you right. That would make your diffs a
"diff script" - that is a shorter script that you can execute on a stack to
make an update? Or am I dreaming :)

On 03/03/2008, Mark Wieder <[EMAIL PROTECTED]> wrote:
>
> David-
>
>
> >I use a similar technique for storing stacks in SVN. When scripts are
> saved
> > I have hooks which also export text files to SVN and write out metadata
> > for
> > indexing purposes.
>
>
>
> What I have settled on is saving a stack as a text file series of xtalk
> commands for recreating it:
>
> create button
> set the name of it to "btnCancel"
> etc...
>
> Then I archive the previous version as only the properties that have
> changed:
>
> set the name of button "btnCancel" to "button"
>
> That way I can recreate a stack quickly without having to traverse a chain
> of changed properties and not have to worry about the integrity of the
> archive.
>
> ...and voila! instant diffs.
>
>
> --
>
> Mark Wieder
>   [EMAIL PROTECTED]
>
>
>
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[David Bovill]

On 05/03/2008, Ben Rubinstein <[EMAIL PROTECTED]> wrote:
>
> On 3/3/08 15:30, David Bovill wrote:
> > I use a similar technique for storing stacks in SVN. When scripts are
> saved
> > I have hooks which also export text files to SVN and write out metadata
> for
> > indexing purposes.
>
>
> Hi David,
>
> Just to clarify - are these hooks in your Rev IDE, or hooks in Subversion
> or
> Eclipse?


They are in the Rev and galaxy IDE's.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Ben Rubinstein]

On 3/3/08 15:30, David Bovill wrote:

I use a similar technique for storing stacks in SVN. When scripts are saved
I have hooks which also export text files to SVN and write out metadata for
indexing purposes.


Hi David,

Just to clarify - are these hooks in your Rev IDE, or hooks in Subversion or 
Eclipse?


- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Josh Mellicker]

On Mar 2, 2008, at 8:19 AM, Ben Rubinstein wrote:


And does it offer any kind of diff or comparison features?


TextWrangler has a well-implemented "Compare Two Front Documents"  
feature that I have found really useful. (pasting the latest version  
of a huge stack script into one text doc and an older version into  
another)


http://www.barebones.com/products/textwrangler/
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Richard Gaskin]

mfstuart wrote:


I have some questions as to even if RunRev allows itself to be a software
development tool for development teams. So here are my questions:
Who is using RunRev in a group development environment? (reply if you are)


Many here and elsewhere.


How many developers are on the team?


Varies.  Most of my projects here use three to five; I've done one
project in another xTalk (Gain Momentum) that had a team of 25.


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


Often multiple regions, sometimes different countries.


How are you handling "master" stack updates to the server?
How do you handle "code" (.rev files) check-out and check-in?


Varies from project to project.  Sometimes a custom solution; with a
small, well-organized team we can get away with using email.


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


I'd say so, and the track record of this community, in which so many
people have had three or more programmers contributing to a project,
would seem to reinforce that.

As with any tool, the trick is to find the right dividing lines that 
make the most sense for the workflow.  With project management in Rev, 
the most popular approach is also the simplest: using stacks as the 
natural dividing line defining a discrete work unit.


If you want to have all your stacks as substacks in one stack file, it's
easy enough to clone them out with the clone command, and then integrate
them back into a mainStack by deleting the existing substack and setting
the new one's mainStack property.

But I find it even easier to just leave these stacks as separate stack
files, so that the EXE contains almost no code at all and everything is
handled in a collection of stack files in a Components folder that's in
the same folder as the app.  In OS X you could even put your Components
into the bundle if you prefer.

Not only are stacks a simple with-the-grain work unit in Rev, dividing
work with them makes sense logically as well.  You can put code into
library stacks, have UI views in stacks, and define things such that
each can be treated as a sort of black box, with certain things it
expects from the environment and things the environment can expect from
it.  Regardless of the physical structure of your project, factoring
things into "black boxes" is a useful practice that can make code more
robust from the start and easier to enhance and maintain down the road.

Here in my shop, most of the heavy lifting is done in libraries which
contain code broken up along logical boundaries, so that related code is
all in one place.  This also means that the code in the UI tends to be
very light, often trivial.

Gain Momentum had a built-in check-in/check-out system that worked at
the stack level.  Since I switched to Rev I more than a decade ago I
tend to use the same level of granularity in defining shareable work units.

Chipp's Magic Carpet is a good stack-based solution ready to go, and
others like Ken Ray and myself have written our own for some projects. 
Stacks are such a natural dividing line in Rev that even if you chose to 
write your own from scratch, I'd be surprised if you didn't have a 
positive ROI on the first project you use it on.  And if you use an 
existing one like Magic Carpet you can get instant results right now.


--
 Richard Gaskin
 Managing Editor, revJournal
 ___
 Rev tips, tutorials and more: http://www.revJournal.com

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Dave]

On 1 Mar 2008, at 20:08, Mark Wieder wrote:


Dave-

Saturday, March 1, 2008, 3:43:43 AM, you wrote:



I found the best way to handle this was to export all the script as
text files and them to a compare/merge of the source code and import
the text files back into a "master" stack that is used to build the
standalone application. For example:


That works fine as long as you're only dealing with script changes,
but not for UI changes. What happens if one of the developers needs to
add a field or a button to a stack? What happens if it makes more
sense to move a handler from a card script to a new button script or
vice versa? What if one makes a new custom property? Or worse, makes a
setprop handler for it? None of these are insurmountable, but they
take human mediation to resolve.


In the case of adding new controls, the developer just adds them to  
his copy of the stack, once working the objects are added to the  
template stack and the scripts are imported in the normal way. Moving  
scripts is ok, the scripts just get imported from objects in the  
normal way, e.g. if you move a handler from the card script to a  
button then both the card and the object scripts are added to the  
blank template stack. Custom properties are imported too (forgot to  
mention that before).


Yes, there is some human intervention involved, but not that much,  
but there is almost always some user intervention needed with my  
Source Control System in my experience.


All the Best
Dave


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Sivakatirswami]

Andre Garzia wrote:

Yes, I use magic carpet daily and it saves a lot of time. Me and
Sivakatirswami works on the same projects using magic carpet and we
never run into a problem. I think Magic Carpet is one of the killer
apps available for Revolution Developers and anyone doing serious work
in Rev can benefit from it.

CVS/SVN and the other usual suspects can't really deal with Stacks,
Magic Carpet is built with stacks... really, it works very well!

Andre
  


Ditto that... I've had experience with Adobe's Version Cue, terminal cmd 
line RCS and Magic Carpet. The latter tops them all for simplicity and 
flexibility, and, if it's Revolution stacks you are wanting to 
collaborate on, well, it's really the tool of choice... Run, don't walk 
to Altuit to get this little gem.


Note, I think it might serve equally well for other kinds of documents 
as well...  version control over,  MSword docs, or OmniOutliner files... 
etc.


Sivakatirswami

On 3/1/08, Chipp Walters <[EMAIL PROTECTED]> wrote:
  

Coming a bit late to this party. I've successfully used Rev in a
 multi-developer environment using our own auto-update architecture and
 MagicCarpet.

 It basically works like this. Individual developers check out stacks
 from a web server using MagicCarpet, work on them, then check them
 back in (with notes if they like). MagicCarpet can be setup to
 automatically archive versions, so you can 'roll back' to an older
 version if necessary. Because of our auto-updating architecture, as
 soon as someone checks in a stack, it is instantly made available to
 anyone with the application's executable (Mac or PC). New files are
 automatically downloaded into a plugins folder, after a successful
 launch. Our MGC architecture also handles downloading and
 uncompressing of zip archives as well.

 With small groups of developers, each can be assigned a specific
 library (stack) to work on. Jerry Daniels, Andre Garzia and Sarah
 Reichelt are a few who have used this technique successfully.

 Just another point of view...


 -Chipp

___
 use-revolution mailing list
 use-revolution@lists.runrev.com
 Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
 http://lists.runrev.com/mailman/listinfo/use-revolution





  


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Mark Wieder]

David-

>I use a similar technique for storing stacks in SVN. When scripts are saved
> I have hooks which also export text files to SVN and write out metadata 
> for
> indexing purposes.


What I have settled on is saving a stack as a text file series of xtalk 
commands for recreating it:

create button
set the name of it to "btnCancel"
etc...

Then I archive the previous version as only the properties that have 
changed:

set the name of button "btnCancel" to "button"

That way I can recreate a stack quickly without having to traverse a chain 
of changed properties and not have to worry about the integrity of the 
archive.

...and voila! instant diffs.

-- 
 Mark Wieder
 [EMAIL PROTECTED] 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[David Bovill]

I use a similar technique for storing stacks in SVN. When scripts are saved
I have hooks which also export text files to SVN and write out metadata for
indexing purposes.

I started with XML files, but as most of the changes were script based and I
wanted the code readable and documented I moved the scripts into their own
text files and use XML for the interface. I am not yet using the XML
interface stuff - as I don't find it useful. I am at the moment storing
binary stacks for minimal interface components ("views") and use text files
to describe combinations of these into more useful and complex compound
views.


On 01/03/2008, Mark Wieder <[EMAIL PROTECTED]> wrote:
>
> Dave-
>
>
> Saturday, March 1, 2008, 3:43:43 AM, you wrote:
>
>
> > I found the best way to handle this was to export all the script as
> > text files and them to a compare/merge of the source code and import
> > the text files back into a "master" stack that is used to build the
> > standalone application. For example:
>
>
> That works fine as long as you're only dealing with script changes,
> but not for UI changes. What happens if one of the developers needs to
> add a field or a button to a stack? What happens if it makes more
> sense to move a handler from a card script to a new button script or
> vice versa? What if one makes a new custom property? Or worse, makes a
> setprop handler for it? None of these are insurmountable, but they
> take human mediation to resolve.
>
>
> --
> -Mark Wieder
>   [EMAIL PROTECTED]
>
>
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Chipp Walters]

Ben,

No, it only manages stacks. No diff'ing. It's fairly simple as it
uploads and keeps track of changes for individual stacks.

-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Ben Rubinstein]

On 1/3/08 21:33, Chipp Walters wrote:

Coming a bit late to this party. I've successfully used Rev in a
multi-developer environment using our own auto-update architecture and
MagicCarpet.

It basically works like this. Individual developers check out stacks
from a web server using MagicCarpet, work on them, then check them
back in (with notes if they like). MagicCarpet can be setup to
automatically archive versions, so you can 'roll back' to an older
version if necessary. Because of our auto-updating architecture, as
soon as someone checks in a stack, it is instantly made available to
anyone with the application's executable (Mac or PC). New files are
automatically downloaded into a plugins folder, after a successful
launch. Our MGC architecture also handles downloading and
uncompressing of zip archives as well.


Thanks for reminding me about MagicCarpet, which I mean to check out (pun not 
intended).  Can you clarify; does it offer any merging at a level more 
detailed than stack (and does it merge substacks)?  And does it offer any kind 
of diff or comparison features?


thanks,

- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Andre Garzia]

Yes, I use magic carpet daily and it saves a lot of time. Me and
Sivakatirswami works on the same projects using magic carpet and we
never run into a problem. I think Magic Carpet is one of the killer
apps available for Revolution Developers and anyone doing serious work
in Rev can benefit from it.

CVS/SVN and the other usual suspects can't really deal with Stacks,
Magic Carpet is built with stacks... really, it works very well!

Andre

On 3/1/08, Chipp Walters <[EMAIL PROTECTED]> wrote:
> Coming a bit late to this party. I've successfully used Rev in a
>  multi-developer environment using our own auto-update architecture and
>  MagicCarpet.
>
>  It basically works like this. Individual developers check out stacks
>  from a web server using MagicCarpet, work on them, then check them
>  back in (with notes if they like). MagicCarpet can be setup to
>  automatically archive versions, so you can 'roll back' to an older
>  version if necessary. Because of our auto-updating architecture, as
>  soon as someone checks in a stack, it is instantly made available to
>  anyone with the application's executable (Mac or PC). New files are
>  automatically downloaded into a plugins folder, after a successful
>  launch. Our MGC architecture also handles downloading and
>  uncompressing of zip archives as well.
>
>  With small groups of developers, each can be assigned a specific
>  library (stack) to work on. Jerry Daniels, Andre Garzia and Sarah
>  Reichelt are a few who have used this technique successfully.
>
>  Just another point of view...
>
>
>  -Chipp
>
> ___
>  use-revolution mailing list
>  use-revolution@lists.runrev.com
>  Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
>  http://lists.runrev.com/mailman/listinfo/use-revolution
>


-- 
http://www.andregarzia.com All We Do Is Code.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Neal Campbell]

I have been using for all of my non-Visual Studio projects for over a
year. Its light enough to not get in the way but provides good
protection and version control.

Highly recommended (which there was a plugin for Realbasic's IDE).

Neal

On Sat, Mar 1, 2008 at 5:22 PM, Jerry Daniels <[EMAIL PROTECTED]> wrote:
> Yes, indeed.
>
>  Jerry Daniels
>
>  Daniels & Mara, Inc.
>  Makers of GLX2
>  http://www.daniels-mara.com/glx2
>
>
>
>  On Mar 1, 2008, at 3:33 PM, Chipp Walters wrote:
>
>  > Coming a bit late to this party. I've successfully used Rev in a
>  > multi-developer environment using our own auto-update architecture and
>  > MagicCarpet.
>  >
>  > It basically works like this. Individual developers check out stacks
>  > from a web server using MagicCarpet, work on them, then check them
>  > back in (with notes if they like). MagicCarpet can be setup to
>  > automatically archive versions, so you can 'roll back' to an older
>  > version if necessary. Because of our auto-updating architecture, as
>  > soon as someone checks in a stack, it is instantly made available to
>  > anyone with the application's executable (Mac or PC). New files are
>  > automatically downloaded into a plugins folder, after a successful
>  > launch. Our MGC architecture also handles downloading and
>  > uncompressing of zip archives as well.
>  >
>  > With small groups of developers, each can be assigned a specific
>  > library (stack) to work on. Jerry Daniels, Andre Garzia and Sarah
>  > Reichelt are a few who have used this technique successfully.
>  >
>  > Just another point of view...
>  >
>  > -Chipp
>  > ___
>  > use-revolution mailing list
>  > use-revolution@lists.runrev.com
>  > Please visit this url to subscribe, unsubscribe and manage your
>  > subscription preferences:
>  > http://lists.runrev.com/mailman/listinfo/use-revolution
>
>
>
>
>
>
>
>  ___
>  use-revolution mailing list
>  use-revolution@lists.runrev.com
>  Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
>  http://lists.runrev.com/mailman/listinfo/use-revolution
>



-- 
Neal Campbell
Abroham Neal Software
Programming Services for Windows, OS X and Linux
(540) 242 0911
-
Try Spot for OS X, the intelligent DXCluster Client at
www.abrohamnealsoftware.com

For a great dog book, visit www.abrohamneal.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Jerry Daniels]

Yes, indeed.

Jerry Daniels

Daniels & Mara, Inc.
Makers of GLX2
http://www.daniels-mara.com/glx2

On Mar 1, 2008, at 3:33 PM, Chipp Walters wrote:


Coming a bit late to this party. I've successfully used Rev in a
multi-developer environment using our own auto-update architecture and
MagicCarpet.

It basically works like this. Individual developers check out stacks
from a web server using MagicCarpet, work on them, then check them
back in (with notes if they like). MagicCarpet can be setup to
automatically archive versions, so you can 'roll back' to an older
version if necessary. Because of our auto-updating architecture, as
soon as someone checks in a stack, it is instantly made available to
anyone with the application's executable (Mac or PC). New files are
automatically downloaded into a plugins folder, after a successful
launch. Our MGC architecture also handles downloading and
uncompressing of zip archives as well.

With small groups of developers, each can be assigned a specific
library (stack) to work on. Jerry Daniels, Andre Garzia and Sarah
Reichelt are a few who have used this technique successfully.

Just another point of view...

-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution








___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Chipp Walters]

Coming a bit late to this party. I've successfully used Rev in a
multi-developer environment using our own auto-update architecture and
MagicCarpet.

It basically works like this. Individual developers check out stacks
from a web server using MagicCarpet, work on them, then check them
back in (with notes if they like). MagicCarpet can be setup to
automatically archive versions, so you can 'roll back' to an older
version if necessary. Because of our auto-updating architecture, as
soon as someone checks in a stack, it is instantly made available to
anyone with the application's executable (Mac or PC). New files are
automatically downloaded into a plugins folder, after a successful
launch. Our MGC architecture also handles downloading and
uncompressing of zip archives as well.

With small groups of developers, each can be assigned a specific
library (stack) to work on. Jerry Daniels, Andre Garzia and Sarah
Reichelt are a few who have used this technique successfully.

Just another point of view...

-Chipp
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Mark Wieder]

viktoras-

Saturday, March 1, 2008, 1:11:24 AM, you wrote:

> Of course it would be nice to have a possibility to set any ID from
> script (should we ask for an enhancement, is this possible at all?).

That's BZ #4046 already.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Mark Wieder]

Stephen-

Friday, February 29, 2008, 5:33:40 PM, you wrote:

> pehaps a good reason to use the altID property or use unique names!!

Actually, ids can be used as long as you don't need absolute values
for objects other than images. If you refer to group id 4567 instead
of group "xyzzy" then this approach probably won't work out well.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Mark Wieder]

Dave-

Saturday, March 1, 2008, 3:43:43 AM, you wrote:


> I found the best way to handle this was to export all the script as
> text files and them to a compare/merge of the source code and import
> the text files back into a "master" stack that is used to build the
> standalone application. For example:

That works fine as long as you're only dealing with script changes,
but not for UI changes. What happens if one of the developers needs to
add a field or a button to a stack? What happens if it makes more
sense to move a handler from a card script to a new button script or
vice versa? What if one makes a new custom property? Or worse, makes a
setprop handler for it? None of these are insurmountable, but they
take human mediation to resolve.

-- 
-Mark Wieder
 [EMAIL PROTECTED]

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Dave]

On 29 Feb 2008, at 08:01, Malte Brill wrote:


Hi Mark,

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


Me :)

>How many developers are on the team?

Up to 5

>Are the developers in the same office or are the team members  
spread over

>different regions or countries?

Most of the time same office, somtimes spread across regions

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

Very carefully. ;-)

>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?


The file format is not really team friendly given its binary  
nature. It boils down to that every team member is working on one  
module (stack) at the time, which get loaded by a splash screen  
master stack in the deployed version. If cards need to be in the  
same stack, but different people are working on them, we either  
copy over the cards, or ping ourselfs in an IM system. "Do you have  
xyz.rev in use at the moment? Please check it in to SVN that I can  
do my bits" And in a few cases this goes wrong. Given the binary  
nature of stacks, SVN can not merge them, which is a pity. I wrote  
an XML exporter for stacks, that can export a stack to XML and  
recreate the stack afterwards. However, this has some difficulties,  
as there are some properties, that can not be set by script (ID  
being one). So one needs to design the stacks carefully (do not  
refer to controls by ID) and I gave up on that approach.




I found the best way to handle this was to export all the script as  
text files and them to a compare/merge of the source code and import  
the text files back into a "master" stack that is used to build the  
standalone application. For example:


Fred, George and Sally all work on "StackA" at the same time. They  
then want to merge their changes into one masterstack. There is a  
template stack (Template_StackA)  that only contains the GUI  
elements, no script code. They export the scripts from their stacks  
and do a merge/compare on the text files. The template file is copied  
into a new folder and the new text files are imported back into the  
corresponding objects in the stack.


Hope this helps
All the Best
Dave










___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Mark Schonewille]

Hi,

It might be interesting for you to know that DIFfersifier exports all  
properties of stacks to XML now. The result is an amost correct XML  
file, that can be parsed and interpreted by all specialized XML  
viewers. It should be possible to reconstruct your stack from it,  
except the ID numbers, for which you might want to use the altIDs.


There are a few little glitches, which will be fixed soon. One of them  
is that your stack must have a group (any, even empty, group will do).  
Another is that a small number of tags is incorrect. You might want to  
delete tags that cannot be  parsed for now.


Although DIFfersifier was made to convert HyperCard stacksm, it also  
works with Revolution and MetaCard stacks. You can find DIFfersifier  
at  and that's also where you  
will find an update without those XML-related glitches and errors in a  
few weeks.


Best regards,

Mark Schonewille

--

Economy-x-Talk Consulting and Software Engineering
http://economy-x-talk.com
http://www.salery.biz

Convert colours between different colour spaces with Color Converter.  
Download at http://economy-x-talk.com/cc.html


Well, if you're able to *not* set 'hard' values of any ids in your  
code,

then the serialization ( dump ) of a stack is not a problem, no ?
and then, you can use any CVS/SVN/BZR tool to manage your versions
in a very subtle way.

I've done that for an old project, but didn't serialize ( export ) all
properties, only a few but it did work !

Regards,
Thierry



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Thierry]

Hi viktoras,

Unfortunately a few functions in Rev require use of ID (or long ID)  
when referring to objects...


Yes, you're right but what I'm saying is to not manage the references
of your objects with ids numbers written in the code.  Therefore, the  
relevant question
could be if it's possible to do that in every situation ? Which, I  
think the answer is
not, unless one take care of his organization of coding and  
referencing...

But this is a big topic indeed :-)
You can have a look at How some OO languages deals with serialization;
more or less the same sort of problems, or even HOW is done the mapping
between OO and Relationels Models.



Meanwhile I wonder whether altID approach works reliably in all cases.


So do I

Regards,
Thierry



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[viktoras didziulis]

Unfortunately a few functions in Rev require use of ID (or long ID) when 
referring to objects...
RevDictionary says: use the altID property to specify an additional ID 
for an object. Both the ID and the altID property are checked when you 
refer to an object by ID.


Of course it would be nice to have a possibility to set any ID from 
script (should we ask for an enhancement, is this possible at all?). 
Meanwhile I wonder whether altID approach works reliably in all cases.


B.t.w the dictionary warns:  be careful not to set an object's altID 
property to the ID of an object of the same type. Since both properties 
are checked when you refer to an object by ID, doing this may cause the 
wrong object to be found because its altID property is the same as the 
ID of the object you want.


Gotcha: how do we know in advance what ID will be assigned to an object 
to avoid matching ID and altID of two different objects? Will the 
Revolution engine check uniqueness of both IDs and altIDs?  Is there any 
way to ensure that no ID and altID for any two objects match ?


All the best!
Viktoras



Thierry wrote:

Well, if you're able to *not* set 'hard' values of any ids in your code,
then the serialization ( dump ) of a stack is not a problem, no ?
and then, you can use any CVS/SVN/BZR tool to manage your versions
in a very subtle way.

I've done that for an old project, but didn't serialize ( export ) all
properties, only a few but it did work !

Regards,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Thierry]

Le 1 mars 08 à 02:11, Mark Wieder a écrit :


"Stephen-

It should be said that (almost?) every object in rev can be  
created by
script. As an exercise I've written scripts that go through all  
objects in
a stack and make up a list of statements that can later be  
executed and
recreate everything, including custom properties and scripts. It  
gets a
little crazy with groups inside groups, but it can be done.   
Base64 is

one's friend in this instance.

Would these scripts (all text) work in a code versioning environment?



Almost. I can deconstruct and reconstruct objects and entire  
stacks, but ids
are the Achilles heel here. For some reason object ids are set in  
stone at
creation time. This works out ok in most cases, but if you have  
code that
references objects by id then the recreation approach won't work  
because the
rebuilt objects will almost certainly have different ids from the  
original

objects.


Well, if you're able to *not* set 'hard' values of any ids in your code,
then the serialization ( dump ) of a stack is not a problem, no ?
and then, you can use any CVS/SVN/BZR tool to manage your versions
in a very subtle way.

I've done that for an old project, but didn't serialize ( export ) all
properties, only a few but it did work !

Regards,
Thierry

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Luis]

I'm wondering what they use at RunRev HQ.

Cheers,

Luis.



mfstuart wrote:

Hi Ben,
Nice concept, if someone could build that in RunRev, a Team Development
system, quite possible if you know the structure of all the objects. The
SmartProperties plug-in that already exists, shows how the same object in
the original rev file could be compared to the just updated rev file.

==
Ben wrote:
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. 


Mark Stuart

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Stephen Barncard]

pehaps a good reason to use the altID property or use unique names!!


Almost. I can deconstruct and reconstruct objects and entire stacks, but ids
are the Achilles heel here. For some reason object ids are set in stone at
creation time. This works out ok in most cases, but if you have code that
references objects by id then the recreation approach won't work because the
rebuilt objects will almost certainly have different ids from the original
objects.

--
 Mark Wieder
 [EMAIL PROTECTED]



--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Mark Wieder]

"Stephen-

> It should be said that (almost?) every object in rev can be created by 
> script. As an exercise I've written scripts that go through all objects in 
> a stack and make up a list of statements that can later be executed and 
> recreate everything, including custom properties and scripts. It gets a 
> little crazy with groups inside groups, but it can be done.  Base64 is 
> one's friend in this instance.
>
> Would these scripts (all text) work in a code versioning environment?


Almost. I can deconstruct and reconstruct objects and entire stacks, but ids 
are the Achilles heel here. For some reason object ids are set in stone at 
creation time. This works out ok in most cases, but if you have code that 
references objects by id then the recreation approach won't work because the 
rebuilt objects will almost certainly have different ids from the original 
objects.

-- 
 Mark Wieder
 [EMAIL PROTECTED] 



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Ben Rubinstein]

On 29/2/08 17:49, Len Morgan wrote:
I understand: NO GUARANTY, No help.  I accept the challenge.  Where can 
I locate the code so I can have my way with it?


I'll email it off list.

- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Len Morgan]

I understand: NO GUARANTY, No help.  I accept the challenge.  Where can 
I locate the code so I can have my way with it?


len morgan

Ben Rubinstein wrote:

On 29/2/08 14:27, Len Morgan wrote:
Is there any chance that one of you (or someone else) might release 
the XML exporter?  I'd like to make a "DIFFer"  for stacks.  I'd want 
to be able to export EVERYTHING (object properties, etc) in addition 
to scripts and then give the option to the user to display 
everything, just objects, just scripts, etc.


I understand that you cannot restore a stack exactly, because you 
can't set IDs, but I think you might be able to "fake" it by 
recreating the stack in the same order (so the ids would end up being 
the same).  Maybe that's more trouble than it's worth but I think it 
IS possible.


I think this would be a handy tool and I'd love to take a shot at it.


You're welcome to take a copy of mine and mash it as you will.  It's 
literally a tool stack - no docs, impenetrable interface, probably 
shitey code - I've just built it once when I needed, extended it on 
another occasion when I needed a bit more, repeat, so it's just got an 
accreted collection of the features I've needed at some time or the 
other.


I say it generates XML, but it would be more accurate to say 
'pseudo-XML' - it's probably well formed, but it's not valid, there's 
no use of CDATA or escaping on the content, so if a script includes 
"&" (er, many of mine do) that just appears in the 'xml', instantly 
rendering it invalid for a start.


I've only ever used it for diffing, not with any intention of 
archiving or recreating from the files.  Includes options for scripts, 
substacks, object native properties, user properties, rev properties, 
contents and styled contents.


(As an example of the fact that it has been aimed at diffing not 
reconstructing, it's smart enough to output elements belonging to 
groups only once, rather than on each card it encounters the group; 
but it doesn't mention whether a particular card includes a given group.)


So, if you'll accept it with no warranties, no apologies, and no 
explanations,  you're welcome to it.


- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-revolution



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[mfstuart]

Hi Ben,
Nice concept, if someone could build that in RunRev, a Team Development
system, quite possible if you know the structure of all the objects. The
SmartProperties plug-in that already exists, shows how the same object in
the original rev file could be compared to the just updated rev file.

==
Ben wrote:
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. 

Mark Stuart
-- 
View this message in context: 
http://www.nabble.com/Team-Development-using-Run-Rev-tp15752758p15763352.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Stephen Barncard]

It should be said that (almost?) every object in rev can be created 
by script. As an exercise I've written scripts that go through all 
objects in a stack and make up a list of statements that can later be 
executed and recreate everything, including custom properties and 
scripts. It gets a little crazy with groups inside groups, but it can 
be done.  Base64 is one's friend in this instance.


Would these scripts (all text) work in a code versioning environment?



So if you have this exporter, can you create the importer to get back the
objects to their original state? That would be the key.
And if this cannot work, then Steve's concepts would align to how I'd
approach team development using RunRev.


--


stephen barncard
s a n  f r a n c i s c o
- - -  - - - - - - - - -



___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

RE: Team Development using Run Rev

[Steve Checkley]

** reposted because Hotmail didn't add line breaks to my message! **Hello 
all,Glad this question came up because the company I work for has beenmulling 
over Rev for development work. No decision has been made yet,but I've had to 
give this some serious thought as to how we'd go aboutthings if we did.We'd 
basically have three or four coders working on a project, and wewould have to 
split out into many stacks so each coder could work on abit each. Some stacks, 
therefore, would act as interface but would containvery little 'doing' code and 
other stacks would act as libraries that processbits of data, or provide 
support for interface elements such as a treeview. In this way, you could break 
a project down and give each developerspecific tasks and ownership of areas to 
work on.If there was one stack that contained more UI that any other, one 
developerwould have to be given responsibility over it and merge the others' 
efforts.This might mean that the other developers produce a stack with just 
that oneparticular card in it, which would then reduce the potential for mixing 
upversions of the stacks. If they're working on just one card but have themain 
stacks 'in use' at the time, there should be little chance of scriptsnot 
working when merged.You'd need to set a variable naming convention, to make 
sure that yourguys don't go mad and create their own globals for the same 
thing. Localsshould be named conventionally too, so it's easier to read code. 
The firststack that loads should set your 'world' variables, as I call them... 
onesthat determine look and feel, location of files and folders etc.Code should 
be well commented and explained so a second developer canfollow what's been 
done. In my own projects, I use two commentingstyles... one that explains what 
the handler does and ones that explain whatI'm doing as I go along. It's 
usually easier to read Rev's code than otherlanguages but sometimes it can get 
complicated, especially if abbreviationsor more advanced structures are 
used.Using groups of controls should make things easier to manage too. So 
ifyou've got a panel on your main stack and it gets updated, it should justbe a 
matter of deleting the group and replacing it with another.There are loads of 
reasons why Rev would work so well as a developmentplatform but it would 
require careful management of the project to ensure it all comes together. That 
said, I'm sure any development team is used tosome discipline and my gut 
feeling is that the speed with which an applicationcould be put together 
outweighs any additional time spent controlling it.What do others think? 
Wouldn't it be interesting if the list worked on a groupproject to find out how 
easy it is to produce something in this way?Cheers,Steve
_
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[mfstuart]

Hi Malte,
First, thanx for your reply. I've put other questions or responses below...

>Most of the time same office, sometimes spread across regions -
So do the remote developers email the rev files to somebody who then copies
these new or updated rev files to the master location? I assume this is the
merge process.

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

>I wrote an XML exporter for stacks -
In the tool I currently use (eDeveloper), I can export any object in the
application to a text file: model, table definition, program, help, menu,
anything. In this file, besides all the other stuff, is what they call an
ISN - Internal Serial Number for each object. This is how they track
(internally) the relationship between each object. When I import that object
into another project, or even the same project on the master, it knows what
it belongs to, in the target project.
So if you have this exporter, can you create the importer to get back the
objects to their original state? That would be the key.
And if this cannot work, then Steve's concepts would align to how I'd
approach team development using RunRev.

Thanx,
Mark Stuart
-- 
View this message in context: 
http://www.nabble.com/Team-Development-using-Run-Rev-tp15752758p15762903.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Ben Rubinstein]

On 29/2/08 14:27, Len Morgan wrote:
Is there any chance that one of you (or someone else) might release the 
XML exporter?  I'd like to make a "DIFFer"  for stacks.  I'd want to be 
able to export EVERYTHING (object properties, etc) in addition to 
scripts and then give the option to the user to display everything, just 
objects, just scripts, etc.


I understand that you cannot restore a stack exactly, because you can't 
set IDs, but I think you might be able to "fake" it by recreating the 
stack in the same order (so the ids would end up being the same).  Maybe 
that's more trouble than it's worth but I think it IS possible.


I think this would be a handy tool and I'd love to take a shot at it.


You're welcome to take a copy of mine and mash it as you will.  It's literally 
a tool stack - no docs, impenetrable interface, probably shitey code - I've 
just built it once when I needed, extended it on another occasion when I 
needed a bit more, repeat, so it's just got an accreted collection of the 
features I've needed at some time or the other.


I say it generates XML, but it would be more accurate to say 'pseudo-XML' - 
it's probably well formed, but it's not valid, there's no use of CDATA or 
escaping on the content, so if a script includes "&" (er, many of mine do) 
that just appears in the 'xml', instantly rendering it invalid for a start.


I've only ever used it for diffing, not with any intention of archiving or 
recreating from the files.  Includes options for scripts, substacks, object 
native properties, user properties, rev properties, contents and styled contents.


(As an example of the fact that it has been aimed at diffing not 
reconstructing, it's smart enough to output elements belonging to groups only 
once, rather than on each card it encounters the group; but it doesn't mention 
whether a particular card includes a given group.)


So, if you'll accept it with no warranties, no apologies, and no explanations, 
 you're welcome to it.


- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Ben Rubinstein]

On 29/2/08 15:50, Joe Lewis Wilkins wrote:
Let's face it guys, anytime you have more than one "brain" working on 
anything, the process is problematic. Even such tools as Apple's MPW, 
developed specifically for team operations, was not easily groked by 
most (IMHO). To expect that it would be any different  with Rev is 
pretty much a pipe-dream. To even think about it, much less try to do 
it, may prove to be foolish what with all of the caveats.


I don't disagree, but it's much easier with some environments than others. 
The nature of Rev development makes it harder than eg .NET development, or 
typical LAMP development, or I guess a more direct comparison, Flex development.


We have many much larger and more complex projects in the studio here on which 
many people collaborate on the development, with much less hassle than is 
experienced when collaborating on the small number of relatively simple Rev 
projects.  Strict use of source of source code control and adherence to a 
simple set of conventions is enough to avoid any major issues with those 
development environments.


That just isn't the case with Rev, because of the fact that code is 
distributed in many places, interface elements are defined in object 
properties not in anything that is recognisable as 'code', and all these 
pieces of scripts and object properties are bound up together with assets in a 
single binary file with an opaque file structure.


I don't think that's a fault as such; it's the consequence of some of the same 
things about Rev that make it wonderful, and wonderfully productive, in other 
ways.


But it would be idle to pretend that there isn't a difference between 
development environments in this respect, and that Rev poses more difficulties 
than some others.  I don't think that's a reason not to use Rev; but there are 
tradeoffs, and it's one of the factors that I'd weigh in choosing the platform 
on which to develop a new project.


Given that, in many cases I will find the advantages of Rev more compelling 
that the disadvantages including that one; so it's worth considering what can 
be done to alleviate these difficulties.


- Ben

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Joe Lewis Wilkins]

Let's face it guys, anytime you have more than one "brain" working on  
anything, the process is problematic. Even such tools as Apple's MPW,  
developed specifically for team operations, was not easily groked by  
most (IMHO). To expect that it would be any different  with Rev is  
pretty much a pipe-dream. To even think about it, much less try to do  
it, may prove to be foolish what with all of the caveats.


Modularize the effort so as to have independent stacks or collections  
of stacks, bring the fully completed modules together at the end  
someway and then figure out how to divvy up the separate modules  
amongst the team members for implementation. Maybe that seems obvious,  
but it must be done at the very outset as a part of the  
conceptualization or you're doomed to fail. Just my 2 cents worth.  
(smile)


Joe Wilkins

On Feb 29, 2008, at 12:01 AM, Malte Brill wrote:


Hi Mark,

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


Me :)

>How many developers are on the team?

Up to 5

>Are the developers in the same office or are the team members  
spread over

>different regions or countries?

Most of the time same office, somtimes spread across regions

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

Very carefully. ;-)

>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?


The file format is not really team friendly given its binary nature.  
It boils down to that every team member is working on one module  
(stack) at the time, which get loaded by a splash screen master  
stack in the deployed version. If cards need to be in the same  
stack, but different people are working on them, we either copy over  
the cards, or ping ourselfs in an IM system. "Do you have xyz.rev in  
use at the moment? Please check it in to SVN that I can do my bits"  
And in a few cases this goes wrong. Given the binary nature of  
stacks, SVN can not merge them, which is a pity. I wrote an XML  
exporter for stacks, that can export a stack to XML and recreate the  
stack afterwards. However, this has some difficulties, as there are  
some properties, that can not be set by script (ID being one). So  
one needs to design the stacks carefully (do not refer to controls  
by ID) and I gave up on that approach.


>I ask these questions at this time after spending almost 2 years  
using and

>learning RunRev on my spare time.
>It is starting to appear to me that it's a viable tool to use to  
develop

>"off the shelf" software products.

Good tool with up and downsides in team mode. It plays nicer with  
one man show companies.


>But with that in mind it's important to understand the questions  
above, as

>one day this may be the tool of choice.

I hope my answers help a bit.

All the best,

Malte






___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Len Morgan]

Is there any chance that one of you (or someone else) might release the 
XML exporter?  I'd like to make a "DIFFer"  for stacks.  I'd want to be 
able to export EVERYTHING (object properties, etc) in addition to 
scripts and then give the option to the user to display everything, just 
objects, just scripts, etc.


I understand that you cannot restore a stack exactly, because you can't 
set IDs, but I think you might be able to "fake" it by recreating the 
stack in the same order (so the ids would end up being the same).  Maybe 
that's more trouble than it's worth but I think it IS possible.


I think this would be a handy tool and I'd love to take a shot at it.

len morgan

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.




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: 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 hist

RE: Team Development using Run Rev

[Steve Checkley]

Hello all,
 
Glad this question came up because the company I work for has been mulling over 
Rev for development work. No decision has been made yet, but I've had to give 
this some serious thought as to how we'd go about things if we did.
 
We'd basically have three or four coders working on a project, and we would 
have to split out into many stacks so each coder could work on a bit each. Some 
stacks, therefore, would act as interface but would contain very little 'doing' 
code and other stacks would act as libraries that process bits of data, or 
provide support for interface elements such as a tree view. In this way, you 
could break a project down and give each developer specific tasks and ownership 
of areas to work on.
 
If there was one stack that contained more UI that any other, one developer 
would have to be given responsibility over it and merge the others' efforts. 
This might mean that the other developers produce a stack with just that one 
particular card in it, which would then reduce the potential for mixing up 
versions of the stacks. If they're working on just one card but have the main 
stacks 'in use' at the time, there should be little chance of scripts not 
working when merged.
 
You'd need to set a variable naming convention, to make sure that your guys 
don't go mad and create their own globals for the same thing. Locals should be 
named conventionally too, so it's easier to read code. The first stack that 
loads should set your 'world' variables, as I call them... ones that determine 
look and feel, location of files and folders etc.
 
Code should be well commented and explained so a second developer can follow 
what's been done. In my own projects, I use two commenting styles... one that 
explains what the handler does and ones that explain what I'm doing as I go 
along. It's usually easier to read Rev's code than other languages but 
sometimes it can get complicated, especially if abbreviations or more advanced 
structures are used.
 
Using groups of controls should make things easier to manage too. So if you've 
got a panel on your main stack and it gets updated, it should just be a matter 
of deleting the group and replacing it with another.
 
There are loads of reasons why Rev would work so well as a development platform 
but it would require careful management of the project to ensure it all comes 
together. That said, I'm sure any development team is used to some discipline 
and my gut feeling is that the speed with which an application could be put 
together outweighs any additional time spent controlling it.
 
What do others think? Wouldn't it be interesting if the list worked on a group 
project to find out how easy it is to produce something in this way?
 
Cheers,
 
 
Steve
_
Free games, great prizes - get gaming at Gamesbox. 
http://www.searchgamesbox.com___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Team Development using Run Rev

[Malte Brill]

Hi Mark,

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


Me :)

>How many developers are on the team?

Up to 5

>Are the developers in the same office or are the team members spread  
over

>different regions or countries?

Most of the time same office, somtimes spread across regions

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

Very carefully. ;-)

>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?


The file format is not really team friendly given its binary nature.  
It boils down to that every team member is working on one module  
(stack) at the time, which get loaded by a splash screen master stack  
in the deployed version. If cards need to be in the same stack, but  
different people are working on them, we either copy over the cards,  
or ping ourselfs in an IM system. "Do you have xyz.rev in use at the  
moment? Please check it in to SVN that I can do my bits" And in a few  
cases this goes wrong. Given the binary nature of stacks, SVN can not  
merge them, which is a pity. I wrote an XML exporter for stacks, that  
can export a stack to XML and recreate the stack afterwards. However,  
this has some difficulties, as there are some properties, that can not  
be set by script (ID being one). So one needs to design the stacks  
carefully (do not refer to controls by ID) and I gave up on that  
approach.


>I ask these questions at this time after spending almost 2 years  
using and

>learning RunRev on my spare time.
>It is starting to appear to me that it's a viable tool to use to  
develop

>"off the shelf" software products.

Good tool with up and downsides in team mode. It plays nicer with one  
man show companies.


>But with that in mind it's important to understand the questions  
above, as

>one day this may be the tool of choice.

I hope my answers help a bit.

All the best,

Malte

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution