class Activity(object):
	"""The model of an Activity currently being hacked on.
	
	Version tracking is abstracted by this class as well. Debug control logic
	will interact with this.
    
    Generally, this class represents the top-level python package in a given
    project.  The project may in fact not be a full-blown Sugar activity.
    
    If Develop does not detect the presence of the activity/activity.info file,
    the GUI will not present the user with certain Activity-specific features.
    Likewise, if the bazaar repository has not been initialised, version
    control features will not be presented either.
	
    It is important to note that develop-activity makes a significant departure
    from traditional IDE design;  it does not persist any sort of "Project"
    meta-data between sessions beyond what is stored in the .info file mandated
    for Activity Bundles, and the .bzr directory of the Bazaar version
    control system.  Develop will never touch .bzr directly -- it invokes
    bzrlib for all source control operations.
    
    This is done because any sort of Project system would effectively duplicate
    the information stored in both the activity.info and version control
    facilities.  This would mean that the person using this tool would have
    "one more thing to worry about".  Obviously, this violates the DRY
    principle.
    
    As such, I feel reluctant to describe the Develop activity as an "IDE";  it
    would be better described as an "Activity Maker" or similar.
    
    New Activities can be created in two ways: as "forks" of existing
    activities either from the system image or downloaded from other users
    on the mesh (usually done from the View Source key); and newly created
    activities.
    
    Activity implements the Factory pattern for Directory objects.
    
    For both technical and usability reasons, there will be no concept of an
    "untitled" buffer.
	"""