On Thu, Dec 14, 2000 at 01:37:23PM -0600, Karl Fogel wrote:
> Greg Stein <email@example.com> writes:
> > It would seem that I'll need to alter the strategy to create URLs of the
> > form: http://www.lyra.org/repos/$svn/ver/672/foo/bar.c (where 672 is the
> > revision number).
> > Does this seem like the right approach?
> Is it worth having the `ver' prefix in there?
> I alway think of the path as a descending trail, starting from a
> particular number in the version array. In that case
> does just as well, and is a bit more readable (IMHO).
> Also, I can't remember what the $svn is for, but there's a reason for
> it, right?
First off, the URL quoted above is an "internal" URL that the user will
never really see. The "real" resource is:
That resource refers to the "latest" /foo/bar.c in the "/repos" repository
on www.lyra.org. In WebDAV terms, it is called a "version-controlled
resource" (VCR). To the user, they are working with clear, clean URLs. In
fact, those URLs can also be surfed by a web browser :-)
Under the covers, we have some internal URLs to refer to different parts of
the system. These internal URLs are stored in the "$svn" namespace (which
can be changed if some goober doesn't like that name and/or wants to
actually use it for a file/dir).
Under $svn, we have four types of resources (using DeltaV terms):
1) activities, stored in .../$svn/act/
2) version resources, stored in .../$svn/ver/
3) version history resources, stored in .../$svn/his/
4) working resources, stored in .../$svn/wrk/
"Activities" are the DeltaV analogue to FS transactions. We collect a bunch
of changes within an activity, then CHECKIN the activity.
A "version resource" is a resource referring to a specific version of a
resource in the repository. This is our (revision, path) tuple.
[ note that DeltaV uses the "version" term; we use "revision" ]
A "version history resource" refers to the abstract concept of a specific
resource. From the history resource, you can find all the different versions
of that resource. You could view this as a Table of Contents for a logical
resource. I think this resource might be analogous to the node "100" in the
repository; from it, we can track down versions of a resource no matter what
they may have been renamed to, or whether they've been deleted.
[ e.g. if repos/foo/bar.c is deleted, how do you track it down again? you
can certainly keep a version resource URL, but the version history gives
you the entire ancestry tree ]
"Working resources" are temporary resources during the commit process. We
tell the server to check out the version resource corresponding to what we
have on the client. [and this typically fails if it isn't the latest; the
client reports "/foo/bar.c is not up-to-date"] The checkout "creates" a
working resource, where we PUT/PROPPATCH our changes. These working
resources are associated with an activity that we created at the beginning
of the commit process. When the activity is (successfully) checked-in, then
all the working resources will be deleted.
The formats are like so:
(yes, that's a UUID on the end)
[ URL formats subject to change over the next week :-); history resources
may not ever be implemented (we might not need them) ]
Note also that we could eventually do really cool things, such as allowing
somebody to surf to .../$svn/ver/7/ to web-browse the state of repository at
revision 7. The history resource could present a full outline of all the
revisions of a file. etc. SVN V1.0 will *severely* restrict the methods
that are allowed within the $svn area. I'm not about to get into web page
generation for V1 :-)
That is a rough overview. There is some more detail in the repository at
notes/webdav-usage.html, although it needs to be updated/clarified a bit.
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006