Re: Version issues
Jim Whitehead (ejw@ics.uci.edu)
Thu, 1 Apr 1999 16:55:40 -0800
From: Jim Whitehead <ejw@ics.uci.edu>
To: Versioning <ietf-dav-versioning@w3.org>
Date: Thu, 1 Apr 1999 16:55:40 -0800
Message-ID: <003001be7ca3$87a7ff00$d115c380@ics.uci.edu>
Subject: Re: Version issues
-----Original Message-----
From: Chris Kaler [mailto:ckaler@microsoft.com]
Sent: Thursday, February 18, 1999 8:59 AM
To: 'jamsden@us.ibm.com'; Bruce Cragun
Cc: gclemm@atria.com; ejw@ics.uci.edu; dgd@cs.bu.edu;
Cragun.Bruce@gw.novell.com; sridhar.iyengar@mv.unisys.com;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues
So I guess I object to having to pull the entire RSR (which could get
large), just to change the default revision of a single resource, even in
Level 2. It is inefficient and has scaling problems. I don't think it is
unreasonable to have a "helper" method for this.
If we agree on that (which I don't think we do), then Level 1 is easy,
because servers only need to implement the help and a "default workspace" is
assumed. When they become Level 2 servers, there is a natural path.
I don't think we can force workspaces onto Level 1 servers -- Bruce's
comments about it not being necessary are true. If I want to have a DMS
which versions automatically but, by default, only allows me to get the tip
version, then all this stuff is overhead to me and I don't want to build it.
For systems like this, I use the versioning as a safety mechanism and I will
go to the server to restore older versions.
Chris
-----Original Message-----
From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com]
Sent: Thursday, February 18, 1999 8:01 AM
To: Bruce Cragun
Cc: jamsden@us.ibm.com; gclemm@atria.com; ejw@ics.uci.edu;
dgd@cs.bu.edu; Cragun.Bruce@GW.Novell.com;
sridhar.iyengar@mv.unisys.com; Chris Kaler;
bradley_sergeant@intersolv.com; ABabich@filenet.com
Subject: RE: Version issues
Comments below in <jra> tags.
"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/18/99 10:15:43 AM
To: Jim Amsden/Raleigh/IBM
cc:
Subject: RE: Version issues
Nobody is claiming workspaces are too difficult, and I'm not against
being required to do them. I'm against being required to do them if
they aren't necessary. Every "little" thing we require in Level 1 is
one more deterrent in getting people to support versioning. Still, I
don't want to make too big an issue of this since we have bigger issues
with the standard still to tackle.
<jra>
Something is necessary to resolve a URL to a versioned resource to a
specific revision. Let's just not have two things, one for each level. At
the same time, I would like to avoid special cases that we do for level 1
that appear to be simpler, but don't scale and aren't applicable to level
2.
</jra>
What is my default workspace going to do, though, when I ask for a
versioned resource? I believe you have indicated a preference that the
default workspace give me either a) the checked-out revision, or b) the
latest revision if none are checked out. That would be okay, but why
would I need a workspace to accomplish this? And what if more than one
revision is checked out?
<jra>
You need a workspace because this is only one case that is a reasonable
default. Another is checkedout, R1, and latest. That is get anything I have
checked out, or get a revision labeled R1 for release 1, or get latest if
the versioned resource doesn't have a revision labeled R1. This is an
extremely simple and common case for versioning, and a workspace does it
just fine. There might be other mechanisms that would work too, but they
would probably end up looking a lot like workspaces.
We need to think a little more about having two revisions of the same
versioned resource checked out at the same time. Currently, this would
require separate activities to disambiguate the working resource. Rember,
checkouts in WebDAV aren't extracting a resource to the local file system
where the user can specify a local file name. The resources are checked out
on the web, are accessed using the same URL that was used before they were
checked out (to provide uniform access), and can be accessed by many users
at the same time subject to locks (on the working resource that is). This
is a different paradigm, one that has different capabilities, some better,
some less flexible.
</jra>
You also say workspaces are not about creating sets. I understand the
revision selection rule part of workspaces, but are workspaces 1-to-1
with revisions/versioned resources? I have understood that a workspace
referred to 1..n resources, with a selection rule for each. Looking
back at the definition in the Goals document, I see it doesn't indicate
1..n. Hmmmm.
<jra>
A repository can contain many workspaces, one of which is the default
workspace. Users create and use workspaces to meet their needs. The default
workspace is used if one isn't specified.
A workspace doesn't contain any resources, versioned or otherwise. It isn't
a collection. A workspace does specify a revision selection rule, one rule,
having many entries. Each entry can be one of: "checkedout", the URL of the
current activity, the URL of a merge activity (maybe more than one, not
sure yet), a label, a configuration, or "latest". The URL of an arbitrary
versioned resource is resolved in the context of a workspace to a
particular revision. This is done by searching through the entries in the
revision selection rule in order looking for a match. The first revision
that matches is the one selected. If there is no matching revision, then a
resource not found status is returned.
So a workspace maps or resolves many versioned resources to a single
revision for each versioned resource. There is only one revision selection
rule in a workspace, and it is applied to all versioned resources resolved
in the context of that workspace. That rule may have multiple entries that
specify the matching order.
</jra>
So what, then, is the difference between the workspace and the
selection rule other than the fact that the workspace *contains* a
selection rule?
<jra>
That's all a workspace is, a resource that contains a revision selection
rule. One refers to a workspace with a URL, just like any other resource.
We may want to define a mime type for activities and workspaces. A
workspace is a resource so its extensible. The revision selection rule is
its contents.
</jra>
>>> <jamsden@us.ibm.com> 02/18/99 06:06AM >>>
Bruce,
Unfortunately, its not that simple. If you have multiple revisions,
each
with a label, and you allow either non-versioning clients and/or
versioning
clients to specify URLs without specifying a label, something must
happen.
A revision has to be selected. What I'm trying to avoid is having
different
mechanisms for level 1 and level 2; default revisions, and workspaces.
These two mechanisms conflict if both were implemented in level 2. In
addition, I think default revisions don't scale and would be harder
for
users to use and servers to implement than simple workspaces. Let's try
to
understand what the issues are with workspaces in level 1. Why would
level
1 servers not want to implement them? What would they find too hard?
Workspaces aren't about defining sets of resources, they're about
resolving
URLs referencing a versioned resource to a particular revision. Level
1
servers have to do this somehow. I think workspaces are the simplest
way
for both clients and servers. They also provide some additional
flexibility
for free, and would be consistent across levels. Sounds like a win-win
situation.
"Bruce Cragun" <BCragun.ORM2-1.OREM2@GW.Novell.com> on 02/17/99
07:12:40 PM
To: Jim Amsden/Raleigh/IBM
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.