Julian Foad wrote on Mon, Mar 14, 2022 at 10:47:57 +0000: > 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.
This implies the wc won't be uniform revision. This might break user expectations; might prevent the user from running «svn merge»; and might get in the way of querying the repository for the wc's history. E.g., even a simple «svn diff -r BASE» on an unmodified wc will show differences, because BASE is resolved to a revision number once at the start, not once per versioned file. One way in which I can see this possibly working is if the user is willing to restructure their tree so all the large files are in one subdirectory that's an immediate child of the wc root, and all other files are in another immediate child directory of the wc root. Then they can use the latter child directory as their cwd and run svn operations normally. The cwd won't be the wc root, but that's manageable. However, requiring a tree restructure would increase the cost to the user of starting to use this feature. Also, at this point they can basically leave the large files in an svn:external wc, and enable pristines-on-demand only for that wc, rather than have one wc with two subdirs. Cheers, Daniel > (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 >
