On Fri, Dec 29, 2000 at 04:10:21PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
>...
> > 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 client can do the v67 and v72 compare (via URL). Otherwise, you're going
to need server round trips to fetch more data, or to ask the server to do
the comparison for you.
Essentially, you can quickly compare these two URLs and know that a change
has occurred:
http://www.lyra.org/repos/$svn/ver/73.4/foo.c
http://www.lyra.org/repos/$svn/ver/73.5/foo.c
> > > > 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.
Not at all :-)
I want to put the ID into the version resource URL. Before, I was assuming
that the revision number would go in there. But! If I put the revision in
there, then I need to update all those URLs on the client whenever the
server bumps the revision number.
If we do lazy updating on the client, then we get fragmentation. If we want
to update them all, then the server response grows larger.
> 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.
See above :-)
> > 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.
It is because the original premise was that the revision number is embedded
within the *opaque* version resource URL. To get all of those updated, they
must be sent from the server. There is a tradeoff on request size vs
response size as long as that revision number is in there.
To resolve the situation, I asked whether it seemed reasonable to put the ID
into the URL instead. There is a small operational change to the FS API, but
not a lot.
>...
> Is that what your proposed new set_revision() editor function is for?
> Am I finally seeing the light here? :-)
Nah. That is separate. set_revision() was to avoid mixing the semantics of
the ancestor_revision argument. In one case, it represents a derivation; in
another, it is used to set the current revision. It's kind of messy :-)
> (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.)
If you waited for an "out" argument, then you'd need to walk the WC again to
set the revision information.
> 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.
It cannot deduce version resource URLs.
> > 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.
That is an alternative. I'm trying to find out whether the ID/path
alternative is also workable because using the ID is better for other
reasons.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:18 2006