Bert Huijben wrote on Tue, Apr 26, 2011 at 19:10:04 +0200:
>
>
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein_at_gmail.com]
> > Sent: dinsdag 26 april 2011 17:31
> > To: Hyrum K Wright
> > Cc: dev_at_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
>
Received on 2011-04-26 21:09:58 CEST