I haven't been very active with Dolphin for about a year, so the
following may be somewhat innaccurate...

I come from a C++ world which is file/project based and versioning
works smoothly with VSS/SVN/CVS. A callout also to the good folks at
'Beyond Compare' who make differencing really easy for source
code/binary/images/.doc/.pdf version comparison.

Anyway, the Dolphin image based system of code control in small talk is
still rather jarring for me. Which I think explains why some folks
here seem to prefer to start from the virgin Smalltalk image and add
patches then open their packages.

I like the idea of versioning each individual method with STS within
Dolphin. Would this be stored in the package file for which the method
is associated??

Would it make sense to have the C++ equivalent of an external .dsp/.dsw
file which I could click on in explorer? Then dolphin would load the
virgin smalltalk image, apply patches and open the corresponding
packages/dependencies.

Something like this would support the package loading workflow nicely.
I've never used 'Pax' workflow, but having 1 file / class seems a bit
too many files to manage.

Also as a previous person wrote, it would be nice to have a package
re-load capability. Even nicer if Dolphin monitors the package files
for changes, and offers to load if they are changed by the external
source control.

Also to support package workflow it would be helpful to offer to save
all modified packages on exit from Dolphin.

Thanks again for this fine product.

Chris Uppal wrote:
> TimM wrote:
>
> > I started to
> > find that local history was enough to roll back most things (in Dolphin
> > Ian B leverages the changes file to give this ability).
>
> ;-) Just a few days ago I rebuilt my image for the first time since 5th May
> 2004 -- just think of all the valuable history I would have lost...
>
> (I was hoping to make it through to D6, but I've been doing too much
> experimental external interfacing and must have got a rogue pointer somewhere
> :-( So I had to rebuild. Not a big deal anyway, and it least it was a chance
> to check (and find the odd error in) my rebuild process before D6 rolls
> around.)
>
>
> > Something we could do that lessens the impact of this is to make STS
> > visible as a network drive (or some subset of it). In our Envy days - Oli
> > Bye used a java library that made any object visible on the network using
> > SMTB (or some acronym like that - I recall is was some windows network
> > protocol). Anyway - he wrote an adapter for envy so everything appeared
> > as files accross the network. I'm sure it wouldn't be so hard to do this
> > for Dolphin.
>
> You mean SMB, I think. In theory it would be quite doable to make an SMB (over
> TCP/IP) server in Dolphin. I've speculated a few times about how to do it.
> The only problem (besides actually having to read the specs and write the code
> ;-) and the fact that I don't use SMB over TCP on my network[*]) is that I
> don't know whether its possible to run two SMB services on the same IP address.
> OTOH, an NFS server would be possible, but then you could only "see" the
> virtual files on a machine with an NFS client. So Unix boxes would see the
> data, but most Windows machines would be oblivious. What the world needs is a
> good, simple, cross-platform, virtual file system...
>
> -- chris
>
>[*] I'm trying to stick with the old-fashioned SMB over NetBUI approach for as
> long as possible since that isn't routable by accident ("accidents" like when
> sp2 silently opened up file access via (IIRC) dial-up accounts....)