S T B H P N

Project #2 - Software Repository Testbed

Spring 2018

Version 1.1 , Due Date: Tuesday March 6th

Purpose:

When a software system becomes large there may be many hundreds, or even thousands, of packages that make up its source code. Efficient development requires a means for reliably storing, versioning, and viewing each of its parts.

The second project this Spring focuses on building the core capability of a Software Repository. The Repository is intended to manage a, possibly large, collection of source code packages, providing versioning, check-in, check-out, and browsing.

This first stage will consist of a single RepositoryCore process, with an integrated client used for testing. It does not attempt to provide a user the ability to use its features by asynchronous actions. Rather, the client simply provides a programmed set of tests to demonstrate the core capabilities.

We will use the NoSql databased, developed in Project #1, to store metadata about each file in the repository. Version numbers will be appended to file names on check-in. All other information will be contained in metadata, e.g., description, author, check-in status (open or closed), files on which it depends, categories to which the file belongs, and its storage path in the Repository.

In later projects we will build interprocess communication channels and user interfaces to support user interactions from separate client processes.

Requirements:

Your RepositoryCore Project:
  1. (1) Shall use Visual Studio 2017 and the standard C++ libraries, as provided in the ECS computer labs.
  2. (1) Shall use the C++ standard library's streams for all I/O and new and delete for all heap-based memory management1.
  3. (2) Shall provide C++ packages:
    • TestExecutive: executes a sequence of tests to demonstrate core Repository functionality.
    • RepositoryCore: provides means to check-in, version, browse, and check-out source code packages.
    • Check-in: provides the functionality to start a new package version by accepting files, appending version numbers to their filenames, providing dependency and category information, creating metadata, and storing the files in a designated location.
    • Check-out: retrieves package files, removing version information from their filenames. Retrieved files will be copied to a specified directory.
    • Version: manages version numbering for all files held in the Repository.
    • Browse: provides the capability to locate files and view their contents.
    You are free to alter the names and division of responsibilities as you see fit. However, you are expected to enforce the "Single Responsiblity Principle"2 as illustrated in the package structure described above.
  4. (3) Shall support check-in by accepting a single package's files3 and append a version number to the end of each file name, e.g., p5.h and p5.cpp become p5.h.3 and p5.cpp.3 if the package name is p5 and the last closed check-in for that package was version 2. A check-in is open, by default. A package with open check-in can be modified without altering its version number. Once a check-in is closed, that version of the package becomes immutable.
    The author of a check-in defines all of the packages that the check-in package depends on. However, a check-in can only be closed if its dependent packages are all present in the Repository, with closed check-ins.
  5. (5) Shall support browsing of one or more packages by displaying package descriptions. The packages to be browsed are identified by a query on the NoSql database that holds metadata for all packages in the repository. The full package text shall be displayed on demand, identified by one of the keys returned from the initial browse query.
  6. (4) Your Repository shall be submitted with several packages, all with closed check-ins, and a few packages with open check-ins.
  7. (2) The TestExecutive shall execute a series of tests that clearly demonstrate your project satisfies each of the Requirements, above.

  1. That means that you are not allowed to use any of the C language I/0, e.g., printf, scanf, etc, nor the C memory management, e.g., calloc, malloc, or free.
  2. https://en.wikipedia.org/wiki/Single_responsibility_principle
  3. This is in addition to the construction tests you include as part of every package you submit.

What you need to know:

In order to successfully meet these requirements you will need to know:
  1. Details of the C++ language: http://CppReference.com.
  2. All those things you learned while developing code for Projects #1.
  3. How the CodeAnalyzer works. The TAs and I will give you a lot of help with this.
    Also, you should look at the blog: Parser.
  4. A Strong Component Algorithm: Tarjan Algorithm description and pseudo code
  5. The STL Containers.