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_at_BASE and foo_at_HEAD part of the same location
segment", i.e., foo_at_BASE and foo_at_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_at_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
Received on 2014-06-25 13:49:22 CEST