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
