On Thu, Mar 10, 2022 at 5:59 AM Julian Foad wrote:
>
> Nathan Hartman wrote:
> > Suggestion: The user provides the earliest SVN version with which they
> > want compatibility, and SVN picks the latest WC format version that is
> > compatible with it. [...]
>
> And Daniel Sahlberg wrote:
> >> Regar
Julian Foad wrote on Wed, Mar 16, 2022 at 21:03:28 +:
> Daniel Shahaf wrote:
> >Also, unrelated: have we verified that all the temporary files we create
> >are created in a crash-safe way? I.e., that if libsvn_wc is SIGKILL'd
> >partway through hydrating something, the something will be cleane
Daniel Shahaf wrote:
>Also, unrelated: have we verified that all the temporary files we create
>are created in a crash-safe way? I.e., that if libsvn_wc is SIGKILL'd
>partway through hydrating something, the something will be cleaned up by
>libsvn_wc at some point in the future?
I haven't reviewe
Julian Foad wrote on Wed, Mar 16, 2022 at 20:44:08 +:
> We're free to continue design discussions but I've limited time and
> need to focus. To me it appears we've moved far enough along this path
> of "some of our users want to do X" leading to "let's see how far we
> can implement an alternat
Daniel Shahaf wrote:
>> The request is to break the original design's invariant for this case.
>
> By only hydrating files that have been updated repository-side. How
> will small, modified files that _haven't_ been remotely modified get
> hydrated, then? The logic is the same for small and large
Daniel Shahaf wrote:
>Julian Foad wrote:
>> It might be *absolutely fine* for the real life users [...]
>
>So what are you saying? That we should stop doing design discussions
>and go talk to users? [...]
Sorry if that came across far too harsh. Looking back I see I phrased it as
"What if...?"
Julian Foad wrote on Wed, Mar 16, 2022 at 06:52:48 +:
> Daniel Shahaf wrote:
> >Julian Foad wrote:
> >> exploration was enough to show that an initial release based on the
> >> original approach has possibilities of being improved, incrementally, in
> >> that way, as and when resources permit.
Julian Foad wrote on Wed, Mar 16, 2022 at 19:49:38 +:
> Daniel Shahaf wrote:
> > [...]I suspect I'm still missing something.
>
> I suggest you re-read the issue 4892 use case:
> https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-issue4892/notes/i525/i525-use-case-4892-mi
Julian Foad wrote on Wed, Mar 16, 2022 at 07:03:43 +:
> Daniel Shahaf wrote:
> >This implies the wc won't be uniform revision. This might break user
> >expectations; might [...],
> I'm not sure how your clarification helps us progress. The point is:
>
> It might be *absolutely fine* for the
Daniel Shahaf wrote:
> [...]I suspect I'm still missing something.
I suggest you re-read the issue 4892 use case:
https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-issue4892/notes/i525/i525-use-case-4892-minimal-update.txt
The request is to break the original design's inva
> >> [...] 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
> >
> >Yes, but for the "deltas" part of update we already mostly DTRT, don't we?
> >
> >- If the file is not modified, [...]
> >
Julian Foad wrote on Wed, Mar 16, 2022 at 07:27:49 +:
> Daniel Shahaf wrote:
> >I'll also mention asciinema. It's basically script(1) into a video
> >hosted online. It might be instructive for us to watch an asciinema
> >session of someone trying this branch for the first time. It's about as
Daniel Shahaf wrote:
> [...], ourselves. Is HEAD of the branch good enough that devs
>with use-cases can start to try it in their real use-case wc's? It
>won't be possible to downgrade f32 to f31, but [...]
I think so. Anyone trying it should take a quick look through the known bugs
filed as de
Daniel Shahaf wrote:
>> Stick with the idea, for now, that we do need to handle that "restore"
>> part of update.
>
>Can we deprecate it?
People already argued for keeping it. No need to spend more time discussing
that now, as I pointed out the effort required to make it work this new way
(fetch
Daniel Shahaf wrote:
>This implies the wc won't be uniform revision. This might break user
>expectations; might [...],
I'm not sure how your clarification helps us progress. The point is:
It might be *absolutely fine* for the real life users in their real life
situations, and that's what we nee
15 matches
Mail list logo
