On Mon, Mar 14, 2022 at 11: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. > > 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.
Speaking from the peanut gallery, as I or "my users" probably won't be bothered too much by the occasional "superfluous pristine" (as I said before, I'm more interested in this feature for our build server with 400 working copies -- not particularly for rare huge files, but more for the general overhead of duplicating thousands of files): If I would be a user with several huge binaries in the repo / WC, I imagine I would not be happy with this proposal. The reason is that I have always, forever, only done "svn update the-whole-wc". Updating individual subdirs is micro-managing. I update my entire project (i.e. working copy) daily just to keep up with whatever my 100 colleagues have done since the last time I updated. It's just daily routine: Press Ctrl-T (Update Project) in IntelliJ, and start working. I'm not going to bother thinking about what exactly I need updated, and multi-selecting the 80 subdirs that I might need to keep in sync with the most important stuff. That's just my opinion, or my feeling trying to place myself in the position of such users. I'm not doing any actual work here, so I certainly don't want to stand in the way of consensus / progress, if the current implementation is sufficient for others. -- Johan
