Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Code Sharing with Squeak
The Dream Team - Code Sharing with Squeak
- Matt Manzel gtg722b
- Harrison Caudill gte042u
- Hai Nguyen gtg623h
- Scott McRae gtg014g
Our group had problems with code sharing from the beginning of the project, and continued to have problems throughout the semester. This Cases Page will talk about what we found would work best, how this can go wrong, and what to do to prevent and fix them.
If you haven't actually used Squeak yet, let me take a minute to tell you about one of the ways (there are many) it is a terrible environment that you would never want to use unless you had to (like now). Squeak doesn't actually store your code in any kind of structured, readable format. It stores the code internally in the memory of the virtual machine, which is then stored in the image file. You can export into .st files or .cs files, but these are not anywhere near human readable, nor do they work with CVS, due to the CRLF line break.
This is where DVS comes in. DVS is a component you can file into your squeak image that lets you file out in a more readable format. (At least readable to CVS.) After you file out with DVS, you can use CVS r a similar tool to synchronize with teammates.
To install DVS, go to this page. Save the links to PackageInfo and DVS to your squeak directory. Open a file browser and file in PackageInfo. When it asks you a question, click "no". Now file in DVS. The Package Panel shouold appear. To bring it up normally, run "PackagePanel open" form a workspace.
After you have DVS loaded and the Package Panel open, Click add and type the name of the Package you for your project. It is better to you multiple files, so you will have less merging problems. If you are using a different directory for CVS (which is a good idea), click Edit and change the directory for the package to be filed in/out to. Now you can file in/out to a CVS readable format.
Using CVS with DVS and Squeak is fairly straight foreward, however there are a few subtle but very important points. After you have the repository setup and the code added and committed, you should always use the following procedure:
CVS update and DVS file in (before you make any changes)
DVS file out, CVS update, resolve conflicts, CVS commit (IN THAT ORDER)
It is vitally important that you DO NOT cvs update before you file out your changes. Make sure your entire team understands this before you start using CVS.
Our team talked about using subversion instead of CVS in the beginning. We did not end up doing much testing with it, but it may be possible to store the squeak image its self in a subversion repository, since it can do binary differenceing. You may want to look in to Subversion as an alternative, if you have the time.
When code sharing goes wrong...
Here is a quote directly from our CVS logs:
This is dedicated to the assmonkey who overwrote all of my chages:
HOW TO USE CVS WITH DVS(tm):
1. Update cvs.
2. In squeak, open the DVS window (open... -> DVS Package Panel)
3. For any files that you were working on, click the 'changes' button
4. Merge the updated files with your existing code
5. NOW you can file out your file with DVS (after you've merged the changes!)
6. Create a separate file out for your classes because you can't trust anyone to do it right. ;)
7. be a smartass about it.
Note: You should use the steps in the CVS section, not these.
Once we got to the part of the project where it was impossible to work in separate files, we realized there was something terribly wrong with the way we were using CVS. We realized this when we found that we were all overwriting eachothers changes. We probably spent about 30% to 40% of our time just dealing with and recovering from code sharing problems.
Why does this happen?
We are still not entirely sure what was happening, it was probably caused by doing a cvs update before a file out. The important thing you have to keep in mind is what revision number you started editing, and the current revision in the CVS respository. Here is what happens:
You do a CVS update and file in revision 1.24 (for example)
You start making changes to the code
Your teammate finishes a small changes and commits revision 1.25
Another teammate make a change in a different file and you do a CVS update and file in that file
(CVS brought you up to date with revision 1.25 at the same time)
You finish with you changes, file out, and commit
The problem here is CVS thinks you are up to date, since you have revision 1.25, so it thinks you purposefully removed the changes that you teammate made, and updates the repository to reflect that.
How to avoid code clobbering
To avoid the problem in the scenario describe above, just follow this rule: Never update without filling out first.
Another trick is to try to use separate packages for the components each person is responsible for. This way you can simply avoid having to modify the same file at the same time altogeather.
Lastly, for the packages you can't give one person ownership of, you can use a physical object as a mutex, os only the person who has the object can make changes to the file. While this seems somewhat silly and defeats one of the main goals of CVS, it does solve the code sharing problems.
Link to this Page
- Living the Dream last edited on 25 July 2004 at 10:46 pm by lawn-199-77-206-96.lawn.gatech.edu