On Fri, Jan 21, 2022 at 5:56 AM Karl Fogel <kfo...@red-bean.com> wrote: > > On 20 Jan 2022, Julian Foad wrote: > >The more I think about this, the more I think we are prematurely > >complicating the requirements in this respect. I'm going to > >back-track > >and posit that a simple per-WC switch should suffice for the vast > >majority of cases, and has the benefit of simplicity. (The user > >might > >wish to set this based on the repository location -- local/fast > >versus remote/slow.) > > Personally I'd be very happy to start with this. We can always > improve the client-side UI for the feature more in the future. > > >I will note that I previously misunderstood the current > >'pristines-on-demand' implementation as fetching the pristine > >before a > >diff (for example) and discarding it afterwards. In fact it > >keeps the > >pristine as long as the file in question remains in a locally > >modified > >state, and only discards the pristine when (before or after some > >client > >operation) the file is no longer in a modified state. That is to > >say, it > >fetches pristines less often than I had thought. > > And it only fetches pristine for commands that absolutely need > pristine, I assume? (I think you said earlier that it does not > fetch for 'commit'.) > > I like the trick of keeping the pristine, once fetched, for as > long as the file is locally modified. > > >The only case in which a simple per-WC setting might be > >unsatisfactory > >is the following combination: > > > > - the repository is "slow" (and/or offline working is > > required); > > > > - and, in a single WC: > > - the WC data set is "huge" (relative to local disk space) in > > total; and > > - there is a subset of files on which the user needs to work > >(requiring diffs, etc.) often enough that fetching their > >pristines "on > >demand" is a problem; and > > - that subset of files is not "huge" in total; and > > - that subset of files can be distinguished from the rest by > > metadata. > > > >That is certainly a possible case, but we have no suggestion that > >it is > >at all common. It is not one of the cases driving this > >feature. So I > >think it is not something to design for at this stage. > > Well, that case is almost exactly our use case at my company :-), > except that I think fetching pristines on demand will be fine. > Thus, we can live with a per-WC setting. > > >I'm going to work on getting something more basic (per-WC yes/no) > >closer > >to production-ready and then we can re-assess it. > > Sounds good! > > Best regards, > -Karl
I like where this is going. Thanks to all involved for pushing it forward :-). Just as another data point, at my company we have a slightly different use case where this feature would be great (I think), and where a simple per-WC-yes/no switch would work fine. In this case, we'd probably also want a "system-wide runtime config area default". The use case: we have a couple of build machines for "official full builds" (for test, staging, production, ... different stages) of our major applications. To save time, for most big applications, we keep re-using the large checked-out working copies (update, build, and switch to the next release branch if there is a next release). We also use those same working copies for backporting cherrypick merges to our release branches (it's all part of our release process, supported by build scripts and procedures to do these things). So, currently, our largest build server has 400 such working copies on disk, and they remain there "dormant" until someone updates, builds, cherrypick-merges, commits-a-tag-from-WC, ... Totalling around 450 GB at the moment. Not an absolute killer, but this is a growing number, and our sysadmins would be quite happy to see that number be +/- divided by 2 :-). Besides, these build servers are located in our data centers, "right next to" the SVN server, i.e. having a 1 Gb or 10 Gb connection to the repository. A perfect fit for "I don't need 99.9% of those pristines most of the time, and it's blazingly fast to get them when needed". Ideally, after pristines-on-demand become possible, I'd do the following: - Set a system-wide flag to make pristines-on-demand the default for new WC's. - Run a script to "convert" all existing working copies to pristines-on-demand (setting the per-WC flag). - Run a script to "vacuum-pristines" those converted working copies. - Receive chocolates from our sysadmins (probably not, but I can try). (BTW: a lot of those working copies are similar, so a feature to have a "shared pristine store" would also help, but that's another feature altogether, and perhaps much more difficult to get right -- both features would solve the wasted-disk-storage problem here, so I'm happy either way) Kind regards, -- Johan
