Requirements

• To be able to support multiple development process styles.
• To utilize multiple database backends including a simple out of the box db.
• To make it uncomplicated for a solitary developer.
• To provide sophistication necessary to support teams with multiple projects.
• To permit development in an "unconnected" manner, as Store currently does.
• To be able use remote repository without incurring large time penalties.
• Ability to extend the repository schema.
• Ability to merge code components from different repositories.
• Version roll back.

• Need to support multiple branches.
• Merge branches.
• Apply a common change to multiple branches.
• Historical tracking of changes to a component, including changes across renames and movement to different containers.
• a container may be a namespace or a "package".
• this probably means that UUIDs will be needed.
• UUID for a method can be a secure hash based on intial source code.
• Need UUID aliasing mechanism to sync methods from different places.
• Flexible rules for version identification and version level generation.
• Create a UUID for each version.
• Retain version history comprised of the UUID, version name, timestamp, repository id(?).
• transactional support
• Ability to operate as client/server, although need also to be able to use single image.
• Server is needed to reduce communication between repository db and a remote user.
• Provides transactional support.
• Can notify users of significant events, such as another user dirtied the same package or method.
• Client/server communications
• Use a repository language,(NOT SQL).
• Extensible, maybe namespaces so user extenstions are isolated.
• Modify changes file to accomodate version information.
• A file format to replace parcels, but it is a mini repository database like envy export files, but must keep performance in mind.
• Support binary loading * packages with no source, or packages that require a different compiler.
• supply classification key words for various code components.
• be able to have additional class properties * see #extraAttributesForDefinition.
• code component properties... method pragmas
• Need broader class extensions;
• Additional methods
• Method overrides
• Add instance vars
• Override class def - this may mean removing ivars.
• Add shared vars
• Add to External class libraries, etc...
• Extend Namespaces
• Add imports
• Higher level code components are composed of versionable atoms.
• High level code component would be things like;
• packages
• change sets
• bundles
• config maps
• Versionable atoms
• Methods
• Class definitions
• Namespace definitions
• Extensions
• Change sets need additional support to manage/view them. Lots of disjoint change sets would be hard to manage.
• Need to support unmanaged changes to code, i.e. an application that generates runtime classes should not be managed by the source code management system.

• Need a way to develop and test the SCM without interfering with Store.
• Create a sandbox of the class hierarchy which we will plug our code into

• notification needed to track changes to code base
• to keep tools syncronized
• allow some changes to be untracked