Karl Fogel wrote on Wed, Jul 28, 2021 at 11:02:21 -0500: > On 28 Jul 2021, Nathan Hartman wrote: > > If you run 'svn up --set-depth=files' on a/b/c, as it works currently > > d/e/f/g will be deleted. (Unless they contain modifications.) So there > > has to be a way to make some depth elements sticky, or, alternatively, > > there has to be a way to do depth arithmetic, e.g.: > > 'svn up --set-depth+=files'
To be clear, that would set the depth to MAX(depth, svn_depth_files), right? I.e., comparable to chmod(1) with a symbolic mode argument, whereas the existing --set-depth syntax is comparable to chmod(1) with a numeric mode argument. > Ah, I didn't realize that --depth=files would prune directories already > checked out. Either we'd have to change that default behavior, or add a new > depth type... Or maybe the answer is just that '--depth=directories' > automatically makes those directories sticky, so that other shallower depths > don't prune them. So svn_depth_directories would be sticky and other depths wouldn't be? Off the cuff, can't say I like this. "Special cases aren't special enough to break the rules." > > The following might be a separate feature request but it might be cool > > if 'svn update --set-depth=...' could support the '--parents' > > argument, at least when setting depth=files. Rationale: a user might > > want to bring in all the files in g (in a/b/c/d/e/f/g) and all of g's > > ancestors, but not g's siblings nor those of its ancestors. (This use > > case comes up often in a project I work on; don't know whether anyone > > else has a need for this use case.) > > > > Food for thought... > > Yup. I'm inclined to start with the simple case (sparse tree of all > directories and only directories), and discuss other fancier things as > separate features later. That sounds like you'll do: 1. Identify a specific use-case 2. Design and implement it 3. Identify other related use-cases, design and implement them I'd rather recommend: A. Identify use-cases B. Design something to address them C. Implement support for at least one of the use-cases from (A) in a way that builds towards implementing (B) > This one would be a good one to discuss, though. > It might be that the '--parents' behavior could be implied in most cases > anyway, and thus wouldn't need an explicit '--parents' flag. Cheers, Daniel
