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. brane_at_wandisco.com
Received on 2014-06-23 11:22:21 CEST