Re: why workspaces

Well, the preamble puts the subject into more layman's terms, so its
clearer to people (like me) who are not in the business of developing
version control systems.  But, the remainder is probably sufficient
for a spec.

Thanks,
Russ


-------- Original Message --------
Subject: Re: why workspaces
Date: Thu, 12 Oct 2000 20:58:05 -0400 (EDT)
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: Russ.Pridemore@bigfoot.com
References: <39E64127.5DCFE227@worldnet.att.net>

Great!  Should I include that preamble (about having a sandbox on the
client) or is the text between the "----" marks sufficient?

Cheers,
Geoff

   Date: Thu, 12 Oct 2000 18:54:31 -0400
   From: Russ Pridemore <russ.pridemore@worldnet.att.net>

   Thank you for this explanation of workspaces.  It is *much* clearer
now
   (to me, at least :-).

   Russ

   -------- Original Message --------
   Subject: Re: why workspaces
   Resent-Date: Thu, 12 Oct 2000 11:34:29 -0400 (EDT)
   Resent-From: ietf-dav-versioning@w3.org
   Date: Thu, 12 Oct 2000 11:33:34 -0400 (EDT)
   From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
   To: ietf-dav-versioning@w3.org
   References: <200010112138.RAA10083@tux.w3.org>
   <20001012015825.Y347@lyra.org>


      From: Greg Stein <gstein@lyra.org>

      Well... as a counterpoint argument: I've never viewed workspaces
as a
      central concept. I've always found them rather bothersome. That
   darned
      Workspace header just felt a bit wrong to me. Thankfully, I could
   implement
      a lot of DeltaV and just completely disregard the workspace
concept.

   You are maintaining a copy of the versioned resource tree (sometimes
   called a "sandbox") on your client I assume, for local builds,
   disconnected use, etc. ?

   Now what if you wanted to represent that sandbox on the server?
   That's what a workspace is.

   Here's some additional motivation I'll be adding to the "Workspace"
   section of the protocol:

   -----------------------------
   It is often desirable to allow several clients on behalf of a single
   user to access a related set of checked-out resources.  In
particular,
   this allows a user to access these resources from several physical
   locations, such as from another office, from home, from a remote
site,
   or while traveling, without being forced to prematurely checkin those
   checked-out resources.  Sometimes it is even desirable to provide
   shared access to checked-out resources for several closely
cooperating
   users (using WebDAV locking to avoid overwrite problems).

   If only one set of checked-out resources is required, then this can
be
   achieved with core versioning by simply checking out the appropriate
   version selectors.  This approach is often unacceptable because it
   exposes the intermediate states of the checked-out resources to every
   client, and does not allow for a second set of checked-out resources
   to be defined for a group that wishes to be isolated from the
   intermediate states of another group.  Unfortunately, working
   resources do not address this problem, because although they allow
   multiple concurrent checkouts from a single version history, there is
   no mechanism for grouping related working resources into an
   identifiable set.

   A related problem is that it is often desirable to isolate clients
   from a logical change that involves renaming shared resources, until
   that logical change is complete and tested.  When all clients use a
   common set of shared version selectors, every client sees the result
   of a MOVE as soon as it occurs.

   An additional problem is that it is often necessary to perform
testing
   on the server rather than on the client.  Since a test routine on the
   server has no way of knowing what working resources or what versions
   are to be tested, only the versions selected as the current target of
   the version selectors can be tested.  This not only does not allow
   testing of a checked-out resource before checking it in, but also
does
   not provide for any parallel testing of different configurations of
   versioned resources.

   To address these problems, advanced versioning introduces the concept
   of a "workspace".  A workspace is a collection whose members are a
set
   of related version selectors and unversioned resources.  In order to
   expose multiple views of a set of related version selectors in the
URL
   namespace, multiple workspaces may be used.  In order to make a
change
   made to a version selector in one workspace visible in another
   workspace, that version selector must be checked in, and then the
   corresponding version selector in the other workspace can be updated
   to display the content and dead properties of the new version.  In
   order to ensure unambiguous merging and baselining semantics, a
   workspace may contain at most one version selector for a given
version
   history (although a server may support multiple bindings in a
   workspace to the same version selector).

   ----------------------------------

Received on Friday, 13 October 2000 19:20:33 UTC