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" <365nice@xxxxxxxxx> wrote in message news:1154085830.499022.193440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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


.

Relevant Pages

  • Re: STS loading previous edition doesnt remove new classes
    ... that package). ... This wasn't what I was expecting - I expected that loading a previous ... No remote server without a huge repository dump occuring renders it ... Developer one can add 20 methods to class A, and developer two, ...
    (comp.lang.smalltalk.dolphin)
  • Re: Global variables
    ... I have a litte OT question: how do you initialize the Repository? ... first class triggered the Starter class. ... principle of object orientation is to design towards an interface, ... Starter class must not reside in the interface respository package. ...
    (comp.object)
  • Re: Fostering Cooperation (was Yum and EXTRAS)
    ... The page does not claim that cooperation would be ... The page is short and to the point in explaining why repository mixing ... that users of independent package providers should encourage them to join ... Fedora Core, it would be beneficial, if Fedora packages and their ...
    (Fedora)
  • Re: Fedora needs more evangelism for repositories
    ... Package upgrades, interaction with packager about packaging bugs (not ... Pin-Priority: 600 ... If package abc is in "Fedora Extras" and any other repository, ...
    (Fedora)
  • Re: An introduction of the new cheerleader...
    ... >> repository contains a new package, ... But when a package of the same software is in a public ... For inter-repository compatibility, it needs global policies which all ... > to Fedora QA to become a Fedora Extras package. ...
    (Fedora)