SCCS integration problems

I'm working on getting Dolphin to work with external version control systems
such as RCS or Visual SourceSafe, and I'm making some progress.  (For those
interested, go to
http://www.nls.net/mp/jarvis/Bob/DolphinGoodies.htm and download the
appropriate files).  The problem I have now is that the process is too
manual, and I'd like to automate the checkout process so that if you make a
change to e.g. a class which is part of a package under source control, the
appropriate file should be automagically checked out.  OK, so off I go
looking through the image for appropriate events to hook into, and there in
Package is the #changed event.  I concoct a bit of code, hook into Package's
#changed event, change a Package, and wahoo!  I get the appropriate event!
I make another change to the same package and...no event.  A bit more
investigation reveals that Package only triggers a #changed event if the
'changed' status of the package is changed - e.g. when the package goes from
'unchanged' to 'changed'.  Drat...

Anyone got any ideas?  I suppose I *could* check out all files in the
package when any change is made, but that defeats the purpose of having
multiple files (in PAX format) so that potentially multiple developers can
work on multiple parts of a package with (minimal) interference.  Andy/Blair
- any chance of getting Package changed so it triggers some event whenever a
change is made?

Thanks.

Bob Jarvis

Bob

"Bob Jarvis" <[hidden email]> wrote in message
news:[hidden email]...
> I'm working on getting Dolphin to work with external version control
systems
> such as RCS or Visual SourceSafe, and I'm making some progress.  (For
those
> interested, go to
> http://www.nls.net/mp/jarvis/Bob/DolphinGoodies.htm and download the
> appropriate files).  The problem I have now is that the process is too
> manual, and I'd like to automate the checkout process so that if you make
a
> change to e.g. a class which is part of a package under source control,
the
> appropriate file should be automagically checked out.  OK, so off I go
> looking through the image for appropriate events to hook into, and there
in
> Package is the #changed event.  I concoct a bit of code, hook into
Package's
> #changed event, change a Package, and wahoo!  I get the appropriate event!
> I make another change to the same package and...no event.  A bit more
> investigation reveals that Package only triggers a #changed event if the
> 'changed' status of the package is changed - e.g. when the package goes
from
> 'unchanged' to 'changed'.  Drat...
>
> Anyone got any ideas?  I suppose I *could* check out all files in the
> package when any change is made, but that defeats the purpose of having
> multiple files (in PAX format) so that potentially multiple developers can
> work on multiple parts of a package with (minimal) interference.
Andy/Blair
> - any chance of getting Package changed so it triggers some event whenever
a
> change is made?

The individual objects in the package (classes, resources, etc) are also
flagged individually as "changed", and events are triggered when they are
changed/added (see the events published by SmalltalkSystem and
ResourceManager). These are the events that are picked up by the various
browers to keep them in sync.

Regards

Blair

Blair,

> The individual objects in the package (classes, resources, etc) are also
> flagged individually as "changed", and events are triggered when they are
> changed/added (see the events published by SmalltalkSystem and
> ResourceManager). These are the events that are picked up by the various
> browers to keep them in sync.

Has this changed in D4.01?  I used (in D4.0) to just catch #packageChanged
from the PackageManager, which worked OK up till recently (I think).  Bob's
note made me realise that things had stopped working.

I'm not sure now what I ought to be trapping (as you may remember, I have a
need to keep up-to-date with all the currently loaded packages), after some
hours getting badly confused while trying to get my stuff working again, I'm
now trapping all of:

    #loadedChanged
    #owndedChanged
    #prerequisitesReset
    #classRepackaged:from:to:
    #methodRepackaged:from:to:
    #resourceRepackaged:from:to:
    #globalRepackaged:from:to:
    #packageChanged:

as they are generated by the PM .

That works OK again now, *except* that I'm no longer getting told about
changes to any of:

    package version
    package comment
    package scripts

unless they cause the package's changed flag to get set.

