Re: svn commit: r20834 - trunk/subversion/libsvn_wc

[Karl Fogel <kf...@google.com>]

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()?

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r20834 - trunk/subversion/libsvn_wc

[Erik Huelsmann <eh...@gmail.com>]

On 7/31/06, Karl Fogel <kf...@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