Mark Phippard wrote: >> Update starts by hydrating. That means it WILL download any missing >> pristines of modified files, regardless whether any newer revision >> will be found. > > Does the possibility exist to optimize this at all? [...]
To understand, we need to recap that this design is based around a simple invariant: whenever a file is seen to be locally modified, at the next convenient opportunity we will download its base; and when seen to be not-modified we will discard its base. It is not a fetch-at-point-of-access design. This design uses a "wrapper" structure, localising the hydration and dehydration steps at the top level of subcommands, outside the command logic, not inside the command logic. It does not know which text bases the command will need, and instead works on the principle that it will fetch all that might be needed. Evgeny and others suggested that localizing the network access to the start of each subcommand was better (for client software and users) than introducing the possibility for network access to be required at arbitrary points inside the command logic. The rationale is that in the design use cases, fetching is acceptably cheap both in network speed and in the availability of sufficient storage space for text bases for the files that are locally modified. Possibilities for optimisation may exist but the kind of optimisation you are aksing about would require a different design, one in which the fetcher knows what is really needed by the current operation, so one where the fetch is pushed down in the logic to nearer the point of access. There is limited scope for it in this design. Personally I would like us to explore the fetch-at-point-of-access design alternative. While introducing one kind of complexity (network access requested at arbitrary points during a command) I feel it would reduce the kind of complexity we're discussing here (unnecessary fetches and consequent attempts at optimisation). But that's not what we're exploring right now. I asked about this in this thread a few weeks ago; you could see there for further discussion. (I tried to dig up a link but having trouble finding myself in the archives.) - Julian
