W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Protocol support for maintaining a "local file area" on the client

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 27 Apr 2001 14:51:52 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E23A8@SUS-MA1IT01>
To: ietf-dav-versioning@w3.org
   From: Tim_Ellison@uk.ibm.com [mailto:Tim_Ellison@uk.ibm.com]

   "Clemm, Geoff" <gclemm@rational.com> wrote:

   > I've been reviewing the protocol wrt client maintenance of a
   > "local file area" (i.e. a tree of files on the client that
   > reflect the state on the server).  I identified two issues:


   > The second issue was having multiple file areas for the same
   > workspace.

   What is a 'file area'?

See above.  A file area is "a tree of files on the client that
reflect the state on the server".

   > To handle this efficiently, we could allow one workspace to be
   > UPDATE'd by another.  This allows a client to create a separate
   > workspace for its file area, and then use UPDATE to determine how
   > that file area should be changed to reflect the changes made to
   > some shared workspace.

   > JimW: Note that this also makes your "initialize a new workspace"
   > scenario much simpler ... you just use one UPDATE call instead of
   > a series of VERSION-CONTROL calls.

   Sounds similar to the operations currently available under baseline
   -- but I'll wait to hear what a file area is first.

Yes.  The only difference is that it allows you to have multiple file
areas before you are ready to baseline (e.g. you want to compile on a
couple of different platforms before creating the baseline).

Similarly, it is a convenient way to initialize a new workspace to
select the same versions as an existing workspace, even when you are
not ready to "baseline" the state of that existing workspace.

Received on Friday, 27 April 2001 14:51:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC