STS loading previous edition doesn't remove new classes
Locked
 
|
I just noticed that loading a previous edition of a package using STS
has left classes that were in the newer edition still in the image (in that package). This wasn't what I was expecting - I expected that loading a previous edition (by browsing editions of a package and right clicking on an older one and picking load) would load all the original classes and remove anything that was added in the later edition. Is this an oversight or is it expected behavior? The downside of course is that if yo make new changes from that previous edition, and then version it, it will contain the classes from the later version as well. Tim |
|
|
"TimM" <[hidden email]> wrote in message
news:[hidden email]... >I just noticed that loading a previous edition of a package using STS > has left classes that were in the newer edition still in the image (in > that package). > > This wasn't what I was expecting - I expected that loading a previous > edition (by browsing editions of a package and right clicking on an > older one and picking load) would load all the original classes and > remove anything that was added in the later edition. > > Is this an oversight or is it expected behavior? > > The downside of course is that if yo make new changes from that > previous edition, and then version it, it will contain the classes from > the later version as well. > > Tim > I noticed this way back when, when trying to determine if it was worth using. For me this felt like a bug which made me question just how much use it was getting. I would love to be using the integrated source control system but it looks a long way off for me for the following (excuse the tangent) 1) I gave it a very tiny hypothetical workout with some scenarios and saw like you that new classes aren't unloaded when reverting, also a change of an objects superclass isn't flagged as a difference between editions. These things did worry me. 2) Stability - Nobody can really know for sure whether its as secure as Visual SourceSafe or actually pretty good ;-) My only real point being that version control is a dangerous business and going with something more tried/tested is always going to be more welcome. 3) No remote server without a huge repository dump occuring renders it pretty much unusable for me. This is presumably for complete method level versioning which is nice but not absolutely required - is there anything else?. It'd be nice if it could run in a mode that just used everything from the client besides checkin/commit. 4) Two way merge - This is a big killer for me; please correct me if I'm wrong but both this and the system we have in VSE only use a two way merge and completely manual at that, doing a choose left - right which seems very primitive. Developer one can add 20 methods to class A, and developer two, 20 methods to class B and it requires manual merging? If a method has changed at all you have to look at the dates and pick the latest one and theres so much scope for error. 99% of merging in a well organised and communicative team should be automatic with a basic three way merge, with only changed methods by both requiring human intervention. As much as I hate to get away from the object/image approach and would love to use the STS repository, I feel I'm going to end up using TortoiseSVN with KDiff . I can have it set up on an apache server and it is very stable (plus loving the explorer integration!) However it feels like it breaks a lot of the Smalltalk approach to working, and after a merge or update you're going to have to do those slightly annoying uninstall and install cycles, or revert to base image and bring in which don't feel right. I'm not too sure yet whether to use .PAC or .PAX as the former are always produced and could potentially hang around uncommited. I can't see any reason why a 3 way merge tool would have any issues at all with the .PAC files and it'd probably feel quicker to work with than on a class basis, but experience says that small chunks and .PAX might be better in the long run. Any advice from anyone using either method of repository, their approaches and positive / negative experiences would be appreciated! Regards, Chris |
Re: STS loading previous edition doesn't remove new classes
|
|
Tim, Chris,
this is now fixed. I thought of it first as a feature since I always start from a clean image. Now, classes which don't belong to a package will be made uncommitted (so they remain in the image bug are excluded from the package). The bug with not detecting superclass change was already fixed before. Regarding stability, maybe you should ask people in this newsgroup if they ever encountered repository corruption. Regarding distributed repository, this will be added in the future. It is not much work, just lack of time and competent developer resources. The new version will be distributed together with live update from OA but I am not able to say anything about when this will happen. Best regards, David Gorisek ChrisB wrote: > "TimM" <[hidden email]> wrote in message > news:[hidden email]... >> I just noticed that loading a previous edition of a package using STS >> has left classes that were in the newer edition still in the image (in >> that package). >> >> This wasn't what I was expecting - I expected that loading a previous >> edition (by browsing editions of a package and right clicking on an >> older one and picking load) would load all the original classes and >> remove anything that was added in the later edition. >> >> Is this an oversight or is it expected behavior? >> >> The downside of course is that if yo make new changes from that >> previous edition, and then version it, it will contain the classes from >> the later version as well. >> >> Tim >> > > I noticed this way back when, when trying to determine if it was worth > using. For me this felt like a bug which made me question just how much use > it was getting. I would love to be using the integrated source control > system but it looks a long way off for me for the following (excuse the > tangent) > > 1) I gave it a very tiny hypothetical workout with some scenarios and saw > like you that new classes aren't unloaded when reverting, also a change of > an objects superclass isn't flagged as a difference between editions. These > things did worry me. > 2) Stability - Nobody can really know for sure whether its as secure as > Visual SourceSafe or actually pretty good ;-) My only real point being that > version control is a dangerous business and going with something more > tried/tested is always going to be more welcome. > 3) No remote server without a huge repository dump occuring renders it > pretty much unusable for me. This is presumably for complete method level > versioning which is nice but not absolutely required - is there anything > else?. It'd be nice if it could run in a mode that just used everything from > the client besides checkin/commit. > 4) Two way merge - This is a big killer for me; please correct me if I'm > wrong but both this and the system we have in VSE only use a two way merge > and completely manual at that, doing a choose left - right which seems very > primitive. Developer one can add 20 methods to class A, and developer two, > 20 methods to class B and it requires manual merging? If a method has > changed at all you have to look at the dates and pick the latest one and > theres so much scope for error. 99% of merging in a well organised and > communicative team should be automatic with a basic three way merge, with > only changed methods by both requiring human intervention. > > As much as I hate to get away from the object/image approach and would love > to use the STS repository, I feel I'm going to end up using TortoiseSVN with > KDiff . I can have it set up on an apache server and it is very stable (plus > loving the explorer integration!) However it feels like it breaks a lot of > the Smalltalk approach to working, and after a merge or update you're going > to have to do those slightly annoying uninstall and install cycles, or > revert to base image and bring in which don't feel right. > > I'm not too sure yet whether to use .PAC or .PAX as the former are always > produced and could potentially hang around uncommited. I can't see any > reason why a 3 way merge tool would have any issues at all with the .PAC > files and it'd probably feel quicker to work with than on a class basis, but > experience says that small chunks and .PAX might be better in the long run. > > Any advice from anyone using either method of repository, their approaches > and positive / negative experiences would be appreciated! > > Regards, > Chris > > |
|
|
Hi David,
> Regarding distributed repository, this will be added in the future. It > is not much work, just lack of time and competent developer resources. Thanks so much for fixing this! Actually I wanted to chip in earlier and comment that your generosity in making Sts open source was a good thing, and certainly it has raised the bar in terms of what is possible in reinvigorating Smalltalk (certainly it compliements the work of Blair and Andy particularly well). So thank you for contributing it. Inevitably there are going to be use cases that you didn't think of, and of course as users we are going to report. I guess really what we need to address is how we are going to contribute back and help pay back to you so that its not such a burden. This is a tough one - not many projects in Smalltalk have been historically started for open contribution. Ironically one of the features we are in search of is an easy way to allow remote contributions with some build system to ensure that things don't break (particulary with complex apps like Sts). On that front, I've been playing with using Subversion - not to replace Sts, there is no way that subversion will give you the same dynamic feel of recovering method editions or backing out classes, but as an easy way to allow quick remote sharing and also adressing external resources like jpg's and web pages etc. So I am wondering for the remote sharing cases if its possible to leverage your technology such that if I remote sync to subversion and it does an automatic merge (possibly resolving a conflict) on a package file, can I somehow load in a package and replace the existing contents without the whole hassle of unloading the existing package etc. Do you have some pointers on approaching this - it seems like a potential quick win which might give some experinece in your code base and potentially setup some ways to remote work some longer term solutions. Tim |
|
|
In reply to this post by David Gorisek-5
"David Gorisek" <[hidden email]> wrote in message
news:[hidden email]... > Tim, Chris, > > this is now fixed. I thought of it first as a feature since I always start > from a clean image. Now, classes which don't belong to a package will be > made uncommitted (so they remain in the image bug are excluded from the > package). > > The bug with not detecting superclass change was already fixed before. > > Regarding stability, maybe you should ask people in this newsgroup if they > ever encountered repository corruption. > > Regarding distributed repository, this will be added in the future. It is > not much work, just lack of time and competent developer resources. > > The new version will be distributed together with live update from OA but > I am not able to say anything about when this will happen. > > Best regards, > > David Gorisek > > This is excellent news. There was only ever numerous little niggles that rendered it pretty much impossible for me to use and its great if we can eliminate these things to make Dolphin the complete package. Some of the others, notably proven stability was just forcing myself onto the file based route! But I would much much rather be working with STS for its integration, full method history and potentially better merging - Smalltalk knows where its methods are and could make 3 way merging an absolute snip whereas file based mergers are dumb and can have issues. I've discovered that running STS over a VPN seems to work fine, just not on an FTP server mapped as a drive so that is an option for remote developers. It seems the minor issues are in check and I've almost finished an automated merge. I had to change the changed class node in that a load of nil just did nothing whereas I've actually removed it from the package - I guess this is obviously very similar to what you have done on load edition and might want to go unpackaged for consistency; have you done this here? I could do class/package comments but may also realise that they aren't worth the effort. Cheers Chris |
Re: STS loading previous edition doesn't remove new classes
|
|
In reply to this post by Tim M
Tim M wrote:
... > > So I am wondering for the remote sharing cases if its possible to > leverage your technology such that if I remote sync to subversion and it > does an automatic merge (possibly resolving a conflict) on a package > file, can I somehow load in a package and replace the existing contents > without the whole hassle of unloading the existing package etc. > > Do you have some pointers on approaching this - it seems like a > potential quick win which might give some experinece in your code base > and potentially setup some ways to remote work some longer term solutions. > > Tim > > Tim, the following script should work to load a package from a file and then replace an already installed package with a different version: ---------- stsPackage := (StsManager current importPackageObjectFor: pathname) loadFrom: pathname. StsManager current basicVersionPackage: stsPackage versionDescriptor: versionString previousEdition: nil "or previous packagae edition instance" versionComment: 'some comment' checkExisting: false. (StsManager getPackageEditionsFor: stsPackage name) last load. --------- Best regards, David |
|
|
Thanks David, I'll see how I get on. I'm not sure how well a a subversion/sts
hybrid will work out (although my experiements look promising so far) - but its an interesting side project that will give me some more Sts experience. Tim > Tim M wrote: > ... >> So I am wondering for the remote sharing cases if its possible to >> leverage your technology such that if I remote sync to subversion and >> it does an automatic merge (possibly resolving a conflict) on a >> package file, can I somehow load in a package and replace the >> existing contents without the whole hassle of unloading the existing >> package etc. >> >> Do you have some pointers on approaching this - it seems like a >> potential quick win which might give some experinece in your code >> base and potentially setup some ways to remote work some longer term >> solutions. >> >> Tim >> > Tim, > > the following script should work to load a package from a file and > then replace an already installed package with a different version: > > ---------- > > stsPackage := (StsManager current importPackageObjectFor: pathname) > loadFrom: pathname. > StsManager current > basicVersionPackage: stsPackage > versionDescriptor: versionString > previousEdition: nil "or previous packagae edition instance" > versionComment: 'some comment' > checkExisting: false. > (StsManager getPackageEditionsFor: stsPackage name) last load. > > --------- > > Best regards, > > David > |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |