On 7/31/06, Karl Fogel <kfogel@google.com> wrote:
> dionisos@tigris.org writes:
> > Modified:
> > trunk/subversion/libsvn_wc/diff.c
> >
> > Log:
> > Fix issue 2583: diff tmp files shouldn't *require* write access to .svn/tmp.
> >
> > Note: There's a better way to fix this: add a flag to svn_wc_translated_file2,
> > but, that can't be backported to 1.4.1, so I'm committing this first.
> > After backport, we can improve the situation.
>
> When you say "add a flag", do you mean add a new bit for the bitmask
> parameter 'apr_uint32_t flags', or do you mean add a whole new parameter?
>
> If the former, I'm not sure what our compatibility policy is on adding
> a new bit, but presumably it should be allowed in at least some
> circumstances -- otherwise what's the point of using a bitmask? :-)
> Specifically, IMHO it should be allowed when the presence of the bit
> causes an *improved* behavior for which the non-improved version
> (i.e., the behavior you get when the bit is simply ignored) is no
> worse than the status quo before the new bit was added.
>
> If the latter, then why not just create svn_wc_translated_file3()?
Both a new public constant or a new API can't be backported to a patch
release. Given that I thought RC4 would be our final RC, I created a
solution which /could/ be backported to a patch release.
Given that we do need an RC5 and the fact that dlr favors the solution
which introduces a new bit flag in the FLAGS parameter, I think we
just need one more backporting vote and we're set.
No, I don't like to add 1000's of boolean parameters to a single
function, revving it for every parameter. I know we didn't document
that unused bits were required to be 0 in that function before, but I
feel that's what can be expected from normal API users.
Summary: there was a followup commit to introduce a new bit flag,
which just needs one more vote to be in RC5.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 1 00:17:43 2006