view and config specification

Hello all,

I work in a concern on a multi-site project with well over 500 developers in
3 different countries with about 5 different development sites and about 100
different projects. There I'm using Rational's ClearCase more than every
other program. I've also worked with some more different version control
systems for different companies and decided to share some of my insights.

Mainly I want to introduce two very powerful features of CC I most value and
which are fairly simple to implement. I don't suggest you have to run and
put it into subversion, I just wanted to share the knowledge and see what
you are thinking about it.

Config Specification
---------------------

The config specification is a simple text file that specifies the file and
directory version I want to have in my checkout.

In my company it consists of about 300 lines that specifies the packages
used for every project, a second file that specifies the customer base
differences from to the last release and a third file that contains the
differences of a specific project to the last release. The packages are
delivered by a lot of platform teams and are taken over by the customer
base. Customer base means, it is the basic software platform for one
customer. The single projects sit on the customer base and choose alternate
systems, do minor alterations and stuff to fit the projects needs.

Integrating a platform package ins mainly done with the config spec (CS) by
selecting the labels of the desired platform package and creating a delivery
label for the customer base. Many groups do that at the same time and
without a proper CS, this kind of large development would not be possible at
all. Some of the bigger version trees hold several thousand versions of the
same file.

What does this file look like. For my own private project it would look
like:

#---------------------------------------------
# Config Spec for the Meson project
#---------------------------------------------

# select all checkouts
element * CHECKEDOUT

#select all files with my userlabel
element * SGE_001

# library versions
element /projects/baselib/... BASELIB_2.1.1
element /projects/datastore/... DS_0.5.3
element /project/meson/makefile /main/gl_rend/5

# meson project
element /project/meson/src/engine/oldvertex.c -none
element /project/meson/... GL_REND.0.3.2
element /project/meson/... MESON.0.3.2

#element * /main/LATEST
#---------------------------------------------

If you read it from top to bottom - every rule that fits first will be
taken. This rules are applied to all checkouts at the time they are taken
from the repository. In this case I have an accurate specified sandbox that
is reproducable any time if I put this CS under version control too. I've
noticed some kind of precursor to this concept in SubVersion: it's the
complex tags.

The syntax of the file is fairly easy:
    # Comment
    element pattern version_selector - select all matching
files/dir-pattern of the specified version
    include version_extended_name - include a file in the
repository

Pattern:
    * all files and directories
    path\... the specified path including subdirs
    path\file the exact specified file
    path the exact specified directory
    ...\path\... everywhere, where the path pattern fits including
subdirs

Version Selector:
    \main\gl_rend\6 absolute version spec
    GL_REND.1.3 all versions where this label is applied
    CHECKEDOUT my current checkouts (this is handled different in CC, I
will explain later)
    \main\LATEST the latest version of the main branch
    -none we don't want the pattern, hide it

The version_extended_name is a combination of path/file@@/version like:
    /project/meson/src/engine/oldvertex.c@@/main/engine/27

This feature is IMHO a top hot spot for multi-site, large scaled
development. A finely controlled time machine that enables every team to
reproduce any made software configuration ever made. I think it should also
be quite easy to implement. A pearl script could do that but it would be
slow with larger repositories.

Views
-------

Subversion sees a checkout as the sandbox. CC calls that a view. The
difference is, that in CC is a workspace, that is created by a developer,
stored in the repository and set up with a config spec. When a user wants to
modify a file, it is checked out - either unreserved or reserved (usually
unreserved). In the repository, the config spec and the checkouts of the
user are stored. At any time the user may sync the changes and subit it
temporary to the view server.

This way, CC is able to show in a version tree what user is working on the
same file and on what branch. It is quite easy to communicate the changes
this way and conflicts are resolved early. It is also possible to crosscheck
my own changes against the latest work copy of another developer. This also
enables the groups to introduce effective software review processes of a new
system function before a checkin has taken place without packaging all the
files and complicated actions. The work of other developers is plain
visible.

In our company this serves more than one purpose. Additional to the benefits
mentioned above it is used for the integration process. They give out
bookable time slots where the integration take place, the changes will then
be committed as a function spawning many files at once, not as sequence of
single files. After that a metadata is applied that hold the change-request
number and an integration label is moved to every integrated file. The
finishing touch is done by some scripts, writing down the differences to the
last integration in a config specification on a exact file base that is
determined by the integration label and a file list is done, that is kept as
reference to the special change request.

That way every single integration is reproducable and documented for the
change log. Tracking changes is no topic anymore.

---
I've added a screenshot of a small filetree that give some additional
insights (sorry, I needed to grey out the company related tags, but I've
written some substitutes below). The UNRESERVED thingies on the pictures are
checkouts. Two of them are made by the same user in two different views.
BTW: the red lines are merge-arrows. If a revision is related to more
revisions that it's precursor a merge leaves a trace in form of the merge
arrow. It also may be only painted to give a hint to relations.
I hope this mail is of use for the community. In the next days I will try to
set up a sandbox and try to compile a SVN on my windows system here.
Hopefully I can find the time to toy a bit around and make my first steps in
SVN development.
Best regards
Gerald Scheidl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org