This affects the "standard" package browser too, so there's been a
regression to the days when changes to packages' comments, etc, weren't
propagated properly.

Can I ask that you go back to the old behaviour for the #packageChanged:
notification please ?  It seems more logical to me, anyway.

Also, I *think* that it's unnecessary for me to be trapping the 4 new
events:
    #classRepackaged:from:to:
    #methodRepackaged:from:to:
    #resourceRepackaged:from:to:
    #globalRepackaged:from:to:
since they are only sent when #ownedChanged: is sent (and I don't need the
extra detail).  Can you confirm that that is how you intend it to be used
please ?

(BTW, those 4 haven't been added to PackageManager
class>>publishedEventsOfInstances, I presume that's just an oversight).

I don't know if it's bug or not, but you used to generate
#prerequisitesReset whenever a method was changed (on the grounds that the
prerequisites cache was possibly out-of-date).  That doesn't seem to happen
anymore.  I'd have said that the old behaviour was more correct.

> Blair

    -- chris

On Thu, 29 Mar 2001 23:07:13 -0500, "Bob Jarvis" <[hidden email]>
wrote:

>I'm working on getting Dolphin to work with external version control systems
>such as RCS or Visual SourceSafe, and I'm making some progress.
[snip]

Are you involved with the CVSTProject on SourceForge at:

        https://sourceforge.net/projects/cvstproj/

I've been using Revision Control System (RCS) for a year, but just
parking whole ".pac" or ".st" files there using a DOS window --
painful!

I've wanted to check out the CVST project to see if it would fit in
with Dolphin but haven't had time to get to it.  I went to their site
and it looks promising, but I don't think they have a Dolphin
interface yet.

I'd like to get involved with CVST, but it will have to wait until I
finish my current project.  I've reworked Eric Arseneau's SIF.  He's
done some really nice work with it.  He has implementations on his
site for Dolphin, Squeak, VW, and VAST.

It doesn't handle variable type classes (variableSubclass ... or
variableByteSubclass ...), but I added one short method and changed
two or three lines in another to fix this.

It is really quick.  It reads my test SIF file containing definitions
and initializers for three classes, 6-8 methods, two pools, and two
global fast enough to load the file in setup which is run before each
of the 6-8 SUnit test case methods I put together for my reworked
version.

I wanted some minor changes to use it to load one common SIF
CampSmalltalk SUnit ANSI Tests file on all versions.

In Dolphin my reworked SIF version builds a Package instance from the
SIF file contents read.  It files out a Package instance contents to a
file in SIF (except for resources).  In Squeak it builds a ChangeSet
instance from the SIF file read, and files out ChangeSet instance to a
SIF file.  This allows me to work using the dialect's normal tools,
but pass files between dialects using SIF.  I expect a port to VW of
my reworked SIF to do parcels (I think that is the usual package of
code), and in VAST I think package of code in called an application.

Eric Arseneau did a some really nice work on SIF.  It is small, and
nicely segmented for porting to other dialects.  I've been
experimenting with his version for a couple of weeks.  I cut the size
about in half, and simplified it even further.  I'll pass on my work
to him after I get the Squeak port of the my Dolphin version done and
see them seamlessly pass SIF files back and forth.

I saw where the CVST project stuff talks about using SIF to store the
changes in CVS.  Seems like a good approach.  I can keep an one file
for the application model and use it in any dialect.  Only the
application GUI need be dialect specific.  With Dolphin 4.0 ".pax"
files, I think a Dolphin interface to CVST shouldn't be too difficult.

Bob, I'll be interested in what you learn on getting Dolphin to work
with external version control systems.  I'll take a look at your site
also.

--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

On Sun, 01 Apr 2001 19:23:02 GMT, [hidden email] (Richard A.
Harmon) wrote:
[snip]
>I've reworked Eric Arseneau's SIF.  He's
>done some really nice work with it.  He has implementations on his
>site for Dolphin, Squeak, VW, and VAST.
[snip]

