Browse Prior Art Database

Separating work in a repository-based team environment for software development with integrated version management using a Working Copy for every user

IP.com Disclosure Number: IPCOM000014364D
Original Publication Date: 2000-May-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 8 page(s) / 167K

Publishing Venue

IBM

Abstract

Scenario:

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 8

  Separating work in a repository-based team environment for software development with integrated version management using a Working Copy for every user

Scenario:

    The issue addressed in this article is based on a problem encountered in a customer project. The project was supposed to build an integrated software development environment (IDE) for developing, testing, building, and deploying software for micro controllers that are connected through different network or bus systems. The customer, a automobile manufacturer, wanted to use the new tool to develop software for in-car controllers, e.g. to control the in-car lights.

    Some of the requirements for the development environment that are important to understand this article are the following: client / server architecture, i.e. a server manages all development artifacts, clients access the server to manipulate the contained development artifacts allow full version control of the development artifacts allow team development with concurrent access to the development artifacts by different
users each user can use the IDE from an arbitrary client to work with the development artifacts each user has its own view on the development artifacts development artifacts are owned by a user more than one user can access a development artifact (the exact access control is not
described here) different user can be allowed to change the same development artifact only the owner of a development artifact can control the release of a development artifact allow relationships between development artifacts, i.e. any kind of bi-directional
relationship allow application-specific consistency checks on the development artifacts and their
relationships

    With these requirements it was not possible to use a simple-file based source code management system (SCM). A repository-based system that holds all the development

1

Page 2 of 8

artifacts was chosen, because it fits this scenario much better.

    Existing repository-based team environments for software development, like IBM VisualAge for Java, which is based on the repository technology called ENVY from Objet Technology Internal (OTI), offer most of the support needed for the project. But for different reasons, whether VisualAge nor ENVY was used in the project: no local storage of user data were allowed, but VisualAge does this in different local files, logically known as the user's workspace no one-to-one mapping between user and client workstation were allowed, but since VisualAge uses local files to store user data, the user always has to work on the same client workstation the concept of organizing development artifacts in VisualAge is quite simple, yet strict: only containment relationships are allowed between the development artifacts, which are more or less unidirectional since the contained object is always accessible through itscontainer object the top most development artifact, that acts as the overall container for all developed objects in one logical gro...