[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-dev
Subject:    Re: svn commit: r1096619 - in /subversion/trunk/subversion/libsvn_wc: translate.c translate.h
From:       Daniel Shahaf <danielsh () elego ! de>
Date:       2011-04-26 19:09:08
Message-ID: 20110426190908.GC24169 () daniel3 ! local
[Download RAW message or body]

Bert Huijben wrote on Tue, Apr 26, 2011 at 19:10:04 +0200:
> 
> 
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein@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
> 

[prev in list] [next in list] [prev in thread] [next in thread]