Next message: Dan Kegel: "Re: Three questions, and a paean to Perforce"
Date: Tue, 9 May 2000 09:50:45 -0400 (EDT)
Message-Id: <200005091350.JAA22553@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Three questions, and a paean to Perforce
From: Dan Kegel <dank@alumni.caltech.edu>
Newbie here, with three questions.
I've been using revision control systems for 17 years,
from futz-with-diff-and-patch to RCS to CVS to MKS SI
to SourceSafe to Perforce and back.
One thing that always was mysterious until recently
was branching. Nobody I knew ever used it successfully,
since the complicated revision ids it caused were confusing.
Yes, any system that requires the user to understand and
manipulate revision ids in order to branch is likely to
be very confusing. On the other hand, CM systems that
automate branching have been around for a couple of decades,
but the best ones aren't cheap/free.
That is, until Perforce.
Perforce has a universal naming convention that lets you represent
documents in the central depot as well as in working areas.
e.g. if the central depot is called 'depot', and I've created a workspace
named 'dan_work', the document ks/dev/main.c is referred to as
//depot/ks/dev/main.c in the central depot, and as
//dan_work/ks/dev/main.c in my workspace.
The WebDAV versioning protocol provides direct support for workspaces
of this kind.
Perforce uses this naming scheme to do the impossible: make branches understandable!
It uses a geographical paradigm: rather than encoding
the fact of the branch in a collection of documents' version ids,
it makes you encode it in the collection's path.
The main reason file-based CM systems use the filesystem namespace for
both the data being versioned and the workspaces that determine the
version selection is that it is the only namespace they have. In
contrast, the headers provided by HTTP provide a mechanism for
separately specifying the versioned resource and the workspace of a
request. In particular, the request-URL is the versioned resource and
a Workspace header specifies the workspace.
This has the advantage that absolute references (which are very common
in href's) continue to work in the presence of versioning.
On the other hand, there is an advantage to versioning unaware clients
to let them see the contents of a workspace "under" that workspace,
since a versioning-unaware client does not know how to use the
Workspace header.
I have therefore added this to the "issue list" (it appeared on the
agenda for this weeks phone call). In particular, I propose that
a workspace resource be modelled as a collection resource, and that
the "contents" of a workspace can appear as members of that workspace.
For instance, if I want to branch the collection of documents under
ks/dev, and call the new branch 1.1, I give a command that copies
all files under ks/dev to the new area ks/1.1. Version ids of
the new files under ks/1.1 start from #1.
In the versioning protocol, this would be marshalled as a
MKWORKSPACE /ks/1.1
MERGE /ks/dev
Workspace: /ks/1.1
As for the version id's, that's up to the server, and the user
shouldn't care much what happens with those.
This strategy lets Perforce get away with very simple version ids,
yet have all the power one needs to do branching of whole collections
of documents in what seems like a sensible way to me.
The versioning protocol does not attempt to require any particular
version id namespace (simple or otherwise), since a user should not
have to be aware of them, and many implementations use the version
id's in different ways.
My questions are:
1. does WebDAV's proposed versioning model support
the paradigm Perforce uses? i.e. do Perforce commands map cleanly
onto the proposed versioning model?
I believe the answer is yes.
2. Has anyone else on this list used Perforce?
I've studied it, but I haven't really used it.
3. I notice that Christopher Seiwald (seiwald@perforce.com)
was a frequent contributer to this list several years ago.
Is anyone from Perforce currently represented here?
Not that I know of, but if nobody shows up by final call,
I definitely plan on giving Chris a personal call myself.
Cheers,
Geoff
--
Geoffrey M. Clemm
Chief Engineer, Configuration Management Business Unit
Rational Software Corporation, the e-Development Company
(781) 676-2684 geoffrey.clemm@rational.com http://www.rational.com