We are considering changing from only packages as units to every class is a unit.
I thought I'd better find out what the repercussions might be.
Our reasoning is two-fold :-

1) Several people want to work simultaneously on different classes within the same package.
2) When a package is modified, we check-in and associate to an SPR (ie: defect/bug/issue ID). We also generate the code and need to associate the same SPR with any source files that are modified. Currently this would involve a diff process to see which generated files have been changed. The walkthrough procedure would involve looking at the changes to the package and the changes to the affected source files.

If every class is a unit, then the diff process wouldn't be required.

What do you think? What are the pitfalls of making every class a unit? (We are just migrating to subversion).

If your process has to deal with high-octan delivery cycles then you may have no choice. If you don't work in a pressured environment then I would recommend you organise your model and assign the work to avoid the need to merge.

If you are moving to SVN then experiment a lot. The default settings in SVN do not suit Rhapsody development and you will probably end up in a mess due to files not being (RO). We had pain initially but now we understand how to make it work well.

I have heard of a lot of people now moving to SVN. It's a great tool but you need to learn how it works.

I have previously posted on similar threads. The reply from Eric Keller on this post is interesting...
https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14464642&#14464642

He also posted here ...
https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14285038&#14285038

I'm hoping that with every class a unit, and subversion configured to use "needs lock", then we shouldn't need to do much merging with diffMerge.

I do worry that a package could be checked out, but not the contained classes (.cls). A change to a property in the writable package might try to change read-only class files.

I agree we need to experiment!

Our use of SVN and Rhapsody uses needs-lock and we stick to package level saved units. We did start using a looser approach similar to what Eric suggests but found it unworkable. Our config file contains:

### Rhapsody files
*.sbs = svn:needs-lock
*.rpy = svn:needs-lock
*.cmp = svn:needs-lock