RE: Version issues

I would like to see the levels split even more than that. I believe that 
some of the configuration management functionality can be considered 
"minimal" in order to be useful and the rest should be optional.

Has this forum had a detailed discussion on the levels of the versioning 
protocol? If not I think the time has come.

Cheers
Dylan

On Tuesday, February 23, 1999 5:48 PM, Slein, Judith A 
[SMTP:JSlein@crt.xerox.com] wrote:
> 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 Thursday, 22 April 1999 09:50:25 UTC