macOS .DS_Store files preventing the deleting of otherwise empty directories

[Sean McBride <se...@rogue-research.com>]

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

Re: macOS .DS_Store files preventing the deleting of otherwise empty directories

[Sean McBride <se...@rogue-research.com>]

On 29 Apr 2025, at 11:54, Andreas Stieger wrote:

> On 2025-04-29 17:06, Sean McBride wrote:
>>> 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.
>> That would be fine for me too.  Perhaps a new setting in 
>> ~/.subversion/config where one can list file names like .DS_Store 
>> that svn is free to delete.
>
> I do not think that version control is the right place to implement 
> this. This is something for build systems or client-side hooks.

There may be no build system involved. A lot of what we use svn for is 
storing of documents and graphics. Nothing is getting "built".

> Also for your particular fruit you look into one of the plugins for 
> finder that prevents these files to be written in the first place?

I'm not aware of any such plugin, have a link to share?

Anyway, I *do* want .DS_Store files to be created in general.

All I'm arguing for is that when svn deletes files (due to a move) and 
then deletes the resulting "empty" parent folder, that it consider a 
folder as "empty" if it only has .DS_Store.

Sean

Re: macOS .DS_Store files preventing the deleting of otherwise empty directories

[Andreas Stieger <An...@gmx.de>]

On 2025-04-29 17:06, Sean McBride wrote:
>> 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.
> That would be fine for me too.  Perhaps a new setting in ~/.subversion/config where one can list file names like .DS_Store that svn is free to delete.

I do not think that version control is the right place to implement 
this. This is something for build systems or client-side hooks. Also for 
your particular fruit you look into one of the plugins for finder that 
prevents these files to be written in the first place?

Andreas

Re: macOS .DS_Store files preventing the deleting of otherwise empty directories

[Sean McBride <se...@rogue-research.com>]

> Thanks for writing!

Thanks for your reply.

> ...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.

That would be fine for me too.  Perhaps a new setting in ~/.subversion/config where one can list file names like .DS_Store that svn is free to delete.

> 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.

Ah, I see. :(

Sean

Re: macOS .DS_Store files preventing the deleting of otherwise empty directories

[Nathan Hartman <ha...@gmail.com>]

On Thu, Apr 24, 2025 at 1:04 PM Sean McBride <se...@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