On Thu, Apr 24, 2025 at 1:04 PM Sean McBride <s...@rogue-research.com> wrote:
> Hello, > > Long-time svn user, first time poster here... > > It often happens to my coworkers (let's say Alice) that they'll get a > local conflict when some other user (Bob) commits a move of a directory. > Let's say Bob moves /foo/bar to /baz/hello. > > If Alice has some new uncommitted file in her local /bar, then of course > svn doesn't delete that file and thus /bar is not empty and thus /bar isn't > deleted either. This is generally desired. *But* if the new uncommitted > file is merely a macOS .DS_Store [1] file, then I'd much rather svn delete > the .DS_Store, as those files are not valuable. Having .DS_Store in the > ignore list does not help. > > Have the devs ever considered special-casing this? i.e. when svn checks > that a folder is "empty", consider having only a .DS_Store file as being > empty. > > Thanks, > > Sean > > [1] https://en.wikipedia.org/wiki/.DS_Store > Hi Sean, Thanks for writing! This is an interesting question. It took a while to research this! * I did not find any relevant issues in the issue tracker. * The mailing list archives (both dev@ and users@) contain 236 instances of the text "DS_Store" but many of these are quoted text in replies-to-replies, and all of them pertain to ignoring files in the ordinary sense: - the svn:ignore and svn:global-ignores properties - in the default runtime configuration area (e.g., ~/.subversion/config in the user's home directory, or the systemwide equivalent in /etc/subversion/config), an example default global-ignores was added in a comment; ".DS_Store" is one of the suggested ignore patterns. * The source code contains only one reference to .DS_Store, in subversion/include/svn_config.h. This is where the above config hint is coded. (Actually, there's a second reference, in a perl script called svn_load_dirs.pl under contrib/. The contrib/ subdirectory is not included in Subversion releases, so I didn't study this one further.) I suppose we could file a feature request, but first we'd have to articulate exactly what it should be and how it should work. Specifically, we can't just delete files (not even "obvious" ones like .DS_Store). It is a design principle of Subversion not to try to decide for the user which files are important to them and which aren't. We don't even set a default ignore pattern, even though we do provide a suggested pattern as a commented-out hint in the config file. Users still have to explicitly uncomment it if they want to use it. In other words, hard-coding "just delete .DS_Store files" as an exception to the normal rules probably won't gain much support. However: If the feature request is for providing users a way to explicitly *request* such automatic deletion, with an appropriate design to make it safe, and it's opt-in, that might be acceptable. There's one (kinda BIG) caveat: supposing there's a discussion and a design and consensus that this feature request is a good idea, we'd still need one or more volunteers to develop the feature and champion it through to a release. Being a volunteer-driven project, that is usually the biggest challenge around here. Cheers, Nathan