Eric Arseneau's SIF Site:

        http://www.PocketSmalltalk.com/sif


--
Richard A. Harmon          "The only good zombie is a dead zombie"
[hidden email]           E. G. McCarthy

Chris

You wrote in message
news:[hidden email]...
> [re: Package/PackageManager events]
> Has this changed in D4.01?  I used (in D4.0) to just catch #packageChanged
> from the PackageManager, which worked OK up till recently (I think).
Bob's
> note made me realise that things had stopped working.

Nope. There is no significant change from 4.0, when this was extensively
revised (you may recall the discussion during the beta). I say "significant"
because there have been some bug fixes in this area, one to fix a package
pre-req maintenance bug associated with loose methods (which was in 4.0 PL1,
i.e. in as of end November 2000), but nothing since.

> I'm not sure now what I ought to be trapping (as you may remember, I have
a
> need to keep up-to-date with all the currently loaded packages), after
some
> hours getting badly confused while trying to get my stuff working again,

I'm a bit confused as to why there is any difference from 4.0. It may be
that there is, but I cannot spot it in the source code history or bugs DB.

Yes, I can see that would be so.

> This affects the "standard" package browser too, so there's been a
> regression to the days when changes to packages' comments, etc, weren't
> propagated properly.

That follows, though since those attributes have never kept in sync. in the
package browsers (certainly they didn't in 3.0), there hasn't been any
regression there.

> Can I ask that you go back to the old behaviour for the #packageChanged:
> notification please ?  It seems more logical to me, anyway.

The reason for dropping the original meaning of #packageChanged: was that it
was too generic; what has changed about the package? This is either not much
use (if one needs to identify what has changed oneself then it means
duplicating information to compare against, or if one is merely maintaining
a display it mean refreshing the entire lot in a rather brute force
fashion). This, and the number of events that were being generated in
response to every change, caused the package system in D3 to significantly
slow down the loading of packages, especially if a package browser was open
at the time (doh!).

The idea in 4.0 was to move to specific events that identified the change
directly so that one can do minimal work to refresh. The Package #changed
event (and the linked PackageManager #packageChanged: event) is badly named
since it is just reporting that the change flag had been toggled. It is all
the more confusing because , but it should have been renamed more
significantly to reflect that. The version, comment, and scripts were
overlooked.

> Also, I *think* that it's unnecessary for me to be trapping the 4 new
> events:
>     #classRepackaged:from:to:
>     #methodRepackaged:from:to:
>     #resourceRepackaged:from:to:
>     #globalRepackaged:from:to:
> since they are only sent when #ownedChanged: is sent (and I don't need the
> extra detail).  Can you confirm that that is how you intend it to be used
> please ?

#ownedChanged: is intended to be a summary event.

>
> (BTW, those 4 haven't been added to PackageManager
> class>>publishedEventsOfInstances, I presume that's just an oversight).

Yes. Thanks for pointing it out.

> I don't know if it's bug or not, but you used to generate
> #prerequisitesReset whenever a method was changed (on the grounds that the
> prerequisites cache was possibly out-of-date).  That doesn't seem to
happen
> anymore.  I'd have said that the old behaviour was more correct.

The #prerequisitesReset event is telling the observer that the package's
cached prerequisites tree has been reset, and that any further "copy" of
that pre-requisites tree (for example in a pre-requisites browser) should
similarly be reset. If something requests those pre-requisites again, then
the cache will be refilled, and the event will again fire on the next change
(i.e. if it is known that something might be using the information, then
they can be informed that it has been invalidated). It is not intended to
indicate merely that some change has occurred that might affect package
pre-requisites - that information would be redundant.

Regards

Blair

Oh goodie!  I was hoping that someone would be working on something like
this.  If there is ever a PvcsSourceManager, VersionsSourceManager,
GpVersionSourceManager, or even better an SccApiSourceManager, please
let me know.  Ditto if anyone is working on such a project and would
like help.  I probably won't get to it myself, at least not alone.

Keith Alcock


Bob Jarvis wrote:

"Richard A. Harmon" <[hidden email]> wrote in message
news:[hidden email]...
> On Thu, 29 Mar 2001 23:07:13 -0500, "Bob Jarvis" <[hidden email]>
> wrote:
>
> >I'm working on getting Dolphin to work with external version control
systems
I agree - text windows and arcane commands *are* painful.  That's what
motivated me to do this work.

No, I'm not involved with the CVSTProject.  I'm vaguely aware of what
they're doing, and I think they're one or two light-years beyond the simple
scope of what I'm trying to accomplish.  (I have considered, in general
terms, harnessing CVS to Dolphin.  I think it's doable, but it's not (yet)
something I'm going to dive into.  If someone wants to grab my code and
start hacking - well, that's what it's there for).  This is just my attempt
to (relatively) quickly and (fairly) easily get my favorite SCCS (RCS)
working with Dolphin.  So far, I'm pleased - at least the bloody thing
*works*, and I'll say right here and now that I'm grateful for and impressed
by the Dolphin base code (thanks, guys!) - I'm just not happy with the fact
that it's not as automagic as I'd like.  (Go read Heinlein's "The Man Who
Was Too Lazy To Fail" for some idea of my basic philosophy of life (thanks,
RAH)).  Checkout should occur without manual intervention IMO, much as
occurs in MS VC++ but without the blasted annoying dialogs.  (Do you ever
want to scream "YES!  YES!  I WANT TO CHANGE THE STUPID FILE, CHECK IT OUT
FOR ME AND QUIT BUGGING ME!!!!" when you get that stupid "<filename> is not
checked out.  Do you want to check it out?" dialog?  I do.  Frequently.  Did
I mention my past employment at the postal service? :-)  Of course, in the
past week I've gotten swamped at work (I'd ignore the stuff and do what I
want but (A) I'm married to the project manager, and I do value peace at
home, and (B) it's tough to justify making a project (not mine, thank Crom)
late because I'd rather do "research" (slang for "fun stuff I'd rather do
instead of the stuff I'm supposed to be doing")), so further automagic has
been temporarily back-burnered, but such is life.

