Re: Changing the permission checks in libsvn_subr/io.c

[Daniel Sahlberg]

Den mån 5 feb. 2024 kl 07:38 skrev Branko Čibej :

> On 04.02.2024 00:31, Evgeny Kotkov via dev wrote:
>
> Daniel Sahlberg   
> writes:
>
>
> Index: subversion/libsvn_subr/io.c
> ===
> --- subversion/libsvn_subr/io.c (revision 1915064)
> +++ subversion/libsvn_subr/io.c (working copy)
> @@ -2535,7 +2535,14 @@ svn_io__is_finfo_read_only(svn_boolean_t *read_onl
>apr_uid_t uid;
>apr_gid_t gid;
>
> -  *read_only = FALSE;
> +  *read_only = (access(file_info->fname, W_OK) != 0);
>
> There are a few problems, because this approach adds a I/O syscall (that
> checks access to a file by its name) into a fairly low-level function.
>
> Previously this function was analyzing the file information from the passed-in
> apr_finfo_t structure.  The new version, however, performs an I/O call, and
> that leads to a couple of problems:
>
> 1) Potential performance regression, not limited to just the revert.
>For example, all calls to open_pack_or_rev_file() in libsvn_fs_fs would
>now start to make additional access() calls, thus slowing down the
>repository operations.
>
> 2) This adds an opportunity for a desynchronization/race between the
>information in apr_finfo_t and the result of access(), because access()
>works by a filename.  For example, in a case where a file is recreated
>between the two calls, its result will correspond to a completely
>different file, compared to the one that produced the apr_finfo_t.
>
> Overall, I have a feeling that solving this specific edge-case might not be
> worth introducing these regressions (which look significant, at least to me).
>
>
> I agree. If it's worth solving, it should be done in a way that's specific
> to revert, not here.
>
> -- Brane
>

Thanks for the feedback and sorry for the late reply. I've been swamped
with other tasks lately and have not yet found the time to look at this but
it is for sure on my todo list.

Kind regards,
Daniel

Re: Removing the old move-tracking experiment

[Julian Foad]

Nathan Hartman wrote:

I am okay with this (conceptually [...]).

More specifically, I am okay with removing it from trunk, but may I 
suggest moving it to a branch, e.g., 'svnmover'? [...]


Thank you for your thoughts on this, Nathan.  I went ahead, removing it 
from trunk (r1915902) and making a branch 'move-tracking-3' (r1915903) 
with a BRANCH-README (1915904).  (The previous two branches in that 
series are earlier related work.)


- Julian

--
- Matrix me: @julian:foad.me.uk 
- Follow me: @jul...@fed.foad.me.uk 

Re: Removing the old move-tracking experiment

[Nathan Hartman]

On Mon, Feb 19, 2024 at 8:49 AM Julian Foad  wrote:

> Hello Subversion devs.
>
> I had a thought that, as the move-tracking experimental design I was
> working on a few years ago isn't heading anywhere, we should remove the
> associated code, as it is better to keep a cleaner codebase on trunk and
> releases.
>
> The associated code is almost entirely decoupled from the public
> interfaces.  (There was one undocumented environment-variable: see in
> the patch below.)  Therefore there seems to be no impact from removing
> it.  I did one basic test run ('make svnserveautocheck') at r1915144 and
> all those tests pass.
>
> I am happy to commit this patch if the community agrees.
>
> It looks like this:
>

(snipped the patch)

I am okay with this (conceptually -- I read the patch but didn't dig
deeper).

More specifically, I am okay with removing it from trunk, but may I suggest
moving it to a branch, e.g., 'svnmover'? If someone wishes to continue the
experiment in the future, the branch could be a starting point, or at least
exist as a reference of what has been tried.

Let me know if you like this idea. If so, then after you commit the patch,
I'll be happy to make the branch, reverse-cherrypick it there, and write
the BRANCH-README.

If you don't think it's worth saving, even in a branch, that's okay too.

Cheers,
Nathan

Community Over Code Asia 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2024 are now
open!

We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this year's applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, May 10th, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you to
apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Hangzhou, China in July, 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)