Lorenz wrote on Mon, Jan 31, 2022 at 07:13:46 +0000:
> Karl Fogel wrote:
> >Hi, everyone. I'd like feedback an idea that I've had for some
> >years now but never written up before.
> >
> >Subversion can already be used to manage large (usually binary)
> >files. In fact, we use SVN for this at my company and it works
> >decently. However, there are two possible features that would
> >make Subversion go beyond "decent" all the way to "quite good" at
> >this :-). They are:
> >
> >1) Make pristine text-base files optional. [...]
>
> I'm following the optional pristines debate for a while now. but can't
> remember a properies based configuration having been discussed.
>
> So here is what I would like to see:
>
*Why* would you like to see a properties-based design? Could you please
describe the use-case, constraints, business needs, etc., you're
designing for? We shouldn't be discussing concrete solutions/designs
until we have a common understanding of what use-case they are designed
to solve.
What does this design achieve or enable that other proposals do not?
As you may have seen elsethread, Julian has already begun to implement
a single per-WC toggle design (as a first iteration of the new
functionality). If you see any conflict between that work and your
use-case, please say so sooner rather than later: it's easier to pivot
before work has been done than after.
> 1) a inheritable svn:pristine (on, off, on-demand) property on files
> and folders.
> On folders that could be extended to handle thresholds (size, age).
For files, this could make sense. "This file will not need to be diffed
by most users" does sound like information the user might have that we
can't determine otherwise. Perhaps it's a generated file (that gets put
in veresion control for whatever reason; e.g., our dist/ repository, and
the Apache CMS websites/ tree). Perhaps it's a file that only one or
two users will be modifying.
For folders, however, I don't see how this makes sense. Size and age
thresholds are not an intrinsic property of an inode in the versioned
filesystem; they are time-space trade-offs that each client makes.
Different clients could make different trade-offs, and clients that
checkout today's HEAD in the future (using the «svn checkout $URL@$peg»
syntax) might have different needs than clients that checkout today's
HEAD today.
>
What do you think of using an r0 revision property for storing
information about what files typically don't need their pristines?
This could get interesting if some of the files involved are protected
by "no access" authz.
> 2) a inheritibe svn:pristine-wc property for local override. This
> property would WC-only, not to be stored in the repository.
>
There is such a thing as WC-only (see SVN_PROP_WC_PREFIX and
svn_prop_wc_kind). The existing ones are deliberately not shown in the
UI. IIRC, they were used as the precursor of today's NODES.dav_cache
column, as a place where the RA layer can store per-file information.
In any case, properties are for attributes of the versioned filesystem's
inodes. They are not for local configuration. It wouldn't make sense
for «svn diff» to show both changes to, say, a file's encoding (in
svn:mime-type) and to a file's pristinefulness, because those are
different kinds-of-things: one describes the versioned inode, like its
charset (which can be stored in svn:mime-type), and another is
a property of the user's working copy [literally] of that versioned
inode, like its depth.
If it's not committable, it shouldn't be shown by «svn diff».
> 3) optional but not neccessary a command line option for svn checkout
> to set svn-pristine-wc to off.
> Optional because one can always restricting the initial checkout
> depth, setting the propery, then update.
>
> 4) for workstation global settings an entry in the config
> corresponding to the svn:pristine-wc would be needed.
If there's a "typical" configuration that many clients will want to use,
having some way for the server to advise them about it would make sense,
as would letting clients decide whether or not to honour the advice
(both by default and _ad hoc_ for a particular working copy).
Furthermore, whenever we have some sort of server-recommended
configuration, having some syntax to show where the wc differs from the
recommendation will make sense. For instance, for depth I do
.
svn info -R | grep-dctrl -F Depth '' -s Path,Depth
.
to print all local files that have a depth other than the default — but
having some syntactic sugar (e.g., a tools/ script) to do this query
would make sense. This goes not only for server-recommended depth
configuration but also for server-recommended pristinefulness
configuration, if we have that.
Looking forward to hearing about your use-case.
Cheers,
Daniel
