I finally realized that the best answer to the RMI-newjvm-thing problem I
created was to simply back out of the changes I've made, for now, and then
to re-apply them (with the problems fixed) when I can. So I've done that,
and I am in the process of running "ant commit" now to commit them.
Commit process is done. Now committed is drjava-20020503-0535, which is
exactly like what was committed before except that my RMI changes were
undone. So any other changes you guys made are still there. CVS is cool
like this.
For the gory details (if you're curious), read below. But once again, CVS
is cool.
Now, this means that (once you ensure this version really works, like by
testing it on Windows and Mac, which I don't have time to do right now)
you can feel free to release a new version publicly (provided everything
else is stable and happy). Cool? Make sure to get info from everyone if
needed on release notes.
FYI, I'll be away but checking email Friday-Thursday, then in town
Thursday the 11th through Wednesday the 17th. I will, however, have the
iBook with me this next week and hope to work on the damned problem we
were having!
-brian
---------- Forwarded message ----------
Date: Fri, 3 May 2002 00:20:09 -0500 (CDT)
From: Brian Stoler <bs...@bs...>
To: co...@ri..., ea...@ri..., cr...@ri...
Cc: bs...@ri...
Subject: CVS trickery
BTW, thought you might be interested in the trickery I'm using to roll
back the changes I made to the RMI thing. I'm using CVS's ability to
apply the difference between two arbitrary revisions of a file to the
current file to selectively undo just my changes. (The relevant docs are
at http://www.cvshome.org/docs/manual/cvs_5.html#SEC62)
So, both so I can remember what I've done and to tell you what I've done,
here's the steps I've taken.
1) Undo changes to drjava.model.repl.newjvm.
First, I used the CVS log info (from the CVS web interface) to find out
the version of DrJava where I first changed over to the RMI thing. Then I
found the current version number (the version I want to be the other
endpoint of the delta). Using these, I did this (inside newjvm):
cvs update -j drjava-20020502-2032 -j drjava-20020413-2208 *.java
This undid all changes made between those two revisions to those files. (I
had to fix one small thing besides this to make it still compile, to
reflect that I repackaged util during that time as well.
2) Undo DefaultGlobalModel changes.
Then I had to undo the changes to DGM, which is the client of the newjvm
stuff. I checked out the log for DGM.java and found the numerical
revisions of the file before and after I made my changes and used them to
make CVS un-apply only those changes by doing this:
cvs update -j 1.26 -j 1.24 DefaultGlobalModel.java
Note that many other revisions occurred after my changes (the current rev
is 1.35), but CVS only un-applies the changes made between 1.26 and 1.24.
Pretty cool. Note as well that because there were later changes, I
encountered a few conflicts when doing this update (just like normal
conflicts when two people edit the same file). They were due to debug
stuff. Anyway, they were easy to resolve.
3) Remove GlobalModelQuitTest.
This test is specific to the new framework and so is not needed (or
wanted) in the version I am going to commit now. So:
cvs remove -f GlobalModelQuitTest.java
4) ant clean test, and make everything pass.
Now I've got a happy version reverted to the old newjvm code. BTW, the
new code in util.newjvm is still there, but unused at present.
After this commit, I will fix my working copy (but not the committed
version!) to un-undo these changes so I can go back to fixing this. This
will be precisely doing steps 1-3 in reverse:
cvs update -j drjava-20020413-2208 -j drjava-20020502-2032 model/repl/newjvm/*.java
cvs update -j 1.24 -j 1.26 model/DefaultGlobalModel.java
cvs update -j 1.3 -j 1.2 model/GlobalModelQuitTest.java
BTW, the third one un-does the removal of QuitTest! Pretty cool!
Then, I will have a personal copy that is once again ready to resolve the
problems, but the committed version will be back to how it was before.
Sorry I didn't realize to do this earlier, and sorry I screwed the
codebase up in the first place! I shouldn't have made such a risky change
like that.
-brian
----------------------------------------------------------------
Brian Stoler cell: (713) 725-3374
|
