Team Development / Exporting stuff to text files

[David Bovill]

On 05/03/2008, Chipp Walters <chipp at chipp.com> wrote:
>
> David, another point to understand is the recompilation of a complete
> stack from text files, is a very difficult, if not impossible task to
> undertake. I should know. I worked with David Johnson for over a year
> on a sharing toolkit (RevShare) which allowed users to update in
> realtime each others projects over the internet. It was a complex
> issue and one where I concluded it could not be done solely via text
> data.
>
> In particular, IIRC, the following properties couldn't be trusted to
> always convert exactly:
>
> "id"
> "visited"
> "layer"
> "armed"
> "htmlText"


Interesting - I don't understand the issues with htmltext and armed, and
particularly string the htmltext of a field should be unproblematic - can
you remember the problems there?

But yes - I agree that to try to create a robust text file format for
collaborating on a "generic" stack is pretty well impossible. However to do
so for very specific things which you design for multi-developer
collaboration is possible. In articular if you are creating generic
components which do not depend on ids or the layer I think it is possible -
or at least I cant find a problem with it.

Not to mention all of the images, movies, etc..which would need to be
> managed as well. All in all, I doubt one will find a better
> 'container' for managing such stuff than the stack itself.


Agreed - but you'd have to add to that that it is good practice to not go
too far with that. I for one got myself in a bunch of trouble a few years
back storing everything in the stack - text and images ending up with large
stacks that were hard to maintain. Seperating data from code is surely a
good idea and not one encouraged by the stack metaphor?

If you agree to that point I think you can see there is some room for
structuring the way stacks are designed and stored to facilitate
collaboration - this includes naming conventions, how to deal with "data" vs
code type issues. I for one think a modified MVC approach and naming
conventions enhance the stack based collaboration model here.

Furthermore, if open source was such a grand concept for the Rev
> community as a whole, why haven't we seen more of it?


My view is that one factor is the lack of high quality collaborative tools,
another major factor (perversely) is the ease of solo development. Combine
these and the incentives for collaborative development are not there.

My personal
> opinion, is like many of my plugins, and other free Rev stuff, they
> really only need a single person to code it.


Definitely agree.

Many moons ago, Richard,
> Jacque and myself tried to create a 'team approach' to creating a new
> property editor-- I believe we ended up each rolling our own.


And that I would say is a classic story for many such Rev based
collaborative projects. My opinion is that the amount of effort it takes to
develop sufficiently robust collaborative tools is on par with the amount of
effort it took RunRev to develop their IDE, anything that fall much short of
that will be discarded by individual developers on the basis that their own
ROI. They will end up rolling there own.

That said, the MetaCard project, I suppose could be included as a
> successful open source project, but it was pretty much well on it's
> way BEFORE being open sourced.


Yes - thanks to Scott insisting on it, and Richard et als dedication. To
develop a collaborative framework for RunRev (svn style) takes a level of
investment on par with the investment put into MC IDE, RunRevs IDE or
Galaxy. I've got maybe 2-3 man-years investment in the environment I use,
but I figure it would take another 3-6 months full time work to finish it. I
also figure it would not be worth "my" while to do that based on ROI, Others
I think have reached a similar conclusion for their own projects. It's
classic "prisoners dilemma" stuff.