IBM VisualAge has Envy (and so does VW from 5i.1 and earlier). VW has Store.
What's the best approach for similar functionality for Squeak?
Nevin
On Monday 28 October 2002 12:56 pm, Nevin Pratt wrote:
IBM VisualAge has Envy (and so does VW from 5i.1 and earlier). VW has Store.
What's the best approach for similar functionality for Squeak?
Probably DVS (available from SqueakMap) with an external CVS or other source code management program, and perhaps CVST as an interface with the CVS server.
Hi again!
Quoting Ned Konz ned@bike-nomad.com:
On Monday 28 October 2002 12:56 pm, Nevin Pratt wrote:
IBM VisualAge has Envy (and so does VW from 5i.1 and earlier). VW has Store.
What's the best approach for similar functionality for Squeak?
Probably DVS (available from SqueakMap) with an external CVS or other source code management program, and perhaps CVST as an interface with the CVS server.
Well, CVST (https://sourceforge.net/projects/cvstproj/) is a project with two components:
-CVSTProj -Sqcvs
CVSTProj tries to do approximately the same thing as DVS but using a different approach if I am not mistaken. It is mostly being developed by Martin Kobetic for VW but it has ports for VA, Dolphin and Squeak (impressive). In short - it is a code mirroring tool that can represent your code in source files on disk so that you can use classic CVS to manage them. Much like DVS.
Sqcvs is simply a Squeak implementation of the CVS pserver client/server protocol. It is 95% functional and probably just a few hours away of being useful. What can it do? Well, it can do the same thing that CVS.exe can but from inside Squeak using Sockets directly to the CVS server. This gives a few advantages:
1. You don't need CVS on the client. Squeak can do it all by itself. 2. You don't even have to have "files". Sqvs uses a model object which can of course in turn use the filesystem but equally easy it could go straight to your classes or some other model! 3. Since it is in Squeak we have better control, which means we can do slick tricks. ;-)
So in short - if you intend to use DVS I see no need for CVSTProj. Sqcvs on the other hand could be a nice partner with DVS, but unless you like to code - that isn't true yet.
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
On Mon, 28 Oct 2002, [ISO-8859-1] G�ran Hultgren wrote:
So in short - if you intend to use DVS I see no need for CVSTProj. Sqcvs on the other hand could be a nice partner with DVS, but unless you like to code - that isn't true yet.
Perhaps we could take a couple of hours at OOPSLA and try to make this integration a reality?
Hi all!
Quoting Avi Bryant avi@beta4.com:
On Mon, 28 Oct 2002, [ISO-8859-1] Göran Hultgren wrote:
So in short - if you intend to use DVS I see no need for CVSTProj.
Sqcvs on the
other hand could be a nice partner with DVS, but unless you like to
code - that
isn't true yet.
Perhaps we could take a couple of hours at OOPSLA and try to make this integration a reality?
Yep, I am all for that. Silly enough it would probably work just fine already because the only "crucial" operations I haven't added are "add" and "remove" IIRC. And since DVS typically don't have many files... :-)
What about that btw - what is your reasoning about having one file per package (instead of say one file per class)? It sort of "defeats" interesting properties in CVS I think. But you may have very good reasons of course.
And another thing, what do you think about the "decisions about how we proceed with modules" I have been trying to get people buzzing about?
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
On Mon, 28 Oct 2002, [ISO-8859-1] G�ran Hultgren wrote:
What about that btw - what is your reasoning about having one file per package (instead of say one file per class)? It sort of "defeats" interesting properties in CVS I think.
But having one file per class defeats some nice properties of changesets - they impose an order on loading in classes (so you don't define a subclass before its superclass), they are easy to distribute and install, Squeak automatically deals with them even when compressed, etc.
Having too many files also makes CVS unwieldy - you always have to be doing adds and removes, revision numbers are on the class and not the entire package, and so on. And the major advantage - that conflicts are kept low - is taken care of fairly well by the order in which DVS files things out.
However, if sqcvs integration was done (so that adds and removes could be done automatically), and using .sar as a packaging format (and generating an install script that loaded everything in the right order), then it might make sense to finish working on the DirectoryPackageDumper, which files out each method and class definition as a separate file.
And another thing, what do you think about the "decisions about how we proceed with modules" I have been trying to get people buzzing about?
Well, I'm personally going to continue making 3.2 the best (as defined by "most useful to me") environment I can, without worrying for a moment about duplicating functionality that may or may not exist in 3.3a. Either everyone else will make roughly the same decision, or they won't.
Avi
Well, I think the answer depends on your goals. CVST (I hope it's OK if I use it as a short for CVSTProj part of it in this message :-) is aiming at: 1) merging Smalltalk with the "source tree" style of projects. 2) portable framework allowing to run a project across several dialects.
For 1) I believe that file per class is a better match. More granular history of the project allows you to answer questions like "When was this class changed ? How many times ? ", allows rollback of individual classes, etc. Which I think are frequent enough to warrant the support. I don't find the argument about load ordering too strong, it's a pretty trivial algorithm, since with the built in Undeclared mechanism the class hierarchy is the only thing you really need to deal with. I admit that more frequent adds/removes/renames are additional overhead, but that's more CVS "feature" than anything else. Better SC tool will make that easier.
It seems to me that DVS is more focused on Squeak than on CVS and there's not as much drive to get as much out of the SC tool as you can. In which case file per package sounds reasonable too. I suspect that both DVS and CVST have a lot in common as they both synchronize the state in the image with the state in the source file tree (computing changes, applying them to the image or to the files, etc). To address goal 2) CVST adds flexible source code format support (you really have to use SIF to run cross-dialect at the moment) and explicit portability interfaces to aid porting efforts. I don't know how far is DVS in that area.
In any case DVS definitely does seem to have more drive behind it in the Squeak camp at the moment. The Squeak port of CVST is lagging behind the VW, VA and Dolphin ports by one version at the moment (as there was no Squeak person in our group at Camp Smalltalk 4 in Colorado) and I definitely won't have time to spend on it. Of course I am sorry to see CVST loosing in the Squeak circles, but that's natural when a more active alternative comes in. Especially if the alternative focuses on more urgent needs of the community.
Best regards,
Martin
Martin Kobetic, Cincom Smalltalk Development, http://www.cincom.com/smalltalk ----- Original Message ----- From: "Avi Bryant" avi@beta4.com To: squeak-dev@lists.squeakfoundation.org Sent: Monday, October 28, 2002 3:50 PM Subject: Re: Envy or Store or what?
On Mon, 28 Oct 2002, [ISO-8859-1] Göran Hultgren wrote:
What about that btw - what is your reasoning about having one file per package (instead of say one file per class)? It sort of "defeats" interesting properties in CVS I think.
But having one file per class defeats some nice properties of changesets - they impose an order on loading in classes (so you don't define a subclass before its superclass), they are easy to distribute and install, Squeak automatically deals with them even when compressed, etc.
Having too many files also makes CVS unwieldy - you always have to be doing adds and removes, revision numbers are on the class and not the entire package, and so on. And the major advantage - that conflicts are kept low - is taken care of fairly well by the order in which DVS files things out.
However, if sqcvs integration was done (so that adds and removes could be done automatically), and using .sar as a packaging format (and generating an install script that loaded everything in the right order), then it might make sense to finish working on the DirectoryPackageDumper, which files out each method and class definition as a separate file.
And another thing, what do you think about the "decisions about how we proceed with modules" I have been trying to get people buzzing about?
Well, I'm personally going to continue making 3.2 the best (as defined by "most useful to me") environment I can, without worrying for a moment about duplicating functionality that may or may not exist in 3.3a. Either everyone else will make roughly the same decision, or they won't.
Avi
On Mon, 28 Oct 2002, Martin Kobetic wrote:
Of course I am sorry to see CVST loosing in the Squeak circles, but that's natural when a more active alternative comes in. Especially if the alternative focuses on more urgent needs of the community.
Yes - and in this case, the urgent need was to have a better way of categorizing source into packages. I'm sure CVSTProj works well for Dolphin, VW, etc, which already have good notions of modularity. In Squeak, however, CVST relies on changesets to define packages, which is (in my experience) a fragile and frustrating way of managing code. This was one major impetus behind developing DVS instead of working on CVSTProj (the other was that I was curious to try an approach that I have since abandoned, of translating unified diffs from CVS into Squeak changesets - the D in DVS stood for Diff-based).
Cheers, Avi
Ned Konz ned@bike-nomad.com said:
What's the best approach for similar functionality for Squeak?
Probably DVS (available from SqueakMap) with an external CVS or other=20 source code management program, and perhaps CVST as an interface with=20 the CVS server.
With all respect to the guys behind DVS and CVST: I think it's a dead end. I have been using CVS ever since it was a bunch of shellscripts around RCS (look that up in the history of computing ;-)), and while it's sort of OK, compared to "the real thing" like StORE it has some very serious shortcomings which makes it unsuitable as the basis for a nice, friendly versioning system for a Smalltalk environment. The most serious thing missing is lack of metadata versioning, working around is probably just as hard as building something new on top of a decent versioning system.
Smalltalk, and Squeak in particular, is about doing The Right Thing. CVS is, IMNSHO, a crutch that is absolutely necessary at the moment to have something, but definitely not The Right Thing.
Reinventing wheels is maybe not the right thing either. Cincom pulled off a great job with StORE, and it's a great piece of code, but I don't think it's something we should reproduce. Maybe talking to a WebDAV server?
Freshmeat has a lot of stuff: http://freshmeat.net/browse/52/?topic_id=52 - I'm going to browse and see whether there is something cool between all the chaff...
(so, here I go again. Talking about what should be done while knowing that I don't have the time to do it or even help out. My apologies, I hope you can live with that bad habit of mine...)
Cees de Groot cg@cdegroot.com said:
Smalltalk, and Squeak in particular, is about doing The Right Thing. CVS is, IMNSHO, a crutch that is absolutely necessary at the moment to have something, but definitely not The Right Thing.
If DVS can use multiple backends, wouldn't Subversion be a better choice?
(featureset seems right, and from ArgoUML I know that tigris.org can churn out nifty stuff)
(and yes, I'll be happy to host a repository ;-))
On 28 Oct 2002, Cees de Groot wrote:
If DVS can use multiple backends, wouldn't Subversion be a better choice?
DVS doesn't care what SCM it's used with - it just syncs the image with the filesystem, and how the files got there is Somebody Else's Problem. So SVN would work great with it. (In fact, DVS barely cares about the filesystem - any external system that can store and retrieve chunk-format source is fine, just write a simple Dumper/Loader pair for it).
Subversion would be especially cool if someone implemented WebDAV in Squeak, so that we could talk to it directly rather than going to files. But, yes, it would be a good choice even without that. The only reason I personally use CVS right now is that sourceforge is a convenient place to host a public repository. If you set up a public SVN server I could probably be convinced to move Seaside, etc, to it.
Avi Bryant avi@beta4.com said:
Subversion would be especially cool if someone implemented WebDAV in Squeak, so that we could talk to it directly rather than going to files. But, yes, it would be a good choice even without that. The only reason I personally use CVS right now is that sourceforge is a convenient place to host a public repository. If you set up a public SVN server I could probably be convinced to move Seaside, etc, to it.
I'll take up that challenge. BTW: Subversion has a SWIG'ed interface, so building a module directly accessible from Squeak would be a possibility as well.
On 29 Oct 2002, Cees de Groot wrote:
BTW: Subversion has a SWIG'ed interface, so building a module directly accessible from Squeak would be a possibility as well.
But as Colin pointed out, SVN's client interface seems to depend heavily on callbacks. I'm not sure how SWIG helps us there.
On Monday, October 28, 2002, at 12:48 PM, Cees de Groot wrote:
Cees de Groot cg@cdegroot.com said:
Smalltalk, and Squeak in particular, is about doing The Right Thing. CVS is, IMNSHO, a crutch that is absolutely necessary at the moment to have something, but definitely not The Right Thing.
I agree here, up to a point. DVS makes using CVS Squeak fairly painless, but it's far from ideal.
If DVS can use multiple backends, wouldn't Subversion be a better choice?
I'm a big fan of Subversion, but I think integrating it with Squeak nicely would quite difficult. Subversion is designed as a set of libraries that a Subversion client can link against. But the API they present uses a lot of callbacks, so calling into it via FFI would be tricky at best.
Another option would be to just use the svn client. This is easy, but not much of an improvement over using cvs. Svn is "a better CVS," so you still have hassle of synching code back and forth between a working copy and your image.
Avi mentions the possibility of implementing a WebDAV client. That would be a start, but you'd still have to implement an SVN client on top of that, since Subversion's use of WebDAV is fairly specialized. So this is a fair amount of work.
I think implementing our own respository similar to ENVY or StORE would be a pretty attractive option. It's probably not that much more work than implementing DAV, for example, or the CVS pserver protocol...
Cheers,
Colin
Colin Putney Whistler.com
Cees de Groot wrote:
Ned Konz ned@bike-nomad.com said:
What's the best approach for similar functionality for Squeak?
Probably DVS (available from SqueakMap) with an external CVS or other=20 source code management program, and perhaps CVST as an interface with=20 the CVS server.
With all respect to the guys behind DVS and CVST: I think it's a dead end. I have been using CVS ever since it was a bunch of shellscripts around RCS (look that up in the history of computing ;-)), and while it's sort of OK, compared to "the real thing" like StORE it has some very serious shortcomings which makes it unsuitable as the basis for a nice, friendly versioning system for a Smalltalk environment. The most serious thing missing is lack of metadata versioning, working around is probably just as hard as building something new on top of a decent versioning system.
Smalltalk, and Squeak in particular, is about doing The Right Thing. CVS is, IMNSHO, a crutch that is absolutely necessary at the moment to have something, but definitely not The Right Thing.
Reinventing wheels is maybe not the right thing either. Cincom pulled off a great job with StORE, and it's a great piece of code, but I don't think it's something we should reproduce. Maybe talking to a WebDAV server?
This (to me) is a huge tragedy. I'm a bit more guarded about Store than you (as a hardcore user); I'd say Store is in the process of becoming cool. We've had to add a number of tools around it to really create a good process on top of it. But I will say this, once done, it sure does beat the heck out of fileouts and such. The real tragedy to me though is the "reinvent it all in every version of Smalltalk known to mankind" philosophy the Smalltalk world has. A well known guru was known to ask "why are you all still programming in Smalltalk?" (paraphrased). To which I'd answer "because we just love rehashing the same stuff over and over and over and over again." Bottom line, why not just target the Squeak stuff at a PostgreSQL database. How I would love to interchange modules with Squeak in VW. I'm using the compression one right now. But someone had to go through effort to jump it from one environment to the other. And now they drift apart.
Freshmeat has a lot of stuff: http://freshmeat.net/browse/52/?topic_id=52 - I'm going to browse and see whether there is something cool between all the chaff...
(so, here I go again. Talking about what should be done while knowing that I don't have the time to do it or even help out. My apologies, I hope you can live with that bad habit of mine...)
Ditto.
Travis Griggs tgriggs@keyww.com said:
This (to me) is a huge tragedy. I'm a bit more guarded about Store than you (as a hardcore user); I'd say Store is in the process of becoming cool.
Why am I not hardcore? My company depends on it - is that hardcore enough? ;-)
Coming from where I came - Java, CVS - StORE is very cool.
Bottom line, why not just target the Squeak stuff at a PostgreSQL database.
That'd be nice. However, Cincom didn't exactly go through great lengths to make StORE interoperable: the code is closed, the database dictionary is undocumented, and there's no apparent process to change StORE; everything is heavily dependent on VW's concepts (packages, namespaces) which are quite like, but probably completely incompatible with, Squeak's ideas on these topics.
Unless StORE gets open sourced or there is a similar agreement that puts both 'players' (Cincom, the Squeak community) on a level field, I think it's a tempting, but bad, idea.
First of all, let me apologize for the tone of yesterday's message. Avi and Goran (and others) have been working hard to make the simplest thing that could possibly work, work. And my message would probably seem to say "screw the work you're doing". And that was not my intent, and I apologize for sending such a negative vibe.
Cees de Groot wrote:
Travis Griggs tgriggs@keyww.com said:
This (to me) is a huge tragedy. I'm a bit more guarded about Store than you (as a hardcore user); I'd say Store is in the process of becoming cool.
Why am I not hardcore? My company depends on it - is that hardcore enough? ;-)
Sorry Cees, I wasn't trying to imply that you weren't hardcore, your evaluation of Store is as every bit valid as mine is.
Coming from where I came - Java, CVS - StORE is very cool.
Bottom line, why not just target the Squeak stuff at a PostgreSQL database.
That'd be nice. However, Cincom didn't exactly go through great lengths to make StORE interoperable: the code is closed, the database dictionary is undocumented, and there's no apparent process to change StORE; everything is heavily dependent on VW's concepts (packages, namespaces) which are quite like, but probably completely incompatible with, Squeak's ideas on these topics.
Now this seems a bit unfair. I have heard pleas at various times from various Cincom employees to at least consider Store, or something close to it, for other Smalltalks. Moreover, I know that there is no one single person sitting there saying "no". The database dictionaries are as documented as anything in Squeak (i.e. via the code itself). As for packages, namespaces, I dunno.
Unless StORE gets open sourced or there is a similar agreement that puts both 'players' (Cincom, the Squeak community) on a level field, I think it's a tempting, but bad, idea.
You may be right.
Travis Griggs tgriggs@keyww.com wrote:
First of all, let me apologize for the tone of yesterday's message. Avi and Goran (and others) have been working hard to make the simplest thing that could possibly work, work. And my message would probably seem to say "screw the work you're doing". And that was not my intent, and I apologize for sending such a negative vibe.
No problemo. We all know CVS sucks in many ways and is very nice in some others. There is nothing in DVS that ties it with CVS. And sqcvs is not necessarily meant for storing Smalltalk code in CVS. And CVSTProj is probably also not completely tied with CVS.
But I agree - we need nice teamwork tools. But we need them integrated in Squeak and in under typically under SqueakL.
So as I understand it that puts StORE out of the race - but could someone in short words describe what is so cool about it? I have never used it.
regards, Göran
goran.hultgren@bluefish.se said:
So as I understand it that puts StORE out of the race - but could someone in short words describe what is so cool about it? I have never used it.
Well, it 'sucks' in only one respect compared to ENVY - never used that, but I heard that ENVY writes every modification to the repository rather than to the changelog, which is quite great when you make mistakes. Apart from that, StORE offers mostly anything you want: - flexible version numbers (I checkin a version as 'foo', StORE suggests 'foo.1' on the following commit). No such things as machine-generated version numbers combined with human-readable tags. Granted, a matter of taste; - code can be connected to, compared/diffed with etc, multiple repositories; - repositories are trivial to setup: all you need is an empty supported database and StORE does the rest; - graphical version browser, so you can navigate the tree, so what was merged into which versions, etcetera; - integrated with (for VW7) the RB: you can see what package versions you are working with, whether they have been changed w.r.t. the repository, move classes/protocols/methods between StORE packages, see in which packages the code was defined and where you are overriding it, load new versions from StORE, ask for differences with random StORE versions, etcetera. The left pane of the RB, when StORE is loaded, contains StORE packages by default; - good merge tool - you get a list of all the deltas, it automatically applies whatever can be applied automatically, you can then filter out the unresolved deltas - the conflicts - and one by one choose which version you want to have in the merge. The only thing that sucks here is that the database or the queries aren't optimized for complex merges, so that a merge of a multi-version branch on a trunk that's been committed to as well (so both branches have multiple versions since they branched) is awfully slow; we've seen Postgres stamping on for as much as two hours when we were stupid enough to leave a branch unmerged too long (it's easier to go back, file out the differences between the end-version on the branch and the split point, manually fix the chunks and file them in on the trunk). - reasonable differences browser. Needs improvement, though. - optimistic locking model with automatic branching. - hierarchical package model (code is organized in packages, packages can be grouped in bundles, bundles can be grouped in bundles), you can operate on the top level when loading and committing and StORE takes care of the rest on the whole tree.
I think that's basically it.
Cees de Groot cg@cdegroot.com said:
I think that's basically it.
No it ain't, I forgot one feature that's really cool: GC. You can instruct StORE to dump all versions below a certain blessing level prior to a certain date. The idea is that this allows you to keep 'Released' stuff around forever, while cleaning up all 'Tested' stuff older than, say, a year and all 'Development' stuff older than, say, three months.
Hi all,
Since you folks are discussing the possibility of making some Squeak-StORE connection, I had some code lying around which basically does just that.
What it does: - Connect to a Postgres StORE db. - Save a ChangeSet as a Package. - Load in a Package in a ChangeSet. - Publish newer versions of the Package.
What it doesn't: - No UI - No performance (I think it's the PostgreSQL connection) - No Bundles - Not very well tested
It currently tries to mimic a VW-StORE package, including VW class definitons and a guess at Namespaces.
Warning: This is more a proof of concept than a working thing.
Wouter Gazendam CosmoCows http://www.cosmocows.com
On woensdag, okt 30, 2002, at 12:21 Europe/Amsterdam, Cees de Groot wrote:
Cees de Groot cg@cdegroot.com said:
I think that's basically it.
No it ain't, I forgot one feature that's really cool: GC. You can instruct StORE to dump all versions below a certain blessing level prior to a certain date. The idea is that this allows you to keep 'Released' stuff around forever, while cleaning up all 'Tested' stuff older than, say, a year and all 'Development' stuff older than, say, three months.
-- Cees de Groot http://www.cdegroot.com cg@cdegroot.com GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Cogito ergo evigilo
Well, it 'sucks' in only one respect compared to ENVY - never used that, but I heard that ENVY writes every modification to the repository rather than to the changelog, which is quite great when you make mistakes. Apart from that, StORE offers mostly anything you want:
I think this is a matter of preference. I prefer to have control over what get's into repository and what doesn't. With ENVY if you add and remove halt in the method 10 times you've got 20 garbage versions of the method in the repository forever. I'm much happier for those to go into the change log and get lost when I rebuild the image next time. I use StORE in combination with the Change Log based method-history goodie, which gives me access to all the versions that I am ever interested to see. So I don't see this as a disadvantage, more the opposite.
- code can be connected to, compared/diffed with etc, multiple repositories;
This is a very nice feature, which you don't get with ENVY. My development images are reconciled against 3 repositories (my local Postgres at home (fastest), the public Postgres repo (to keep interested people in the loop), and the team repository (Oracle) in California). Works great.
- repositories are trivial to setup: all you need is an empty supported database and StORE does the rest;
Even though a good ODBMS is possibly a better choice for a backend, I think this is a very smart choice in commercial setting. Nobody's going to object against storing your precious source code in Oracle. And in this particular case RDBs fare well enough. One thing I miss is having StORE sit on a good O-R mapping layer (like GLORP), to make adding your own queries easier.
- optimistic locking model with automatic branching.
I would add that (unlike ENVY) the StORE VC model is very close to the popular update/commit model of today's file based VCs (there's no update as such, there's load and merge instead which gives you a bit more control over the update process, and commit is called publish). Should be much easier for new people to pick up.
It can store both the source code (just the differences), or binary (whole packages).
And finally it is the same kind of app so many developers are all too familiar with, objects stored in an RDB. Makes it quite easy for many to get inside and customize the tool.
-- Martin Kobetic, Cincom Smalltalk Development, http://www.cincom.com/smalltalk
On Wed, 30 Oct 2002 11:49:01 -0500, "Martin Kobetic" kobetic@rogers.com wrote:
I think this is a matter of preference. I prefer to have control over what get's into repository and what doesn't. With ENVY if you add and remove halt in the method 10 times you've got 20 garbage versions of the method in the repository forever. I'm much happier for those to go into the change log and get lost when I rebuild the image next time. I use StORE in combination with the Change Log based method-history goodie, which gives me access to all the versions that I am ever interested to see. So I don't see this as a disadvantage, more the opposite.
Not only that, but it also gives you the ability to work disconnected from the repository, which is a crucial feature in my opinion...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Seeker (Micro Autonomous Underwater Vehicle) http://www.huv.com
Cees de Groot wrote:
With all respect to the guys behind DVS and CVST: I think it's a dead end.
<...munch...>
compared to "the real thing" like StORE it has some very serious shortcomings which makes it unsuitable as the basis for a nice, friendly versioning system for a Smalltalk environment. The most serious thing missing is lack of metadata versioning, working around is probably just as hard as building something new on top of a decent versioning system.
I feel somewhat the same as Cees.
Over the years I've used various "fileout-checkin/checkout-filein" SC systems for Smalltalk code, and they all suck compared to "the real thing". I haven't been anxious to try yet another one for Squeak.
If I remember correctly, somebody at Smalltalk Solutions 2001 demo'd a Squeak image hooked to a VisualAge image, using the VisualAge/Envy engine for the Squeak code.
Or was I imagining that?
Nevin
Cees de Groot wrote:
With all respect to the guys behind DVS and CVST: I think it's a dead end.
<...munch...>
compared to "the real thing" like StORE it has some very serious shortcomings which makes it unsuitable as the basis for a nice, friendly versioning system for a Smalltalk environment. The most serious thing missing is lack of metadata versioning, working around is probably just as hard as building something new on top of a decent versioning system.
I feel somewhat the same as Cees.
Over the years I've used various "fileout-checkin/checkout-filein" SC systems for Smalltalk code, and they all suck compared to "the real thing". I haven't been anxious to try yet another one for Squeak.
If I remember correctly, somebody at Smalltalk Solutions 2001 demo'd a Squeak image hooked to a VisualAge image, using the VisualAge/Envy engine for the Squeak code.
Or was I imagining that?
Nevin
P.S. I got an error when I sent this the first time, so I sent it again. It might show up twice-- sorry if it does.
Hi all!
Just two notes and a dream:
Note 1: I did the sqcvs implementation as a "for fun" project. It was never meant to become "The Way" of dealing with Squeak sources. In fact - it can be used for anything that you want to store in CVS. So from this viewpoint I think sqcvs is interesting in it's own right. And also note that you do not need to have files on the client - it works with any model that implements a simple protocol! For example, I have a nested Dictionary with String->String pairs or other Dictionaries in it, thus mimicking a filesystem (filename->file content and subdirectories). Pretty cool.
Note 2: I really like the "work model" of CVS compared to Envy and similar pessimistic systems. I am no Envy expert but I have used it in VW a long time ago and also in VAJ. My experience is that sure, the power of it is tempting but it still gets in my way! I tend to spend quite a lot of time messing around with versions, releasing versions, ownership, yadda, yadda... With CVS I just update and commit regularly. In short I do ctrl-u (WinCVS) and ctrl-m and type in a commit message. When it all comes down to practical work the automerge combined the optimistic model really rocks IMHO. I would also say that the CVS workmodel fits much better with XP than the control-freak-model of Envy. IMHO. On a big 5000 class/11 developer project I worked on we really loved the way CVS set us free when we introduced it. All that manual merging work just disappeared.
Dream:
So... personally I would like to create a Squeak/Smalltalk specific repository solution using DVS (for declaring packages and perhaps more) combined with a nice Comanche based server perhaps that can do tags, branches and Smalltalk-smart-automerge (not the silly "Are these lines too close?") and a few other things that really is useful. And make the backend storage pluggable and let the first implementation use Magma.
Then add a nice smart diff/conflict resolution browser tool and some "collaboration bells and whistles" (like knowing more about where people are hacking/looking etc) and nirvana is pretty close to me. Perhaps we could do a bit of "brainstorming" around this at OOPSLA Avi? So many things to do over there... :-)
regards, Göran
goran.hultgren@bluefish.se said:
Note 2: I really like the "work model" of CVS compared to Envy and similar pessimistic systems.
In fact, I always put this on the prerequisite list when selecting versioning systems :-)
So... personally I would like to create a Squeak/Smalltalk specific repository solution using DVS (for declaring packages and perhaps more) combined with a nice Comanche based server perhaps that can do tags, branches and Smalltalk-smart-automerge (not the silly "Are these lines too close?") and a few other things that really is useful. And make the backend storage pluggable and let the first implementation use Magma.
Add multi-repository to the list. That's one of the things I like best about StORE - I work off-line and commit regularly to my local StORE repository, and only when a chunk of work is finished I need to go to the slow, remote repository I run on one of our servers directly on the Net. Similarly, I maintain multiple versions of software connected to two remote repositories: the Cincom public StORE gets my, say, SSL package patches and there I continuously track work, while the internal repository gets less regular commits with stable versions only.
Hi Nevin!
Quoting Nevin Pratt nevin@smalltalkpro.com:
IBM VisualAge has Envy (and so does VW from 5i.1 and earlier). VW has Store.
What's the best approach for similar functionality for Squeak?
Well, currently I would say DVS - without actually having tried it myself! :-)
Avi is doing a good job moving it forward, it has a nifty architecture, people are using it actively, it is being integrated a bit into SqueakMap, it can use CVS as a backend but AFAIK is not limited to. But it makes good sense. (Even though a nice conflict resolution tool inside Squeak would be a nice addition).
And if I can get my butt in gear and finish sqcvs, DVC could even communicate directly with the CVS server instead of going the route through the filesystem and external CVS executable.
regards, Göran
PS. Joseph Pelrine's Ginzu was an Envy clone (kind of I think) that at least ran in Squeak but I am uncertain of its current status. I think Joseph is active in the Smallscript community now. DS
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
Göran - Why do you always end your postscripts with 'DS'?
david
At 08:37 PM 10/28/2002 +0100, you wrote:
PS. Joseph Pelrine's Ginzu was an Envy clone (kind of I think) that at least ran in Squeak but I am uncertain of its current status. I think Joseph is active in the Smallscript community now. DS
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
-- David Farber dfarber@numenor.com
Hi all!
Quoting David Farber dfarber@numenor.com:
Göran - Why do you always end your postscripts with 'DS'?
david
A good question David! I have no idea! :-)
When you asked I tried to find on the net why that is customary (at least in Swedish) but I didn't find anything. Isn't that "customary" in English? Hmmm. I will try to find out.
regards, Göran
Göran Hultgren, goran.hultgren@bluefish.se GSM: +46 70 3933950, http://www.bluefish.se "Department of Redundancy department." -- ThinkGeek
On Mon, Oct 28, 2002 at 10:51:46PM +0100, Göran Hultgren wrote:
Quoting David Farber dfarber@numenor.com:
Göran - Why do you always end your postscripts with 'DS'?
david
A good question David! I have no idea! :-)
When you asked I tried to find on the net why that is customary (at least in Swedish) but I didn't find anything. Isn't that "customary" in English? Hmmm. I will try to find out.
I have been taught that it's for "den samme" ("the same [person]"), meaning the postscript is written by the same person as the rest of the letter, which suggests it's a Swedish thing, although it could originally be from Latin or French or German for all I know.
Hi all!
Patrik Nordebo patrik@nordebo.com wrote:
On Mon, Oct 28, 2002 at 10:51:46PM +0100, Göran Hultgren wrote:
Quoting David Farber dfarber@numenor.com:
Göran - Why do you always end your postscripts with 'DS'?
david
A good question David! I have no idea! :-)
When you asked I tried to find on the net why that is customary (at least in Swedish) but I didn't find anything. Isn't that "customary" in English? Hmmm. I will try to find out.
I have been taught that it's for "den samme" ("the same [person]"), meaning the postscript is written by the same person as the rest of the letter, which suggests it's a Swedish thing, although it could originally be from Latin or French or German for all I know.
Ah, yes, sounds familiar. But I wonder what PSS/DSS mean then (when you add an extra PS after the first)?! :-)
regards, Göran
That's funny, because seeing it at the end of Göran's postscripts always made me think that someone else had written the postscript--someone whose initials were 'DS'.
david
At 11:31 AM 10/29/2002 +0100, you wrote:
On Mon, Oct 28, 2002 at 10:51:46PM +0100, Göran Hultgren wrote:
Quoting David Farber dfarber@numenor.com:
Göran - Why do you always end your postscripts with 'DS'?
david
A good question David! I have no idea! :-)
When you asked I tried to find on the net why that is customary (at least in Swedish) but I didn't find anything. Isn't that "customary" in English? Hmmm. I will try to find out.
I have been taught that it's for "den samme" ("the same [person]"), meaning the postscript is written by the same person as the rest of the letter, which suggests it's a Swedish thing, although it could originally be from Latin or French or German for all I know.
-- David Farber dfarber@numenor.com
Hi everybody!
David Farber dfarber@numenor.com wrote:
That's funny, because seeing it at the end of Göran's postscripts always made me think that someone else had written the postscript--someone whose initials were 'DS'.
Yes, that's ironical. Not until Patrik explained that it means "den samme" did I vaguely remember this. It has sort of always been a habit to put it in there. The point of it is that since a PS appears below the signing this, as Patrik already explained, clarifies that the PS was written by the same person.
Another thing - what kind of mailinglist greetings do you use? Dan uses the "Hi folks!" greeting which is neutral in gender etc. I often like to write "Hi guys!" but somehow (even if it isn't gender specific in speech nowadays - I have been told) in writing it does seem to imply males to me. Or does it? Would it be "kosher" to use that?
As a homebrewed variant I have been using "Hi all!" but it limps a bit (might be a Swedish saying). :-)
Anyway, I did some searches on Google groups regarding the PS/DS thing, this is a bit interesting. For obvious reasons it seems only Swedes use the DS thing. :-) But hey, I am trying to start a trend here! But when adding a PSS (or a PPS - both variants occur) we also seem to end that with a corresponding DSS or DDS - and I have no idea what that should mean - perhaps it just "looks cool".
After checking around it also seems that most people think it should be "PPS" as in "post post scriptum". But somewhere I saw that it could mean "post scriptum secundum". He.
regards, Göran
On Wed, Oct 30, 2002 at 08:22:10AM +0100, goran.hultgren@bluefish.se wrote:
But when adding a PSS (or a PPS - both variants occur) we also seem to end that with a corresponding DSS or DDS - and I have no idea what that should mean - perhaps it just "looks cool".
It's probably used because of the similarity between "PS" and "DS", I don't think it actually means anything.
After checking around it also seems that most people think it should be "PPS" as in "post post scriptum". But somewhere I saw that it could mean "post scriptum secundum". He.
Well, in that case you'd have to use "PST" ("post scriptum tertius") for the third postscript, which breaks the symmetry and is more easily confused for something else ("psst", for instance). And you'd have to know latin to continue the series.
As my contributions are awfully off-topic, I'll just go back to lurking in a corner now.
squeak-dev@lists.squeakfoundation.org
-
Avi Bryant -
cg＠cdegroot.com -
Colin Putney -
David Farber -
goran.hultgren＠bluefish.se -
Göran Hultgren
-
Jon Hylands -
Martin Kobetic -
Ned Konz -
Nevin Pratt -
Patrik Nordebo -
Travis Griggs -
Wouter Gazendam