Branko Čibej wrote on Mon, Jun 23, 2014 at 11:21:49 +0200:
> On 23.06.2014 10:54, Julian Foad wrote:
> > Daniel Shahaf wrote:
> >
> >> One of my colleagues ran bisect but forgot to update back to HEAD after
> >> finishing it. Another forgot to run 'svn up' in the morning before starting
> >> to edit a file, and later got conflicts
> >>
> >> Both of these user errors might have been prevented if their client had
> >> advised them (during the bisect, for Alice; in the morning, for Bob) that
> >> their working copy's BASE tree differs from HEAD. (That is, that 'svn st
> >> -u' and 'svn diff --summarize -r HEAD' were non-empty.)
> >>
> >> Does this sound useful? Would library changes be needed to allow such
> >> functionality to be developed?
> >>
> >> I think the library changes will be straightforward: we would just need
> >> to have a "dirty" bit, clear it upon update-to-HEAD, and set it upon
> >> backdate and upon "Has HEAD changed?" checks initiated by the
> >> libsvn_client consumer.
> > The proposed library functionality is, roughly, caching of "base-version != head-version", for each WC path or rather each repos path represented in the WC? (A name such as "out-of-date" or "not-youngest" may be better than "dirty".)
> >
> > That sounds potentially reasonable.
> >
> > With just a simple query, it would be enough to solve "Alice"'s problem (forgot to update back to head after bisecting).
> >
> > It would not by itself solve "Bob"'s problem (forgot to run 'svn up' in the morning). For that, you would need periodic monitoring for new changes in the repo, which is comparable to running "svn up" or "svn st -u".
> >
> >> Clients (e.g., $EDITOR plugins) could then be configured to request that
> >> check periodically --- say, once per N hours per working copy. Perhaps
> >> an editor-agnostic daemon that monitors *all* working copies in one's
> >> homedir could be developed, too.
> > Yes, I suppose this would be useful.
>
> And I have to point out that we already provide all the tools and APIs
> that such plugins and/or daemons need.
>
Sure, if $EDITOR is online when you open a file, it could run 'status -u
$file' in the background. A plugin could even run 'status -u' in the
background every so often to build its private cache of files that are
out of date.
Nevertheless, if operations such as 'update' could obtain and store
this information at very little cost, and if it would be generally
useful, it might make sense for libsvn to compute, store, and API
that information. Part of my goal in this thread has been to try
and assess whether that information would indeed be generally useful.
> Not to put too fine a point to it, the fact that you can edit an
> 'out-of-date' file is an intentional part of Subversion's design. As is
> the promise that the client won't go cap-in-hand to the server for every
> little detail.
>
(I've addressed this in my other reply.)
> >> (The "dirty" bit would be, more or less, a cache of "Last Changed Revision"
> >> of ${local_relpath}@HEAD; it'll have to account for deletions, renames, and
> >> replacements, though.)
> > I have thought before of something very similar that may also be useful.
> >
> > In the simple and fairly common case where a user commits a change in a
> > tree where no other commit has been made since the user's last update,
> > this commit always creates a superficially mixed-rev WC that is not
> > really mixed-version -- that is, no versioned paths have any changes in
> > the repo between the oldest and newest recorded base revisions.
> >
> > If we cache the "Next Changed Revision" -- that is, the next revision after Base in which the path was changed in the repo (or the fact that there are no changes between Base and a given younger revision) -- then we can determine when a superficially mixed-rev WC is in fact pointing at the same version of each object.
> >
> > The check for "can't merge into a mixed-rev WC", for example, could be relaxed to "can't merge into a mixed-version WC, but you can merge into a superficially mixed-rev WC".
>
> It would IMO be a /lot/ better to extend the protocol so that the final
> response to a commit contains the list of directories for which an 'svn
> update' to the committed revision is a no-op. That would eliminate most
That sounds like a useful enhancement.
> Bottom line, I object to apparently useful hacks that are likely to be
> outdated soon, but that we'll still have to maintain indefinitely.
I don't see how caching the top end of the location segment is a "hack".
It seems like a datum that could be generally useful. In any case, if
it's a concern, we could make it a private implementation detail, or
even an "optional API" (such as an svn_client_info_t member that is not
guaranteed to be filled in).
Received on 2014-06-25 13:54:44 CEST