RE: Version issues

I'd like to weigh in with Bruce for keeping Level 1 as simple as possible.
Xerox has several products that do linear versioning only, and versioning of
individual resources only, and have no use for workspaces that I can see.
The client always gets the tip revision unless it requests a particular
revision by id.  (There's no notion of a label that a client could assign.)
We'd like them to use WebDAV versioning, but it will be a hard sell if Level
1 forces them to implement a lot of stuff that they don't really need.

-----------

I'd like to describe the model used by one of these products, because it has
several features that may break your view of how version management works:

The user can decide, when creating a document, whether it is versioned or
not.

Assuming that the user specifies that a given document is versioned:

Only simple linear versioning is supported.  Only individual documents can
be versioned.

Revisions are immutable.  That is, once a revision is created, it cannot be
modified.

The server assigns identifiers to revisions, and has the notion of the tip
revision.  Clients cannot assign labels to revisions.

There is no checkout operation.  There is only a "new revision" operation on
the document (on the version series), which results in a new revision being
created at the tip of the series, with the content submitted with the
request; if the document was locked, only the lock owner can do a "new
revision", and the "new revision" operation also unlocks it.

The user can specify how many revisions are to be saved.  This number can be
changed at any time.  Once that number of revisions exist, when a new
revision is created, one is thrown away from the beginning of the list.
There is no trace left of any revision that has been thrown away in this
way.  Version history information is saved only for the most recent n
revisions, where n is the number of revisions the user asked to have saved.

Only one report can be generated.  It contains the revision id, revision
date, user who created the revision, and comments for each revision of the
document.

--Judy

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


> -----Original Message-----
> From: Bruce Cragun [mailto:BCragun.ORM2-1.OREM2@GW.Novell.com]
> Sent: Wednesday, February 17, 1999 7:13 PM
> To: jamsden@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: RE: Version issues
> 
> 
> Okay, I see our disconnect.  You are assuming that, even in 
> Level 1, we
> want some method of creating / identifying a logical *set* of 
> resources,
> such as all revisions that made up a particular milestone or release. 
> In the DMS world there is no such grouping ability; every 
> file is on its
> own.  In the web site arena, however, I can see some value in this
> grouping concept.
> 
> A simple versioning client and/or server, I believe, will not 
> generally
> implement workspaces if given a choice.  If that is true, then I would
> vote to leave workspaces in Level 2.  If with my particular product I
> want only basic versioning, but the ability to create sets 
> (workspaces)
> is important, then I can implement Level 1 versioning and add 
> workspaces
> without the rest of Level 2.  Now my client and my server can take
> advantage of the ability to use workspaces, but other peoples' Level 1
> clients can still make use of my server.  Workspaces are a useful
> "utility" not a required piece of functionality.
> 
> So I vote workspaces remain in Level 2.
> 
> >>> <jamsden@us.ibm.com> 02/17/99 01:44PM >>>
> 
> 
> Bruce,
> I'm sorry to hear you weren't feeling well, but welcome back!
> 
> No, you're getting it just fine. For your item 1 below, the default
> workspace does just what you want. You never even need to know its
> there.
> Recall the default workspace has a revision selection rule containing
> checkedout and latest.
> 
> For item 2, the model currently allows access through a specific
> revision
> name which temporarily overrides the workspace, so this can be done
> too.
> 
> If this was all you wanted, then probably workspaces for level 1 would
> be
> overkill. But, lets look at some other simple scenarios and see what
> would
> happen.
> 
> Say a development organization finishes work on  a milestone and wants
> some
> way to refer to the proper revisions. When work continues, these
> revisions
> won't necessarily be the latest revision because the resources may
> have
> changed in some appropriate way. Configurations solve this in level 2,
> but
> a common scenario for level 1 might be to come up with a label for the
> release and use this label on every revision that participates.
> 
> So now every time you want to get the R1 revision for any of these
> resources, you have to remember the revision name and provide it on
> each
> access. That's not so bad though, and is the same thing as remembering
> a
> workspace that has checkedout, R1, and latest in its revision
> selection
> rule. So far this is a wash.
> 
> Now say there's an R2 of the project as a whole. Some of the resources
> changed and some of them didn't. You could label all the participant
> revisions with R2 and that would work. But, after a while specific
> revisions might have a lot of labels on them making the revision
> history of
> many resource hard to manage. In addition users have to remember
> something
> new, use label R2 instead of R1. An alternative is to just label the
> ones
> that changed with R2 and put checkedout, R2, R1, and latest in the
> revision
> selection rule. Then you'll get the right versions without remembering
> R1,
> R2, ..., you only have to remember the same workspace you were using
> before
> the revisions changed. All users get updated just by updating their
> workspace. The default workspace revision selection rule can 
> be changed
> to
> so that clients that can't or don't specify a revision will get the
> right
> revisions too. You could do this with default labels, but it 
> would take
> a
> lot more work to update a property on every resource resetting its
> default
> when you can just add a single entry to a revision selection rule.
> 
> Workspaces just provide flexibility and ease of use for level 1, not
> any
> new functionality. I think they make the clients simpler and simplify
> the
> user's interaction with the server. So they are useful for level 1
> even
> though there aren't any activities or configurations.
> 
> 
> 
> 
> 
> 
> "Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/17/99
> 03:10:40 PM
> 
> To:   ckaler@microsoft.com, Jim Amsden/Raleigh/IBM
> cc:   ietf-dav-versioning@w3.org 
> Subject:  RE: Version issues
> 
> 
> 
> 
> It isn't that workspaces provide unneeded functionality for Level 1.
> It's just an abstraction that a) isn't in simple versioning models
> now,
> so would require learning and understanding, and b) isn't necessary.
> 
> The way I envision it for a Level 1 implementation is this:
> 
> 1. If I request a resource and specify nothing other than "get me this
> resource" the default is to give me the latest.  Without branching and
> other Level 2 features, this is trivial.  With Level 2
> implementations,
> this is interpreted as the latest on the main line.
> 
> 2. If I want something other than the latest, I include a Revision Id
> or a Label.  This works fine for both levels, without any complexity
> whatsoever.
> 
> Am I just not getting it?
> 
> >>> <jamsden@us.ibm.com> 02/17/99 11:20AM >>>
> 
> 
> Comments below in <jra> tags.
> 
> 
> 
> 
> 
> Chris Kaler <ckaler@microsoft.com> on 02/17/99 12:13:42 PM
> 
> To:   Jim Amsden/Raleigh/IBM
> cc:
> Subject:  RE: Version issues
> 
> 
> 
> 
> I don't think level 1 servers want to deal with revision selection
> rules.
> I
> suspect they could be complicated.  As well, we need to understand the
> semantics of parallel checkouts in the "default workspace".  The
> current
> definition of a workspaces prohibits this and I think it is an
> important
> requirement for level 1.
> 
> <jra>
> Level 1 revision selection rules don't need to be complicated at all.
> There
> are no activities or configurations, so the revision selection rule
> has
> checkedout and 0 or more labels. When a resource is accessed with a
> simple
> URL, this means, get the checked out revision if any, otherwise look
> for a
> revision that has a matchin label. It's hard to imagine anything
> simpler.
> </jra>
> 
> Geoff and I started talking about the Revision-Id header yesterday.  I
> think
> it is reasonable for a client to request version X of /foo/bar.htm.
> It
> seems a cumbersome requirement to have to set the revision of
> /foo/bar.htm
> in the default workspace to be X and get /foo/bar.htm.  As well, this
> won't
> scale at all.  Imagine one person trying to get version X and one
> trying to
> get version Y.  We clearly need more discussion on this, but I don't
> yet
> see
> how we can eliminate a header that specifies a revision.  I do believe
> that
> we could condense several headers into one...
> 
> <jra>
> I also belive that users want to access specific revisions given the
> label.
> If they can assign a label, they should be able to access the resource
> that
> they assigned the label to. Recall that this capability is in the
> model. In
> the new version I moved the method to Repository.getResource(url :
> String,
> label : String = null) : Resource. There's also
> Repository.getResource(url
> : String, context Workspace) : Resource to access a resource in the
> context
> of a workspace. One reason you would want to do this is if you want to
> look
> at an old version, or compare two revisions, and don't want to change
> your
> workspace.
> 
> My issue isn't that I didn't want access by labels, only that access
> when
> labels aren't specified should use Workspaces to resolve the URL.
> </jra>
> 
> I, personally, think that RSR are interesting but probably too
> complicated
> for level 1 servers.  We could say that the SETDEFAULT method is a
> "utility"
> method that modifies the workspace to use the specified revision of
> the
> specified resource.  This allows us to still describe level 1
> functionality
> in the context of level 2 workspaces.  And for level 2, it provides a
> handy
> service for augmenting an RSR without having to pull it, modify it,
> and
> put
> it.
> 
> <jra>
> Again, I don't think revision selection rules are complicate at all,
> especially for level 1 which doesn't have activities, merging, or
> configurations. The complexity results from introducing multiple
> revisions.
> Leaving workspaces out of level 1 will just move the complexity to the
> client or user who have to remember lots of labels on a resource by
> resource basis. This makes the server simpler, but not WebDAV.
> 
> I stress again, what would anyone want to do with versioning level 1
> that
> workspaces wouldn't support? What would workspaces include that would
> be
> considered too much for level 1? We need specific scenarios that
> address
> these issues. As you know, I am also keen to keep things simple. Its
> just I
> want the simplicity for the users and clients, not necessarily just
> for
> the
> server.
> </jra>
> 
> Thoughts?
> 
> Chris
> 
> -----Original Message-----
> From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] 
> Sent: Tuesday, February 16, 1999 12:56 PM
> To: Chris Kaler
> Subject: RE: Version issues
> 
> 
> 
> 
> But if we keep the Revision-Id header and a SETDEFAULT method, this
> will
> conflict with level using a default workspace. I suggest we
> effectively
> use
> default workspaces for level 1. This doesn't mean servers have to
> implement
> them, only do something that makes them look like they work. Clients
> should
> be able to use level 1 services without being aware of workspaces. If
> activities and configurations are not in level 1, then the workspace
> only
> has to consider revision selection rules that include checkedout,
> latest,
> and revision labels. This should be pretty simple.
> 
> 
> 
> 
> 
> 
> Chris Kaler <ckaler@microsoft.com> on 02/16/99 03:21:30 PM
> 
> To:   Jim Amsden/Raleigh/IBM, ietf-dav-versioning@w3.org 
> cc:
> Subject:  RE: Version issues
> 
> 
> 
> 
> 
> [CK] Comments below...
> 
> A few issues came up at our last versioning working group meeting:
> 
> 1. DAV versioning level 1 will still need to be a way of resolving
> access
> to versioned resources given just a URL (and not a label). If
> workspaces
> aren't supported, level 1 servers will have to provide some other way
> to
> resolve URLs to specific revisions, perhaps a default revision for
> each
> versioned resource. For level 2 servers that do support workspaces,
> this
> would result in two, potentially conflicting ways of performing URL
> mapping. This is a strong argument for including workspaces in level
> 1.
> What would anyone want to do with versioning level 1 that workspaces
> wouldn't support? What would workspaces include that would be
> considered
> too much for level 1? If there are no compelling answers to these
> questions, we should include workspaces in level 1, including the
> default
> workspace.
> 
> [CK] I suggest we keep the Revision-Id header and the SETDEFAULT
> method.
> 
> 2. Deleting a resource must explicitly state that the resource is
> removed
> from its parent collection; that is, the collection with which the
> resource
> is an internal member. Versioning complicates delete semantics. There
> are
> three things we might want to delete: an unversioned or working
> resource, a
> revision (and all its descendents?) of a versioned resource, a
> versioned
> resource and all its revision history. This must be done in the
> context
> of
> versioned and unversioned collections that contain the resource, or
> versioned resource as an internal member. The preferred way to do this
> would be to have add and remove methods on collections to create and
> delete
> resources as its the collection that controls the namespace.
> Unfortunately,
> DAV doesn't have those semantics, so we will have to find a
> work-around
> for
> versioning.
> 
> [CK] I expect deleting a working resource to be the same as
> UNCHECKOUT.
> [CK] Deleting a versioned resource is up to the store.  Some stores
> might
> [CK] just delete it.  Some might create an "delete" version.  I don't
> think
> [CK] we want to push a specific model on people.  Especially since the
> [CK] DELETE method is about a resource and in no way describes the
> [CK] underlying repository actions.
> 
> Actually, the current WebDAV spec is a little confusing about
> collections
> and their members. The current spec indicates collections contain
> URLs,
> not
> resources. But, there is the notion of internal members and
> referential
> members, and deleting a collection deletes all its internal members.
> So
> the
> collection behaves like it contains resources, not URLs. This issue
> will
> likely get more confusing when we add versioned resources, versioned
> collections, and multiple revisions.
> 
> [CK]Your right -- some clarification here would be could.
> 
> 3. It is not possible to automatically create workspaces or activities
> for
> either non-versioning clients, or versioning clients that don't
> specify
> them. Default workspaces and/or activities must be used. Creating a
> new
> workspace or activity on each request could cause resources that were
> manipulated in the previous request to disappear.
> 
> [CK] If we say this is what "logically" happens on a Level 1 server
> then
> [CK] OK.  But if the server must in fact do this, then I think the
> cost
> [CK] is too high since Level 1 clients don't care about this
> information.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>

Received on Tuesday, 23 February 1999 11:44:53 UTC