Hi -- I've just absorbed all of this thread that was new since the
last time I read it (that's a lot! :-) ).
I agree with Julian's judgement that we should just ship the MVP
version of our issue #525 solution with 'svn update' fetching
pristines for locally-modified files.
While it's not ideal, it's also not a showstopper, and I don't
think it's worth increasing time-to-ship for this feature over
this relatively minor point.
1) It's "just" a performance issue, not a correctness issue.
2) It can be improved in the future.
3) For users who would be bitten by it, there are several easy
workarounds available: target one's updates to avoid
stimulating the
fetch-pristine behavior; or, copy a file locally before
operating on
it; or, sequence one's work so as to only have one modified
file
around at a given time.
The 525-enabled Subversion will still be a huge win, even with
this small blemish.
Many thanks to Evgeny for pointing out the complexities, likewise
to Julian for his very patient explanations and re-explanations.
And I'd like to personally thank Mark for fighting the good fight
:-). It sounds like we have consensus that this is an
implementation-driven behavior not a usage-driven behavior, so
if/when one day we go to fix it at least we'll already have
agreement on that as a goal.
Best regards,
-Karl
On 14 Mar 2022, Julian Foad wrote:
Dear dev community, and especially Karl and Mark:
A plea to test the current design/implementation.
I wonder if we are missing some perspective.
We are worried that the current design won't be acceptable
because it
has poor behaviour in a particular use case.
The use case involved running "svn update" at the root of the
WC. (It
didn't explicitly say that. More precisely, it implied the update
target
tree contains the huge locally modified file.)
Using this new feature necessarily requires some adjustments to
user
expectations and work flow.
What if we ask the user to limit their "svn update" to target the
particular files/paths that they need to update, keeping their
huge
locally modified file out of its scope? Examples:
svn update readme.txt
svn update small-docs/
# BUT NOT: svn update the-whole-wc/
Then we side-step the issue. It only fetches pristines for
modified
files that are within the tree scope of the specified
targets. (This is
how it works already, not a proposal.)
OK that's not optimal but it might be sufficient.
(Of course there are further concerns, such as what happens if
the user
starts an update at the WC root, then cancels it as it's taking
too
long: can we gracefully recover? Fine, we can look at those
concerns.)
I can go ahead with further work on changing the design if
required, but
I am concerned that might not be the best use of resources. Also
I don't
know how to evaluate the balance of Evgeny's concerns about
protocol
level complexity of the alternative design, against the concerns
about
the present design. In other words pursuing that alternative
seems
riskier, while accepting the known down-sides of the current
design is
sub-optimal but seems less risky.
Should we first test the current design and see if we can work
with it,
before going full steam ahead into changing the design?
The current design/implementation (on branch
'pristines-on-demand-on-mwf') is in a working state. There are
open
issues that still need to be resolved, but it's complete enough
to be
ready for this level of testing.
- Julian
On 14 Mar 2022, Mark Phippard wrote:
On Mon, Mar 14, 2022 at 6:48 AM Julian Foad
<julianf...@apache.org> wrote:
Dear dev community, and especially Karl and Mark:
A plea to test the current design/implementation.
I wonder if we are missing some perspective.
Hi Julian,
I do not believe I can offer much in the way of testing, but I do
want
to reiterate that I am not objecting to the current state of the
change. At least not in the veto sense.
My work has taken me away from SVN. I just wanted to bring some
user
perspective into the conversation. I realize there may be
considerations that make it not the best option to try to solve
this.
I will have to leave that up to you ... and Karl if he has helped
fund
this effort.
Karl did a great job explaining why the current behavior will be
unexpected to the user. I agree they may have workarounds they
can use
to manage it. How a user feels about those workarounds is hard to
predict.
Good luck
Mark
On 14 Mar 2022, Julian Foad wrote:
Mark Phippard wrote:
[...] I just wanted to bring some user perspective [...]
Thanks, Mark. Understood.
I also want to clarify that this is my pragmatic side
speaking. For
anyone who doesn't remember me saying this before, I'll repeat
that my
purist side would love to see us do the alternative, optimal,
design,
and work through the consequent protocol issues. That seems
obviously
to me more "Right", but is only useful if we could afford to
follow it
through to completion, and we don't have a good estimate of the
effort
required for that.
- Julian
- Julian
On 15 Mar 2022, Julian Foad wrote:
Just an addendum, perhaps a more positive portrayal of the brief
exploration of the alternative design approach: my assessment is
that
exploration was enough to show that an initial release based on
the
original approach has possibilities of being improved,
incrementally, in
that way, as and when resources permit.
In other words I am not recommending choosing one approach and
abandoning the other, but starting with one and postponing the
other as
possible future improvement work.
- Julian
On 11 Mar 2022, Julian Foad wrote:
Thank you, Evgeny. That is exactly the kind of discussion we
need, and
you were able to provide far more detailed insights than I
was. That
should help us decide how to proceed.
As for your thoughts about the current approach for MVP, I tend
to agree
that your approach is likely to be useful for a lot of people's
use
cases. Unfortunately it has turned out that Karl has one of the
use
cases that doesn't match those assumptions, where it doesn't work
so well.
Karl, would it make sense now for you to search and compare use
cases
that concern your group, and see if cases that don't work well
with the
current design (such as the particular case we are focusing on
right
now, r1898846 'notes/i525/i525-use-case-4892-minimal-update.txt')
are of
majority or minority concern overall?
One thing we could do is to more formally document use cases in
order
for potential users to spot which ones match their cases.
One thing we could do is release (preview) versions of both
approaches and
get folks to evaluate them.
We need to decide how to spend the next effort here.
- Julian
