(FS) operational question

Up to this point, I've been considering a version resource URL to look
something like:

    http://www.lyra.org/repos/$svn/ver/67/somedir/foo.c

However, this means that a commit *anywhere* in the tree will change the
version resource URL for *every* file/dir in the tree. And since these are
server-constructed URLs, the client can't automagically just update the
version URLs stored throughout the client tree. The server would actually
have to tell the client "here is <this> URL, here is <that> URL." For a
large repository, ugh...

I had already identified the "tell the client about a bazillion new version
resource URLs" problem, but hadn't tackled it yet.

Now, I've just been thinking that there might be other, subtle issues with
"creating" a bazillion new version URLs on each checkin. I say "creating"
because they're just mappings into the repository; there is no true state
associated with them, meaning there is no real cost. The cost is all on the
client side, keeping the records up to date.

So... I came up with an idea to fix the URL. How about:

    http://www.lyra.org/repos/$svn/ver/32.7/somedir/foo.c

i.e. use the Node ID in there, rather than the revision number.

This would create very stable URLs, and it would also skip past the whole
"implicitly create a bazillion URLs" issue and the related update problem.

The implications of this, though... I'd need an API in the filesystem to
open the node by an (ID,path) tuple. I'm not sure if this is possible given
the repository structure, but it sounds doable.

The bigger issue that I'm seeing is that (ID,path) is not really a unique
qualifier. That pair could be constant over 1000 revisions. ... oh, damn. It
also means that a given version resource can't report its "version-name"
properly -- the version name is the revision number. If it can be 1000
different revisions, then which does it pick?

Hunh. Has anybody pondered the issue that for a checkin *anywhere* in the
tree, that on the next "svn update", we have to hit *every* "entries" file
in the entire WC to update the revision number stored in there? It won't be
a matter of simply zooming past them doing nothing... we've got to rewrite
every single file.

The alternative, of course, is to leave things at an old revision number
until a real change arrives, but then our state reporting grows and grows as
we get more exceptions throughout the tree (by "exception" I mean a child
needing to report a revision that is different than the parent's).

Well... I'm going to think on the version URL problem some more. It may be
possible to keep them that way, and the client will just interact with the
server through baselines as a way to modelling the global changes. The
point here being that we would no longer spin a new version URL on each
change, but merely a new baseline plus a few new version URLs. I think this
might work out well.

So... back to the original question about the FS. I believe that I'm going
to need a revision number, huh? An ID and path isn't enough to do the work?
Ooh... or could I go ahead and do an "open_root" on the latest rev, then an
"open_node" with an ID/path. If that ID/path does not occur within that rev,
then I get an error. But having the revision at the open_root also means
that I have all the information needed (revision, path, with ID as a bonus).
Will that work?

[ seems like it since an FS transaction will always be operating against the
  latest revision anyways, right? we still demand that the client has the
  latest before making changes(?). ]

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/