Project #2 Sample - Local Code Repository

Version 1.0,
Due Date: 12:00 am, Sunday, Wk4
Note:
This is a demonstration project, which you are not expected to implement.
Instead, you will implement the projects linked on the Synchronous pages.

Purpose:

In order to successfully implement big systems we need to partition code into relatively small parts that are easy to understand and easy to test. This is important because we need to thoroughly test each of the parts before inserting them into the project's software baseline1. In order to do that effectively we need to understand each of the packages, their modifications, and dependencies on other packages.
As new parts are added to the baseline and as we make changes to fix latent errors or performance problems in existing packages, we will be creating new versions of existing packages as well as creating new packages. When we make changes we will run test sequences for those parts, all the parts that depend on the changed parts and, occasionally, for the entire baseline.
Because there are so many packages, some with several versions, we need a Repository to store the baseline and some semi-automated processes for checking in packages, for versioning, and for making queries on the Repository contents. These sample projects all focus on the structure, design, and implementation of a Repository for storing code baselines.
One obvious question is why would we do this since there are many well-established code control systems, e.g., git, Subversion, etc?
In order to implement a system for continuously integrating new code into complex systems, our goals are to detect breakage as soon as feasible after submitting a change to the baseline. That means that we want to test, not only the changes, but also all packages that directly depend on the changes. The most commonly used code control systems do not make the needed dependency information available, and sometimes make it awkward to extract just the packages needed for an integration test. Our Repository will be designed to provide fine-grained, dependency-aware, package management, to support continuous integration testing.
In this and following projects we will be creating a Repository - a semi-automated storage mechanism that provides pluggable policies for:
  • File managment
  • Version control
  • Package ownership
  • Checkin and Checkout
  • Package browsing
The term "pluggable" means that we can substitute one version of a policy with another without requiring any changes to the Repository code. We will see that means that policies will need to be implemented as components - a software part that has an interface and object factory2.

Requirements:

Your Local Code Repository Project:
  1. Shall be written in C#, using the .Net Framework. You may also use helper code provided in Project2Helpers.
  2. Shall use Visual Studio, Community Edition available at no cost.
  3. Shall implement a Code Repository and associated test executive, which both will be part of the same Windows process.
  4. All input shall be supplied by the process command line.
  5. Shall implement pluggable2 policies for:
    • File Management:
      • Copy files from test directories into versioned directories created by the Versioning policy. Files are specified by a CheckIn policy, based on test executive commands.
      • Find stored files based on queries and display them or write them to specified directories, based on the content of the query. Queries are specified by a CheckOut policy, based on test executive commands.
    • Version Management:
      • Create directories for each new version of a package, as specified by a CheckIn policy.
      • Create an XML metadata file that specifies the package, path, and paths to all metadata files for dependent packages3. The metadata should also contain the name of the package and a brief description of the package operations.
    • CheckIn:
      • Accept from the test executive a list of packages to be checked in.
      • This input also includes dependency information between the incoming files and files already stored in the Repository.
      • Use an Ownership policy to determine if the CheckIn succeeds or fails.
      • The test executive specifies whether the CheckIn is "open" or "closed". If open, the files being stored can be changed at any time without changing the version number. Once a CheckIn is closed, the contents become immutable. The only way changes can be made is to create a new version. Old versions can be discarded only with administration priviledges.
      • Any CheckIn may link to any part of a previously closed CheckIn. No package stored in the Repository may link to any package in an open CheckIn.
    • CheckOut:
      • For any package specified by the test executive, retrieve the package and, by defalult, all its dependent packages. The test executive request may specify that only the named package be returned.
      • CheckOut succeeds or fails based on an Ownership policy.
    • Ownership:
      • Determine whether a CheckIn or CheckOut should succeed, based on credentials supplied with the request4.
    • Browsing:
      • Display the name of a specified package and the first five lines of the package text5.
      • Except commands to navigate to children of the specified package and repeat the display for each.
  6. Shall, using the text executive, demonstrate that you meet each of the requirements stated above. The test executive is expected to have a programmed set of commands to demonstrate each of the requirements6.
  1. A software baseline consists of all the code that we currently consider to be part of the developing project, e.g., code that will eventually be delivered as part of the project results. It does not include prototypes and code from other projects that we are examining for possible later inclusion in the current project.
  2. A component is a unit of software that has an interface and object factory and is build as a DLL (shared library in Linux speak). Each of the policies we are implementing in this project are components. We will discuss this at more length in succeeding lectures.
  3. In C# a package is a single file that has a prologue, consisting of comments that describe the package and its operations, one or more class implementations, and a test stub main function that serves as a construction test while building the package. This test stub is quite different from the test drivers we use for integration test. We will discuss these differences in detail in the lectures.
  4. In this project, for simplicity, we will use text names for credentials. Obviously that is not a good idea for a production Repository.
  5. We will implement a much more effective display in Sample Project #4, using a Graphical User Interface (GUI).
  6. Project #4 will implement a more flexible input process.

What you need to know:

In order to successfully meet these requirements you will need to know:
  1. The definition of the term package and have looked carefully at a few examples.
  2. How to implement C# console applications.
  3. How to build Dynamic Link Libraries (DLLs).