> Bob, I'll be interested in what you learn on getting Dolphin to work
> with external version control systems.  I'll take a look at your site
> also.

Have at, MacDuff, and damned be he who cries, "Hold!  Enough!".  :-)
--
Bob & Karyl Jarvis

"Bob Jarvis" <[hidden email]> wrote in message
news:[hidden email]...

> (Go read Heinlein's "The Man Who
> Was Too Lazy To Fail" for some idea of my basic philosophy of life
(thanks,
> RAH)).

That sounds interesting.  Is it a book or a short story or what?  I couldn't
find it by searching on Amazon or half.com or Google.


-- Frank
[hidden email]

"Frank Sergeant" <[hidden email]> wrote in
<tldA6.183$[hidden email]>:

>> (Go read Heinlein's "The Man Who Was Too Lazy To Fail" for some idea
>> of my basic philosophy of life (thanks, RAH)).
>
>That sounds interesting.  Is it a book or a short story or what?  I
>couldn't find it by searching on Amazon or half.com or Google.
>

I'm pretty sure it's part of "Time Enough For Love" (one of my favourite
Heinlein books)

<Pause while I got downstairs to the other bookcase>

Yep, it is.

P.

"Paul Hudson" <[hidden email]> wrote in message
news:Xns907ED26AEDDECphudsonpoboxcom@127.0.0.1...
> >> (Go read Heinlein's "The Man Who Was Too Lazy To Fail" for some idea

> I'm pretty sure it's part of "Time Enough For Love" (one of my favourite
> Heinlein books)

Thank you.  I just dug up a copy and (re)read that section.  I read the book
25 years ago or so but, unsurprisingly, had forgotten about the Lazy Man.

     "-- and if they noticed that he never did a lick of work, nobody
mentioned it."


-- Frank
[hidden email]