Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [alf-dev] ALF Source Code Maangement Vocabulary Meeting +1-303-928-3232 id 6053141# 10:00AM PDT

There will be a ALF Source Code Management Vocabulary Meeting tomorrow,
Wednesday April 19th at 10:00AM PDT

The call in number is

+1-303-928-3232 id 6053141#

Agenda

0. Last week's minutes (below)
1. Discuss milestone dates and who can do what.
2. Discuss Richard T's proposal (below)
3. Wikki update
4. Any other business



From: Richard Title  

I see SCM as a challenging area because there are a number of vendors
with different models.

Below are some thoughts toward the first 2 sections of your proposed
document (concepts, and use cases). 

I'll leave Schema and WSDL to those with more expertise in those areas.

The concepts that follow are loosely based on JSR 147, which is a
standard Java API for SCM

 (http://www.jcp.org/en/jsr/detail?id=147 ) worked out by a consortium
of SCM vendors not too long ago.

I thought it might be helpful to build on their work rather than
starting from scratch.

For use cases, I drew from an earlier "SCM use cases" document that I
sent out to the alf-dev mailing list a while ago.

Richard Title
AccuRev

Concepts (Objects)

1. File, Directory, Filesystem
    Let's reserve these terms to refer to actual files and directories
on an operating system filesystem. Files may or may not be under source
control.

2. Element 
    An SCM object that is created when a file is put under source
control.

3. Version
    A SCM object representing a version of an element. Versions are
typically created through "checkin" or "keep" operations. 

    Versions have contents, which are an immutable sequence of bytes,
and correspond to the file contents at the tim of the "checkin"/"keep".

    Versions are linked up into a graph via predessor/successor
relationships.

4. Change-Set (Activity)
    A set of versions (i.e. changes from previous version) that
logically go together, e.g. all part of the same defect fix.

5. Branch
    Within a version graph of a single element, a branch would be a
named linear sequence forming one path in the version graph.

    Typically many elements share the same set of named branches (in
ClearCase terminology, the branches have the same branch-type),

    and then we speak collectively as in "latest versions on branch
MAINTENANCE".

6. Stream
    Conceptually similar to a branch (we speak of a "stream of
development"), streams also connote a particular development model.

    Streams form a hierarchy, and versions are promoted up through the
stream hierarchy. ClearCase UCM and AccuRev (and probably others)

    implement a stream model.

7. Workspace (View, Sandbox)
    Workspaces are an environment by which users can make changes to the
persistent SCM objects (e.g. create new versions).

    A workspace corresponds to a directory tree on the filesystem,
containing files that are under source control.

    Files in a workspace correspond to versions of elements.

    New versions are created by keeping/checking in files in a
workspace.

8. Configuration
    Loosely speaking, a configuration refers to the rules specifying
what versions of what elements should be loaded into a workspace.

    In base ClearCase, this corresponds to a "config spec", while in
stream-based models such as ClearCase UCM and AccuRev,

    the configuration is determined strictly by the workspace's position
in the stream hierarchy.

9. Baseline (Snapshot)
    A fixed set of versions, one per element, which can be later
reconstructed.

10. Repository (Vob, Depot)
    The persistent store housing all the SCM systems metadata.


SCM Use Cases (Operations)

1. Create a workspace(sandbox) (view) 
    A workspace is characterized by a place on your local filesystem
where the files correlate to objects under SCM control. Workspaces are a
sharing mechanism: Different users have different workspaces (views)
into the same set of underlying objects.

    "mkws" - AccuRev

    "co" - CVS (creates and populates the sandbox)

    "mkview" - ClearCase

2. Remove a workspace(sandbox) (view) 
    Undoes #1

    "rmws" - AccuRev

     nothing - CVS (just delete the files)

    "rmview" - ClearCase

3. Put a set of files under source control. 
    This create elements corresponding to each file, and creates an
initial version of each element whose contents come from the file.

    "add" - AccuRev, CVS

     "mkelem" - ClearCase

4. Remove elements from source control 
    Undoes #3. Could be implemented by just hiding the elements, if the
SCM system doesn't want to destroy information.

   "defunct" - AccuRev, 

    "remove" - CVS

    "rmelem" - ClearCase

5. Mark a element as being worked on, either exclusively or
non-exclusively 
    "Exclusive" means you are preventing others from working on it at
the same time. Non-exclusive may be a no-op in some systems, or it may
have the effect of making the corresponding file writeable in some other
systems.

   "co" - AccuRev (only needed for exclusive locking)

   "edit"  - CVS (only needed for exclusive locking)

    "checkout" - ClearCase (makes the file writeable, there are
different switches for exclusive vs non-exclusive)

6. Create a new version of an element
   The operation by which new versions come into existence. Takes the
contents of a source file, creates a new version based on those
contents, and puts the new version into the corresponding element's
version-history. Versions of an element are linked into a graph by
predecessor/successor relationships.

   "keep" - AccuRev,

   "ci" - CVS,

   "checkin" - ClearCase

7. Create a new branch (stream) to support parallel development
    The general idea is that new versions are created on that branch. So
for instance, a set of elements might have a maintenance branch/stream
and a future-development branch/stream, each with its own sequence of
versions.

    "mkstream" - AccuRev

    "tag -b" - CVS

    "mkbrtype"  - base ClearCase

    "mkstream" - ClearCase with UCM

8. Capture a baseline (snapshot) 
     The general idea is to capture a fixed set of versions that can be
re-materialized at a later time.

     "mksnap" - AccuRev

     "tag" - CVS

     "mklabel" - base ClearCase

     "mkbaseline" UCM ClearCase

9. Materialize a set of files in a workspace
    The files correspond to underlying elements in the SCM system.

    "update" - AccuRev, CVS, ClearCase (for snapshot/web views, implicit
for dynamic views)

10. Get history of an element or set of elements 
     Time-ordering listing of the history of changes.

    "hist"  - Accurev

    "history" - CVS

    "hist" - ClearCase

11. Compare versions of element(s)

   "diff" - AccuRev, CVS, ClearCase

12. Perform merges of versions, from one branch/stream to another 

   "merge" - AccuRev, CVS, ClearCase

13. Promote versions up the stream hierarchy
    Modern SCM systems define a process by which changes propagate up a
hierarchy of streams. This use-case is to support such a hierarchical
model.

   "promote" - AccuRev

   "deliver" - ClearCase with UCM

14. Define a change-package (activity)  
    This is typically to support associating a set of changes with a
defect. A change-package is typically defined as a set of versions
without gaps (though other definitions are possible).




-----Original Message-----
From: Tim Buss 
Sent: Wednesday, April 12, 2006 11:40 AM
To: 'ALF Developer Mailing List'
Subject: RE: [alf-dev] ALF Source Code Maangement Vocabulary Meeting
+1-303-928-3232 id 6053141# 10:00AM PST

Wednesday, April 12, at 10:00am PST conf call

Meeting Minutes:
Proposed Agenda:
1. Make introductions
2. Discuss how we want to proceed

Attendees
Tim Buss - Serena
Glen Everett - Compuware
Eric Minick - Urban Code
Scott McGrath - Accurev
Matt Laudato - Accurev
Richard Title - Accurev
Mark Phippard - Soft Landing
 
1. Introductions and interest.

Tim - interest driven by ALF and as a tool provider Glen - interest
driven by Corona - a common vocabulary and events from tools helps with
collaboration Eric - interest driven by point to point integration
implementations Scott, Matt, Richard - interested as a tool provider
Mark - interested as a tool provider for company products and
Subversion.
 
2. Proposed approach was discussed
 
A. Concepts  - To enumerate and describe generally the basic concepts we
are trying to capture B. Use cases - The set of core use cases we think
are common and generally useful C. Schema - A formal definition of the
data D. WSDL - A formal definition of the services E. Overview -
Something to tie it all together

It was agreed that this was a reasonable approach.

A general question was raised as to the scope of a vocabulary and what
we might do with functions that are not universally supported (ie one
tool supports and another doesn't) - ALF vocabularies should encapsulate
a core set of functions. Its purpose was to useful and make things
easier but not to provide rigid standard.  Thus tools were welcome to
provide additional services outside of Core and there was no obligation
for a tool to provide all the functions defined by ALF.  That said, the
idea is that we achieve some level of interchangeability especially in
the case of Open Source.

Richard Title shared a straw man proposal for the SCM concepts and use
cases.  Thanks Richard.

We discussed using a wikki to collaborate on the document.  A possible
host for this are the experimental one put together by Richard Gross
(see link on ALF web site).  Others have also indicated they may be able
to host it.

A Face to Face meeting was suggested.  While this is a possibility we
would need to justify it to our respective management.  Possibly it
would be more interesting once we have a couple of vocabulary areas
active so we can normalize efforts.

Action Items
1. Investigate Wikki - Tim
2. Review Richard's proposal - All - this means YOU 3. Create additions
to this proposals and/or suggest alternatives - All - this means YOU.
4. Agenda for next week - Tim
	Items so far
	Discuss milestone dates and who can do what.
	Discuss Richard T's proposal
	Wikki update

Tim Buss,
Serena

**********************************************************************
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.



Back to the top