Source Code Control for Visualworks

'lo all.

A while ago I had a problem where I lost some code because of Store (in VWNC 7.3.1).  Now I'm looking at my code, and I see some empty packages, and I'm not sure if it's because of Store, or because they're indicating what I intended.  I've tried browsing the previous versions for those packages, but, well, frankly I don't trust what I do/don't see there.

I don't trust Store at all.  I can't trust it -- it's already lost code on me once, that I know of.

Does anybody know of a *reliable* source code control system that I can use with VW?

Thank you for your time,

   - M.

Marco Qualizza wrote:
What database are you using for Store's backend? While there are certain
small bugs in Store, I haven't heard anything about it losing code and
we've been using it with PostgreSQL for few years now. So I'd say its
pretty reliable as far as things are concerned and ideally we'd try to
help you work through your problems if you provided a little more
information.

Cheers!

-Boris

How did you lose code?  I've had problems with Store, but not since the
5i.2/5i.3 timeframe.  I use it for BottomFeeder and Silt, so I'm not just
promoting here :)



At 11:46 PM 1/15/2006, you wrote:

At Soops we use Store for commercial development with 10+ people for several
years now. Store has (had) a lot of annoying quirks which would lead to Store
loading the code slightly differently from what we had published, but we
didn't see wholesale loss of the contents of a package.
Most problems we had revolve(d) around namespace support as well as the
specialized classes generated by the DLL and C Connect.

However we do always change one setting of Store in the VW settings tool: the
'Use fast comaprison' option is always off in our images. I don't know
whether that is still necessary on the current version, but in the past this
would lead to different behavior.

I don't know about any other SCM tool that is sufficiently compatible with
VisualWorks, so I advise to join our little club here and use Store and bitch
about it with us - preferably in such a consice way that it helps Cincom to
fix it and  lift it to the nineties, perhaps even the naughts some day.


OTOH if you feel like implementing a modern SCM for VW I'm sure you'll find
interested parties here :-)


Welcome to the club!

R
-

Marco Qualizza wrote:

Marco,

> I don't trust Store at all.  I can't trust it -- it's already lost code on
> me once, that I know of.

Store has lots of scope for improvement, that's for sure.  And I too
have felt that Store lost my code in the past, but I can't remember
the last time it happened.  I think this is a combination of me
getting better at using Store (perhaps learning it's soft spots), and
also Store getting better over time.

> Does anybody know of a *reliable* source code control system that I can use
> with VW?

Store is currently a good option for managing Smalltalk source code if
you are using VisualWorks or GemStone, and having lost Envy, I think
it's currently the best.

Other options would be to use one of the Squeak mechanisms
(Monticello(sp?)) or mapping your code to a file based SCM (there is a
library to help with CVS).

I suggest that you persevere with Store, and if you hit a problem stop
and ask about it on this list.  You can defend against losing code by
saving your work as a parcel from time to time (and if you use a
"master bundle" this will involve saving just the one parcel).

HTH
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

I lost some code when a student published parcels and in store at the  
same time. I ended up patching the
internal of store since some references where pointing to the wrong  
places. And of course the code even in the changeset was
corrupted. I was a bit amazed. The first time in my Smalltalker life  
that I lost code.

Since then we NEVER publish in parcels and in store at the same time and
this is ok.

Stef

On 16 janv. 06, at 05:46, Marco Qualizza wrote:

The only bug I can recall that would cause that kind of major code loss in the database was against SQL Server, and was fixed a couple of releases ago. The problem was two things combined - the sequence generation mechanism could end up causing a transaction conflict, and when you got one, a generalized exception handler would ask if you wanted to reconnect to the database and continue. Reconnecting and continuing would put you in a new transaction context, so all the writes that had been done before that were lost. This was very bad, and both of those things that combined have been corrected.

There were a couple of problems that could lead to Store storing "duplicate methods" in the database, in which case which one you'd get back when you loaded was somewhat random. This was sort of like losing code, but would normally affect only single methods. We think all of the conditions that could lead to this have now been eliminated.

The Fast Comparisons that Reinout talks about determine whether it uses the change set mechanism in the image to figure out what's changed, or if it does the equivalent of a reconcile when you go to publish. The second is likely to be more reliable, since it won't have problems if there's an issue with the change sets, but will take a bit longer. Especially with a local database it probably isn't a big performance hit, so turning it off is a reasonable thing to do. I run with it on, and haven't seen any problems, but that's just one data point.

At 05:18 AM 1/16/2006, Giorgio Ferraris wrote:

Hi,

I lost code using store long, long time ago, (probably on some 5.x version), and it was on an sql server db, but I suspect most of the problems derived from publishing store and parcel (and also the fact I was at that time one of the few using SQLserver, and the support in store was not the best)

Never lost code from that time, but I switched to postgres, just in case…

Giorgio Ferraris

 

---

Da: Marco Qualizza [[hidden email]]
Inviato: lunedì 16 gennaio 2006 5.47
A: [hidden email]
Oggetto: Source Code Control for Visualworks

 

'lo all.

 

A while ago I had a problem where I lost some code because of Store (in VWNC 7.3.1).  Now I'm looking at my code, and I see some empty packages, and I'm not sure if it's because of Store, or because they're indicating what I intended.  I've tried browsing the previous versions for those packages, but, well, frankly I don't trust what I do/don't see there.

 

I don't trust Store at all.  I can't trust it -- it's already lost code on me once, that I know of.

 

Does anybody know of a *reliable* source code control system that I can use with VW?

 

Thank you for your time,

   - M.

Marco:

I have used StORE for quite a while and so far the only times I "thought"
I lost code I could track to some mistake I made in a merge for example or
code that was really in a different package.

Have you actually performed some "tests" i.e. make up some dummy packages
publish them etc, the problem is deterministic. Mind you some have
complained about StORE regarding really long distance publishing. I don't
have network problems , I do publish remotely but I'm not going across the
Atlantic or any other body of water , well maybe the Hudson :)

