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.
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.
>> (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
of the workflows that create mixed-revision working copies, the notable
exception being not committing from the root of the WC.
And as for merging, I believe we've already agreed that the
single-revision constraint is more arbitrary; it reflects a shortcoming
of our merge algorithm, not a limitation of the data model.
Bottom line, I object to apparently useful hacks that are likely to be
outdated soon, but that we'll still have to maintain indefinitely.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
