Julian Foad wrote on Mon, Jun 23, 2014 at 09:54:46 +0100:
> 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?
Roughly, yes. Infomally, the bit desired is "is the file I have the
latest one". I'm not sure how precisely to formulate this question in
API terms; perhaps "is foo@BASE and foo@HEAD part of the same location
segment", i.e., foo@BASE and foo@HEAD are the same node-revision and
neither foo nor any of its tree-wise ancestors have been
deleted/added/replaced(/moved) between rBASE and rHEAD.
(In the preceding, read "HEAD" as "HEAD, as of the time the cached bit
was last computed".)
As to the backing storage: we could just compute the "base-version !=
head-version" bit during an online operation and store it in the db.
Alternatively, we could (a) store the repository-wide last-seen youngest
revision number; (b) for each file, store the youngest-known top bound
of its location segment; and compute the "base-version != head-version"
bit on the fly by comparing (a) and (b). I think this second
alternative is what you termed "Next Changed Revision" below. The idea
is to store not just the low end of node@BASE's location segment (Last
Changed Revision) but also the top end (which is Next Changed Revision
minus one).
> (A name such as "out-of-date" or "not-youngest" may be better than "dirty".)
Sure, I didn't mean "dirty" to be the term used in the final implementation
(for one, it's too generic). Perhaps we could use a name that is a positive
rather than a negative, such as "has-been-changed-in-HEAD" or "has-heirs".
(Not "has-successors" because we already use the term "successor" in the
DAG layer, with a different meaning.)
> 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".
>
Yes. I imagine such periodic monitoring would be implemented in
third-party tools, such as GUI clients, IDEs, or desktop environments.
> > (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".
>
> - Julian
