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 |
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 |
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 |
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 ;-) |
"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 |
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 |
Free forum by Nabble | Edit this page |