Seems reasonable to me even on the release branches, will let it stew a bit here.
On Wed, Jul 21, 2021 at 8:18 AM Daniel Sahlberg <daniel.l.sahlb...@gmail.com> wrote: > > Hi, > > TortoiseSVN is importing APR and APR-util via an svn:externals definition: > [[[ > https://svn.apache.org/repos/asf/apr/apr/tags/1.6.5 apr > https://svn.apache.org/repos/asf/apr/apr-util/tags/1.6.1 apr-util > ]]] > > The build system creates a few new directories within the apr and apr-util > directories for temporary build files. These clutter svn status and makes it > more difficult to see if there are any real changes. > > I would propose to add a few more folders in svn:ignore. (I have already done > similar modifications in the Subversion repository, see r1891003). > > [[[ > Index: apr > =================================================================== > --- apr (revision 1891700) > +++ apr (working copy) > > Property changes on: apr > ___________________________________________________________________ > Modified: svn:ignore > ## -14,8 +14,16 ## > LibNTR > Debug > DebugNT > +debug_win32 > +debug_win32_static > +debug_x64 > +debug_x64_static > Release > ReleaseNT > +release_win32 > +release_win32_static > +release_x64 > +release_x64_static > *.ncb > *.opt > *.plg > Index: apr-util > =================================================================== > --- apr-util (revision 1891700) > +++ apr-util (working copy) > > Property changes on: apr-util > ___________________________________________________________________ > Modified: svn:ignore > ## -17,7 +17,15 ## > apu-*-config > apu-config.out > Debug > +debug_win32 > +debug_win32_static > +debug_x64 > +debug_x64_static > Release > +release_win32 > +release_win32_static > +release_x64 > +release_x64_static > LibD > LibR > aprutil.opt > ]]] > > An alternative approach would be to ignore debug_* and release_*, this might > help in case there is a future architecture (eg arm). > > (I realise this will be made on /trunk and not affect the tags that > TortoiseSVN is pulling in until there is a new release, but it will be better > in the future). > > Kind regards, > Daniel Sahlberg > -- Eric Covener cove...@gmail.com
