Greg Stein <gstein@lyra.org> writes:
> > 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".
>
> They refer to the same entity, but the additional URLs become available
> after a commit. The updated URL is the "more official" URL to access the
> resource, thus it would be "nice" to use it over the older one.
I don't see why it's preferable, actually. There are several
different names for the same resource; one of those names came into
being more recently than the others. But I don't see that that makes
it any more accurate/useful than the others.
> > IMHO, under no circumstances should internal node and node-revision
> > numbers become visible to outside layers.
>
> That is the "opaque ID string" and it is part of the public FS interface. We
> aren't exposing what it means or its decomposition. Just a blob.
Check. I guess what I was really hoping is that it would never become
visible in a record on the client side; I understand those ID strings
must be worked with by anyone who drives the FS interface.
> I understand that rev:path is the unique method, the issue that I'm
> considering is that 67:foo.c and 72:foo.c can refer to the same underlying
> entity. The correct way to model the URL is to have a correspondence between
> the identification mechanism (the URL) and the entity that you're naming
> (the node in the FS).
>
> [ heck, just one example is knowing that v67 and v72 are the same since they
> have the same version resource URL. ]
You can find out that they're the same by retrieving the ID for each
one and noticing that it's the same, right? :-)
> > > 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?
>
> Actually, I think it will be. Since commits do not involve every file, then
> only a few files would have their state updated each time. And since a
> change *anywhere* in the repository bumps the number, then the numbers just
> zoom upwards. The state in your working copy will get highly fragmented,
> thus creating a large amount of data to report to the server.
Nowwaitaminutehere... :-) I think two separate issues are being
conflated in your description. Global revision bumping in the
repository is unrelated to working copy revision fragmentation.
Yes, every commit results in a new revision in the repository. But
that doesn't increase the "revision fragmentation" of anyone's working
copy, and therefore does not result in larger reports. The number of
the highest revision *in the repository* zooms ever upward, but this
affects clients not a whit, as far as updates go.
> Agreed, but a "svn update" will bring all the revs up to par with each
> other *if* we report all the changes on *each* rev change. If we don't
> report them, then an "svn update" will remain fragmented.
Huh?
I wonder if we're not agreeing here. Yes, "svn update" should update
everyone's revision number to the latest known global rev. I never
meant to say it shouldn't, sorry if I was unclear somewhere.
The server doesn't need to do any extra work for that, though, because
'svn update .' works very roughly like this:
1. Client sends local state report.
2. Client fetches latest rev number L from repository.
3. Client receives update from server, the tree delta between its
local state and tree L.
The update tree sent back by the server includes only data for things
that actually changed, yes... but then the client knows that all the
things *not* mentioned simply haven't changed between current state
and L. Thus, it locally marks those unchanged things as being at
revision L.
In other words, at the end of an update to revision X, everything in
the working copy that was included (explicitly or implicitly) in the
update will be at revision L, possibly plus local changes.
I hadn't thought DAV needed to provide any extra support for this;
libsvn_wc has enough knowledge to do it entirely itself.
Oh. Except getting the new revision number...
Is that what your proposed new set_revision() editor function is for?
Am I finally seeing the light here? :-)
(Actually, I had been thinking we'd do it in the same way commit does,
which is a teeny bit awkward -- basically, an (svn_revnum_t *) is
passed to the get_editor() function, and the editor guarantees that
after close_edit() is called, the memory at that address will have
been set to the new revision number. I'm not sure this is better than
just having a set_revision() function, though.)
In any case, the local updating of everything to the new revision
shouldn't result in any extra network traffic for DAV. The network
only mentions the changed entities and the new revision -- the rest,
the working copy can deduce for itself.
> Presume that I have an ID and a path, extracted from the URL:
>
> http://www.lyra.org/repos/$svn/ver/32.7/somedir/foo.c
>
> I cannot simply open the node using the ID/path pair (it is not unique). The
> revision is required.
>
> However, during a commit, we must operate against the latest revision. Thus,
> when I go to "open" the provided ID/path, I can instead open latest/path and
> validate the ID matches. If not, then we punt the commit (it means the
> client does not have the latest revision).
Or, get the IDs for latest:PATH and for wc_rev:PATH, and compare
those. If they're the same, the client's PATH is up to date.
-K
Received on Sat Oct 21 14:36:18 2006