Anyhow, there is really nothing else that you can use with VW and
furthermore I believe your fears are unwarranted. I would run some
experiments so that you have peace of mind.

-Charles


On Sun, 15 Jan 2006 23:46:55 -0500, Marco Qualizza <[hidden email]>
wrote:



--
Charles A. Monteiro

I actually would not recommend using Parcels as a source code management
scheme, even single developer projects benefit from real source code
management. One should use StORE, one should publish to a local repository
feverishly and to a team repository when appropriate for the purposes of
integration and making builds. Use Postgres as an rdms backend , thw
windows version installs easily and is basically good to go for single
developer use off the bat from my recollection.

For most intents and purposes StORE works quite well and quite reliably,
the tools can be improved for sure and they will be.

-Charles

On Mon, 16 Jan 2006 22:22:34 +1300, Stewart MacLean <[hidden email]>
wrote:



--
Charles A. Monteiro

Hello all, 

   Sorry for the delay, I *just* realized that I had managed to reply to myself without posting to the group. This is in answer to all of your questions/points. 

   Boris Popov: I'm running Store with Postgres 8.1.1. And I agree as far as Postgres goes -- I've been using it for a few years and have no complaints or questions. 

   James Robertson: Hello again.  The situation in which I initially started to notice loss was when I moved classes from one package to another. I posted on this list about it 11/11/2005 with the subject "Problems with Store". 

   Reinout Heeck: I too have turned off "Use fast comparison", but I did so after the initial loss in November. And I'll see what I can do about bitching about Store.  Although I really wish that there was a central site for Store/Store development (ie/ a website). *nudge nudge* 

   Bruce Badger: There's a Monticello port for VW? And the CVS library... does it do the same thing with CVS that Smalltalk/X does? (I *really* like how Smalltalk/X integrates with a well established SCM, instead of doing its own thing  ). About versioning habits, I *do* have a master bundle, and I always version it. In fact, in an effort to try to keep the "context" of changes that I make, I always version everything, even packages that haven't changed. Is there any chance that this is contributing to lossage? 

   Stewart MacLean: I'm using Store as a personal version control tool. I don't want to use parcels because of the whole change-history tracking thing... 

   Charles Monteiro: Unfortunately, I can't reliable reproduce the problem (yet). Which, unfortunately, does little to help my peace of mind.  

   As a final note, I run VW and Postgres on Linux (Gentoo, ~x86, up-to-date). 

   Thank you all for you insights and attempts to help. My complaints could have been received in a much different way, it says a lot that they weren't. 

   - Marco 

Sunday, January 15, 2006, 11:46:55 PM, you wrote:

-- 

Best regards,

 Marco                            [hidden email]

Marco Qualizza wrote:
>    Bruce Badger: There's a Monticello port for VW? And the CVS library... does
> it do the same thing with CVS that Smalltalk/X does? (I *really* like how
> Smalltalk/X integrates with a well established SCM, instead of doing its own
> thing  ).

I'm not sure how ST/X does it, but I imagine it's pretty close. You can
see easily how a "project" in it looks like, just by browsing the CVS
repository on source forge. It was versioning its own code back then
just fine. For a brief overview of how to use it I'd recommend this:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/cvstproj/cvstproj/CVSProject.html?rev=1.7
(I note the links on the home page are all dead, things must have
changed on SF since then).

Note that the last time I ran it in VW was probably one of the early 7
releases, so there might be something to be done to bring it into a more
recent version. But it was doing its thing reasonably well back then. If
you're really hung up on using CVS, it is probably worth your while to
check it out. The main things that I'd still want to do before starting
to use it seriously for VW development is:

1) Switching the image hookup from parcels to packages
2) Adding a codec for the XML source code format (right now you can only
do old style file-out or SIF)

 From time to time I get the urge to dust it off, but there's always
something more important to attend to :-). But I'm happy to discuss any
specific issues.

