[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: URL formats, DeltaV resources, etc (was: Re: identifying FS nodes)

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-12-15 02:06:31 CET

Thanks, that clears up a lot!

Greg Stein <gstein@lyra.org> writes:
> On Thu, Dec 14, 2000 at 01:37:23PM -0600, Karl Fogel wrote:
> > Greg Stein <gstein@lyra.org> 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?
> Yup :-)
> > I alway think of the path as a descending trail, starting from a
> > particular number in the version array. In that case
> >
> > http://www.lyra.org/repos/$svn/672/foo/bar.c
> >
> > 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:
> http://www.lyra.org/repos/foo/bar.c
> 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:
> 1) .../$svn/act/e2cb3d1a-d21d-b211-90cc-9d8a0959ebcd
> (yes, that's a UUID on the end)
> 2) .../$svn/ver/7/foo/bar.c
> 3) .../$svn/his/100
> 4) .../$svn/wrk/e2cb3d1a-d21d-b211-90cc-9d8a0959ebcd/7/foo/bar.c
> [ 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.
> Cheers,
> -g
> --
> Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

This is an archived mail posted to the Subversion Dev mailing list.