Re: "BASE != HEAD" notifications

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.

> (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
Received on 2014-06-23 10:55:19 CEST