Generally I have to say that I don't see much of a point to it anymore.
It might have made sense if it managed to take off as a cross-dialect
VC, but it didn't. By now pretty much all dialects have their own
usually better integrated and more powerful systems. I'd definitely not
recommend it over any of those, certainly not with CVS in the backend.
Subversion might have changed it, as it seems to have addressed most of
the serious CVS limitations. But even then I doubt an SVN based solution
has as much potential as a native smalltalk VC. Smalltalk just isn't
about files.

Martin

On Jan 22, 2006, at 12:47 AM, Martin Kobetic wrote:

> Marco Qualizza wrote:
>>    Bruce Badger: There's a Monticello port for VW? And the CVS  
>> library... does it do the same thing with CVS that Smalltalk/X  
>> does? (I *really* like how Smalltalk/X integrates with a well  
>> established SCM, instead of doing its own thing  ).

[snip some details about CVSProject]

> Generally I have to say that I don't see much of a point to it  
> anymore. It might have made sense if it managed to take off as a  
> cross-dialect VC, but it didn't. By now pretty much all dialects  
> have their own usually better integrated and more powerful systems.  
> I'd definitely not recommend it over any of those, certainly not  
> with CVS in the backend. Subversion might have changed it, as it  
> seems to have addressed most of the serious CVS limitations. But  
> even then I doubt an SVN based solution has as much potential as a  
> native smalltalk VC. Smalltalk just isn't about files.

Yes. Martin is dead on here.

Monticello started out as a tool for filing out code so that it could  
be (more) easily versioned with CVS. It even had some ability to  
parse CVS conflict markers, and help with resolving bogus conflicts  
caused by the file format. Eventually we ditched CVS and did the  
versioning natively. Interestingly enough, it wasn't that hard. A  
decent front end for CVS, including a packaging mechanism, UI,  
conflict resolution etc, has a big chunk of the functionality you  
need for native versioning. On the other hand, native versioning is  
so much better than CVS, it's a huge win to go all the way.

Monticello doesn't currently run on VW. It would be nice if it did,  
because that would make cross-platform packages easier to maintain.

Colin

Hi Marco,

 

I appreciate your point on change history. It depends on your personal requirements.

 

I find I get by with browsing versions of methods from the change log via the method menu (which I only use when I want to back track). For system versioning, I’ve set up a single click system build and install that creates a directory for each build version with all the parcels etc that went into it. I also, copy and rename my development directory every now and then at milestones, in case I ever need to backtrack (which is very rarely). BTW, I’ve never lost any source code but managed to munge the parcel file pointers when I changed the default directory during testing within my development image.

 

Having said all that, I find Envy indispensable during my day job for team development.

 

All the best with Store,

 

Cheers,

 

Stewart

 

-----Original Message-----
From: Marco Qualizza [mailto:[hidden email]]
Sent: 21 January 2006 2:27
To: [hidden email]
Subject: Re: Source Code Control for Visualworks

 

Hello all, 

   Sorry for the delay, I *just* realized that I had managed to reply to myself without posting to the group. This is in answer to all of your questions/points. 

 

   Boris Popov: I'm running Store with Postgres 8.1.1. And I agree as far as Postgres goes -- I've been using it for a few years and have no complaints or questions. 

 

   James Robertson: Hello again.  The situation in which I initially started to notice loss was when I moved classes from one package to another. I posted on this list about it 11/11/2005 with the subject "Problems with Store". 

 

   Reinout Heeck: I too have turned off "Use fast comparison", but I did so after the initial loss in November. And I'll see what I can do about bitching about Store.  Although I really wish that there was a central site for Store/Store development (ie/ a website). *nudge nudge* 

 

   Bruce Badger: There's a Monticello port for VW? And the CVS library... does it do the same thing with CVS that Smalltalk/X does? (I *really* like how Smalltalk/X integrates with a well established SCM, instead of doing its own thing  ). About versioning habits, I *do* have a master bundle, and I always version it. In fact, in an effort to try to keep the "context" of changes that I make, I always version everything, even packages that haven't changed. Is there any chance that this is contributing to lossage? 

 

   Stewart MacLean: I'm using Store as a personal version control tool. I don't want to use parcels because of the whole change-history tracking thing... 

 

   Charles Monteiro: Unfortunately, I can't reliable reproduce the problem (yet). Which, unfortunately, does little to help my peace of mind.  

 

   As a final note, I run VW and Postgres on Linux (Gentoo, ~x86, up-to-date). 

 

   Thank you all for you insights and attempts to help. My complaints could have been received in a much different way, it says a lot that they weren't. 

 

   - Marco 

 

Sunday, January 15, 2006, 11:46:55 PM, you wrote:

 

>

'lo all.   A while ago I had a problem where I lost some code because of Store (in VWNC 7.3.1).  Now I'm looking at my code, and I see some empty packages, and I'm not sure if it's because of Store, or because they're indicating what I intended.  I've tried browsing the previous versions for those packages, but, well, frankly I don't trust what I do/don't see there.   I don't trust Store at all.  I can't trust it -- it's already lost code on me once, that I know of.   Does anybody know of a *reliable* source code control system that I can use with VW?   Thank you for your time,    - M.

 

 

 

 

-- 

Best regards,

 Marco                            [hidden email]