Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

Tim M
At first I was quite excited by the notion of Dolphin6 integrating
Omnibase.

Many years ago - I really enjoyed Envy/Developer in IBM Smalltalk.

However, the more I think about it (and I haven't used Omnibase yet)
the more I'm thinking - maybe this isn't a great idea after all?

I say this becuase Envy's flaw was how to version other program
artifacts - things like documentation, database scripts etc (it wasn't
really built for this). You could kind of get them into the proprietery
envy database but that limited how other non-coding team members could
access the resources and update them.

Having had a scout around the Omnibase website - I don't see anything
about this issue?

So this gets me thinking (and this is what in part drove IBM's push in
envy to use an open version control system) why bother using Omnibase -
and not just better integrate Subversion or CVS support?

All you need is a decent diff tool, and then someting like Ian B's
change browser (to get method editions etc) to do most things that envy
does. Also is the benefit that other users can use Tortoise to put
associated artifacts in the VCS.

I am interested in other peoples views on this - but it does concern me
that the silver bullet of Omnibase might actually be detrimental - and
maybe adopting a more Eclipse "open vcs" like approach would be far
more usefulm and better support larger teams.

Tim


Reply | Threaded
Open this post in threaded view
|

Re: Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

Andy Bower-3
TimM,

> At first I was quite excited by the notion of Dolphin6 integrating
> Omnibase.
>
> Many years ago - I really enjoyed Envy/Developer in IBM Smalltalk.
>
> However, the more I think about it (and I haven't used Omnibase yet)
> the more I'm thinking - maybe this isn't a great idea after all?
>
> I say this becuase Envy's flaw was how to version other program
> artifacts - things like documentation, database scripts etc (it wasn't
> really built for this). You could kind of get them into the
> proprietery envy database but that limited how other non-coding team
> members could access the resources and update them.
>
> Having had a scout around the Omnibase website - I don't see anything
> about this issue?

First of all, I think it is important to distinguish between Omnibase
(which is a general-purpose object database) and the Source Tracking
System which is the ENVY-like source control component that uses
Omnibase for its underlying storage.

Anyway, you are right, the issue of storing non-code artefacts does
exist when using the Source Tracking System.  It would be good if we
could store other objects (files) in there too but I don't think David
Gorisek had any current intention is to enhance the product in this
area.  I'm not sure how most STS users deal with this issue at present
but my suggestion would be to use STS in parallel with a more
traditional file based system and match up the two based on version
numbers.

> So this gets me thinking (and this is what in part drove IBM's push in
> envy to use an open version control system) why bother using Omnibase
> - and not just better integrate Subversion or CVS support?
>
> All you need is a decent diff tool, and then someting like Ian B's
> change browser (to get method editions etc) to do most things that
> envy does. Also is the benefit that other users can use Tortoise to
> put associated artifacts in the VCS.
>
> I am interested in other peoples views on this - but it does concern
> me that the silver bullet of Omnibase might actually be detrimental -
> and maybe adopting a more Eclipse "open vcs" like approach would be
> far more usefulm and better support larger teams.

As you probably know the existing Source Browser tool and the PAX
format can already be used to store Dolphin "source objects" in a more
traditional file-based SCCS.  We, in fact, use this method internally
with SourceSafe and have done since 1995. One of the reasons we haven't
made more of this facility is that the SourceSafe integration is rather
"fiddly", involving a certain amount of messing around with version
names etc.  I believe somebody has used Dolphin with CVS but we never
pursued this ourselves since we found CVS far too tricky to set up.

Dolphin 6 will still retain the existing ability to use the Source
Browser with an external SCCS so developers will have the choice as to
which system fits their way of working the best. I'm not sure that I
would agree that a file based approach would better support large teams
although STS isn't really suitable for disconnected (from the
repository) working. The great thing about the Source Tracking System,
though, is that the integration with Dolphin is very tight and having
all the past version information online at any time is a great boon.

Best Regards,


--
Andy Bower
Dolphin Support
www.object-arts.com


Reply | Threaded
Open this post in threaded view
|

Re: Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

TimM-3
Andy -

don't get me wrong - I'm still mulling over the idea. At first it seems
awesome but then when I thought a bit more it raises questions - the kind
that keep coming up in bigger (more than 3 devs) development shops (they
hate proprietory VCS's).

> my suggestion would be to use STS in parallel with a more
>traditional file based system and match up the two based on version
>numbers.

Which I guess raises the question what STS gives you (I am envisioning its
like envy)... but having used Eclipse and IntelliJ quite a bit now - and
used the CVS metaphor, I'm not sure now if its as much as I thought it was.

Good merge tools pretty much automerge all conflicts now (rarely do I have
to manual merge stuff - and when I do, a good merge UI helps). So I start to
wonder (and if you come from a VSS background - you have experienced pretty
basic tools) if the downside of a proprietary VCS starts to hurt you.  The
icons, the html docs, the .sql files all should be in the VCS.

> I believe somebody has used Dolphin with CVS but we never
> pursued this ourselves since we found CVS far too tricky to set up.

I think its much easier to setup these days - and everyone is raving about
Subversion. Also things like Tortoise CVS make these tools much easier to
use (especially for non developers that are on your team). I don't want to
dismiss Omnibase - I'm sure its cool - but this is something worth
considering. The Eclipse trick of haivng local history - and then versioning
to a VCS (like CVS) is actually a good compromise. And having seen how Ian
leverages the changes.sml to give local history - I was quite taken by how
that makes Dolphin very close to Eclipse/IntelliJ. I don't usually care
about other user's editions - but do care about their versions (e.g. what
went into the VCS).

I like the idea that the option is open - and I guess we can play with this
a bit more (I will) - but thought it was worth mentioning to everyone.
Smalltalk has many moments where small decisions put people off - and we
need to make sure we learn from those crossroads (I really applaud your
controversial use of Scintilla - its those leaps that make a big
difference).

Tim



"Andy Bower" <[hidden email]> wrote in message
news:[hidden email]...

> TimM,
>
>> At first I was quite excited by the notion of Dolphin6 integrating
>> Omnibase.
>>
>> Many years ago - I really enjoyed Envy/Developer in IBM Smalltalk.
>>
>> However, the more I think about it (and I haven't used Omnibase yet)
>> the more I'm thinking - maybe this isn't a great idea after all?
>>
>> I say this becuase Envy's flaw was how to version other program
>> artifacts - things like documentation, database scripts etc (it wasn't
>> really built for this). You could kind of get them into the
>> proprietery envy database but that limited how other non-coding team
>> members could access the resources and update them.
>>
>> Having had a scout around the Omnibase website - I don't see anything
>> about this issue?
>
> First of all, I think it is important to distinguish between Omnibase
> (which is a general-purpose object database) and the Source Tracking
> System which is the ENVY-like source control component that uses
> Omnibase for its underlying storage.
>
> Anyway, you are right, the issue of storing non-code artefacts does
> exist when using the Source Tracking System.  It would be good if we
> could store other objects (files) in there too but I don't think David
> Gorisek had any current intention is to enhance the product in this
> area.  I'm not sure how most STS users deal with this issue at present
> but my suggestion would be to use STS in parallel with a more
> traditional file based system and match up the two based on version
> numbers.
>
>> So this gets me thinking (and this is what in part drove IBM's push in
>> envy to use an open version control system) why bother using Omnibase
>> - and not just better integrate Subversion or CVS support?
>>
>> All you need is a decent diff tool, and then someting like Ian B's
>> change browser (to get method editions etc) to do most things that
>> envy does. Also is the benefit that other users can use Tortoise to
>> put associated artifacts in the VCS.
>>
>> I am interested in other peoples views on this - but it does concern
>> me that the silver bullet of Omnibase might actually be detrimental -
>> and maybe adopting a more Eclipse "open vcs" like approach would be
>> far more usefulm and better support larger teams.
>
> As you probably know the existing Source Browser tool and the PAX
> format can already be used to store Dolphin "source objects" in a more
> traditional file-based SCCS.  We, in fact, use this method internally
> with SourceSafe and have done since 1995. One of the reasons we haven't
> made more of this facility is that the SourceSafe integration is rather
> "fiddly", involving a certain amount of messing around with version
> names etc.  I believe somebody has used Dolphin with CVS but we never
> pursued this ourselves since we found CVS far too tricky to set up.
>
> Dolphin 6 will still retain the existing ability to use the Source
> Browser with an external SCCS so developers will have the choice as to
> which system fits their way of working the best. I'm not sure that I
> would agree that a file based approach would better support large teams
> although STS isn't really suitable for disconnected (from the
> repository) working. The great thing about the Source Tracking System,
> though, is that the integration with Dolphin is very tight and having
> all the past version information online at any time is a great boon.
>
> Best Regards,
>
>
> --
> Andy Bower
> Dolphin Support
> www.object-arts.com


Reply | Threaded
Open this post in threaded view
|

Re: Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

Chris Uppal-3
TimM wrote:

> I think its much easier to setup these days - and everyone is raving about
> Subversion. Also things like Tortoise CVS make these tools much easier to
> use (especially for non developers that are on your team).

I think it depends on what you consider SCC to /be/.  Unfortunately gross old
SCC systems like CVS (and don't even mention that MS "thing"), less gross
systems like Subversion, and even the more modern ideas like <I've forgotten
its name> and <I've forgotten this one's name too>, all suffer from the same
fundamental architectural problem -- they think that they are about /files/
rather than about /information/.

It would be perfectly possible for Subversion -- for example -- to be defined
(at the lowest level of the public API) in terms of hierarchically arranged
data, with files being one application of that idea.  But that (as far as I
know) is not what they've done.  The lowest level of the API is at the
check-out-a-file level (I can't remember whether Subversion specifically has
that concept, but you get the idea).  That makes them all but useless -- or at
least woefully underpowered -- for a system like Dolphin that is not based on
the code == file paradugm[*].

As an aside, if I were attempting to use a file-based SSC system to hold
Dolphin code, then rather that pushing out the current state of each class's
code as the versionable artefact, I'd want to push out the entire history of
each method (and class def, etc) as the versionable artefact.  (Not as
expensive as it sounds since the diff between each successive history snapshot
would be more-or-less the new definition of the method.)

    -- chris

([*] that started out as a mistype for "paradigm", but I rather like the new
word, so I've left it in ;-)


Reply | Threaded
Open this post in threaded view
|

Re: Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

TimM-3
"Chris Uppal" <[hidden email]> wrote in message
news:433cef64$0$38045$[hidden email]...

> less gross
> systems like Subversion, and even the more modern ideas like <I've
> forgotten
> its name> and <I've forgotten this one's name too>, all suffer from the
> same
> fundamental architectural problem -- they think that they are about
> /files/
> rather than about /information/.

I think I'll have to give STS a spin in the next beta (hopefully) - but I'm
trying to keep an open mind after feeling constrained by Envy the last time
around, and seeing how file/based paradigms have at least improved over the
last few years (and yes I agree they are the wrong paradugm).

Subversion+Tortoise is at least easy to install and reasonably intuitive
(although not perfect ;-)

Tim


Reply | Threaded
Open this post in threaded view
|

Re: Is the D6 move to Omnibase a bad idea (what happens to non-code artifacts?)

Chris Uppal-3
TimM wrote:

> I'm trying to keep an open mind after feeling constrained by Envy the
> last time around, and seeing how file/based paradigms have at least
> improved over the last few years

Oh sure, I was just presenting an alternative view -- not attempting to
persuade you that STS would be the ideal tool for your purposes.

(Actually, I have yet to fnd a SCC system that works even remotely how I think
they should...  Someday I may write my own.  In the interim, STS does the
things I ask of it without disturbing my workflow too much)

    -- chris