Mark Phippard wrote: > Is there a way to describe it in a way that a really experienced SVN > "user" not "developer" would understand? Set aside the pristinelsss WC > feature. What is the scenario in previous versions of SVN where this > behavior is kicking in?
Hi, Mark. I have been mainly aiming my writing to those taking a detailed look and reviewing the code, while at the same time I don't want to leave anyone here, even on the periphery of the development community, in the dark. I'll give it one more shot in this subthread. The current approach adds a "textbase sync" phase before every operation, which is crudely, pessimistically, fetches pristines for all locally modified files within the tree scope of the operation's target paths, if they are (knowingly) absent from the pristine store. This approach then uses invokes the old business logic of the operation, with little modifications inside it, in particular no callback to fetch pristines on demand after this point. The "restore missing files" is an odd thing that "update" does outside of its core purpose: when any versioned file in its scope is missing from disk, it puts an unmodified copy of the file back on disk there, by copying (and translating keywords/eol-style) from its pristine version. It's something like an implicit revert for files that were deleted from disk without using "svn delete". Why so, I don't know, and I don't like it, but it's there, so let's go on to look at how it interacts with absent pristines. If we have pristines absent on purpose (as we do in this branch), and we simply disable the "textbase sync" a.k.a. "hydration" that runs at the start of an update in our current approach, then that "restore" part of the update errors out (unable to read the pristine) when it encounters a file missing on disk. It's probably a rare case in most users' work flows but it's something that exists we have to deal with one way or another, even if by declaring it no longer supported and changing test expectations accordingly. Stick with the idea, for now, that we do need to handle that "restore" part of update. The alternative approach is to add a callback to the lower level "get the pristine" function that it uses. Then it would be able to fetch what it needs when it needs it and not fetch anything it doesn't need. Evgeny cautions us about that alternative approach, but *in principle* if we could get the protocol level behaviour absolutely right, that would (I think) surely be better. That "restore" happens, within update, before the server tells us whether any update of that particular file is actually present on the repository. (Perhaps it could be moved to afterwards; I haven't investigated that possibility.) Then, never mind whether we care about supporting that "restore" thing; because next a similar pattern applies to the "normal" part of the update (everything it does after "restore"). Obviously we need the normal part of update > [...] From my laymans point of view, we have a database in > the WC that says what we have. I assumed we largely would be using > that information when talking to the server about what it needs to > send us to do an update. Well, yes and no in the current two-phase (hydration, then operation) approach. > So I am just not getting why the server needs > to send us a file that WC already has. It doesn't ever send us a file that the WC already has. The issue we're concerned about is it sending a pristine that is (knowingly) absent from the pristine store, but for a file whose pristine is not going to be looked at during the current update. It might be needed by some future operation but the current approach fetched it pre-emptively (by design) but for this use case we would rather not do that. > I know your answer will be the "restore situation" [...] That's not the essential part, no; the main part of "update" is obviously the essential part, and it has similar characteristics and options, and isn't optional. - Julian
