Greg Stein <gstein@lyra.org> writes:
> 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 don't think the version resource has to change for everything else
in the tree. If foo.c has not changed from 67 to 72, then
http://www.lyra.org/repos/$svn/ver/67/somedir/foo.c
http://www.lyra.org/repos/$svn/ver/72/somedir/foo.c
are the same entity. You can continue using 67 -- the number may not
be "highest", but as far as foo.c is concerned it's still effectively
"latest".
> 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.
IMHO, under no circumstances should internal node and node-revision
numbers become visible to outside layers. If they're part of a URL,
we've done something wrong. :-)
The way to identify a revision uniquely is rev:path, URLified as
desired, of course. (Yes, revN:path and revM:path might be the same
even though N != M, but that doesn't actually hurt us anywhere.)
> 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?
Can you think of a scenario where this is actually a problem? It's
true that you might get 1000 different revisions to choose from, but
that just means any of the choices will do.
If you need a default, go with the highest rev. (But I don't see why
it matters?)
> 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.
Nah -- you described the real solution below, actually. :-)
> 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).
That's been the plan, yup, but it's not such an awful price to pay, is
it? And it's not so simple to avoid -- in general, we can't
automatically tweak the revision numbers for unaffected files, because
for all we know they *might* have changed in the repository. Suppose
bar.c and foo.c are siblings in dir D:
1. If we commit bar.c and get a new rev in return, we cannot assume
that foo.c also moves to that rev, because we haven't updated
foo.c.
2. Likewies, if we update bar.c individually, we still can't change
foo.c's rev, because we haven't updated foo.c itself. Maybe it
has changed in the repository and we just don't know it.
3. If we update the whole dir D, of course, then both foo.c and
bar.c will move to the latest available revision, along with
everything else.
> 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?
Not sure I understand the question/problem... (?)
Sorry for being dense. Could you describe it untersely?
> [ 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(?). ]
Right; if client is trying to commit a change against a non-latest
entity, it just receives an out-of-date error.
(English question: why are "up to date" and "out of date" opposites?
What if I said "down from date" or "in date", and why the habitual
dropping of the conjunctive preposition in the latter? Sheesh.)
Received on Sat Oct 21 14:36:18 2006