Bert Huijben wrote on Tue, Apr 26, 2011 at 19:10:04 +0200: > > > > -----Original Message----- > > From: Greg Stein [mailto:gst...@gmail.com] > > Sent: dinsdag 26 april 2011 17:31 > > To: Hyrum K Wright > > Cc: dev@subversion.apache.org; Bert Huijben > > Subject: Re: svn commit: r1096619 - in > > /subversion/trunk/subversion/libsvn_wc: translate.c translate.h > > workqueue.c > > > > I'm also fine with your approach. If/when perf problems are actually > > found, then we can analyze the fix. Additional flags or functions, > > *with a clear reason for their existence*, would be a fine solution in > > my mind. I see the problem (before your changes) as having N functions > > without any true clarity for why they exist. Deviating from your One > > True Function with clear explanation should avoid going back to that > > state. > > The original code allowed users to version their ~/bin/ while explicitly not > setting svn:executable on their scripts. > > When they applied local changes and then committed their files (for backup) > the +x bit would just stay enabled. > > But when they received an update from the repository (needs review?), the > executable bit would be reset. > > > I expect that since our recent change we disable the execute bit on our > commit, because we just set the flags regardless of changes. > > > I kind of liked that old behavior... But I'm not sure if it is a breaking > change. >
You're describing a two-fold behaviour: * Committing a +x(ACTUAL)/-x(WORKING) file preserves +x * Updating a +x(ACTUAL) file enforces -x The way you describe it, the second is more important to preserve, if we broke the first but not the second it might be okay still? > Bert >
