Question about svn:auto-props pattern matching precedence
To whom it may concern,
The SVN Book version 1.8 states, that if at a given path, *svn:auto-props*
contains two or more file patterns that can match the same file, and such a
file is added, then "there is no way to know" which pattern will be applied
(and therefore, which pattern's corresponding properties the file will gain
upon addition). The example gives patterns "**.c**" and "**.cpp*".
In testing with SVN 1.12 (CollabNet build), I've found that the first
pattern will always take precedence. Is this indeed reliable (i.e., will
the first match always take precedence over others, if the other matching
patterns are all found in the same path's *svn:auto-props*), or have I just
been lucky (i.e., to see consistency)?
And a followup question - if indeed there is no way to reliably control the
pattern precedence, then does this mean that there is no way to, e.g., have
one set of properties apply to "*CMakeLists.txt*" , and another to all
other "**.txt*" files? Bash globbing syntax would allow *!(CMakeLists).txt*
to match all **.txt *files EXCEPT *CMakeLists.txt*, but I believe these
more advanced globbing pattern elements (*!()*, *{}*, and the like) do not
apply to *svn:auto-props*, correct?
Thank you in advance,
Eugeny Sosnovsky
RE: Subversion 1.14.1 and serf 1.3.9
I tried once again, now with svn.exe built from 1.14.1 sources. With OPENSSL 1.1.1l. It seems that it crashes somewhere in zlib. Logs attached. Tomek L From: Daniel Sahlberg Sent: Wednesday, October 20, 2021 3:21 PM To: Tomasz Lubinski Cc: Subversion Subject: Re: Subversion 1.14.1 and serf 1.3.9 Den ons 20 okt. 2021 13:49Tomasz Lubinski mailto:t.lubin...@verocel.pl> > skrev: I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with segmentation fault. Now I receive message: Error running context: The server unexpectedly closed the connection. OK. It is obviously a fault if OpenSSL triggers a segfault if it looses the connection to the server, but just loosing the connection is bad in itself. Do you get any error messages in the server log? What is the server version (and possibly platform/distribution)? Is there any chance that a firewall (either hardware or software) is blocking the connection? Kind regards Daniel Tomek L From: Daniel Sahlberg mailto:daniel.l.sahlb...@gmail.com> > Sent: Wednesday, October 20, 2021 12:03 PM To: Tomasz Lubinski mailto:t.lubin...@verocel.pl> > Cc: Subversion mailto:users@subversion.apache.org> > Subject: Re: Subversion 1.14.1 and serf 1.3.9 Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski mailto:t.lubin...@verocel.pl> >: Yes problem occurs only with correct user/password (self-signed SSL certificate used). In case of incorrect user/password or repository name, it ends with correct error message without segmentation fault. The problem is when I’m trying to open RA session using svn_client_open_ra_session. I’m using my build. Any chance you can verify if it is a problem only when using OpenSSL 3 (ie did you try it with OpenSSL 1.1.1)? Kind regards, Daniel svn-crash-log20211021075056.dmp Description: Binary data svn-crash-log20211021075056.log Description: Binary data
Re: Question about svn:auto-props pattern matching precedence
Den tors 21 okt. 2021 kl 09:31 skrev Eugeny Sosnovsky <
eugeny.sosnov...@silverfirsoftware.com>:
> To whom it may concern,
> The SVN Book version 1.8 states, that if at a given path, *svn:auto-props*
> contains two or more file patterns that can match the same file, and such a
> file is added, then "there is no way to know" which pattern will be applied
> (and therefore, which pattern's corresponding properties the file will gain
> upon addition). The example gives patterns "**.c**" and "**.cpp*".
>
I would interpret "no way to know" as "there is no guarantee" regarding the
current or any future implementation.
In testing with SVN 1.12 (CollabNet build), I've found that the first
> pattern will always take precedence. Is this indeed reliable (i.e., will
> the first match always take precedence over others, if the other matching
> patterns are all found in the same path's *svn:auto-props*), or have I
> just been lucky (i.e., to see consistency)?
>
There is no randomness in the code so you can probably expect it to perform
consistently within a certain version of the program (given the same
parameters), but no explicit guarantee. Any other version or any other set
of parameters might yield different results.
And a followup question - if indeed there is no way to reliably control the
> pattern precedence, then does this mean that there is no way to, e.g., have
> one set of properties apply to "*CMakeLists.txt*" , and another to all
> other "**.txt*" files? Bash globbing syntax would allow
> *!(CMakeLists).txt* to match all **.txt *files EXCEPT *CMakeLists.txt*,
> but I believe these more advanced globbing pattern elements (*!()*, *{}*,
> and the like) do not apply to *svn:auto-props*, correct?
>
There is some part of the glob syntax that allows for negated character
classes. I was looking for it (see [1] and followup messages) and in my
case it was too difficult to make a suitable glob but it might be possible
in your case.
Kind regards
Daniel
[1]
http://mail-archives.apache.org/mod_mbox/subversion-users/202006.mbox/%3c9116ee39-1f64-5d75-8a5a-3bcf35542...@apache.org%3e
Re: Subversion 1.14.1 and serf 1.3.9
Den tors 21 okt. 2021 kl 07:58 skrev Tomasz Lubinski : > I tried once again, now with svn.exe built from 1.14.1 sources. With > OPENSSL 1.1.1l. It seems that it crashes somewhere in zlib. > > Logs attached. > Can you check the server logs and firewalls as I asked in the other mail? I think we have seen crashes in zlib if zlib gets incomplete data. Which would indicate that either the server is crashing or that a firewall cuts of the connection. Kind regards Daniel (PS. Please put your post below the text you are replying to, it makes it a bit easier to follow the discussion compared to top-posting). > > > Tomek L > > > > *From:* Daniel Sahlberg > *Sent:* Wednesday, October 20, 2021 3:21 PM > *To:* Tomasz Lubinski > *Cc:* Subversion > *Subject:* Re: Subversion 1.14.1 and serf 1.3.9 > > > > Den ons 20 okt. 2021 13:49Tomasz Lubinski skrev: > > I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with > segmentation fault. Now I receive message: > > Error running context: The server unexpectedly closed the connection. > > > > OK. It is obviously a fault if OpenSSL triggers a segfault if it looses > the connection to the server, but just loosing the connection is bad in > itself. > > > > Do you get any error messages in the server log? What is the server > version (and possibly platform/distribution)? > > > > Is there any chance that a firewall (either hardware or software) is > blocking the connection? > > > > Kind regards > > Daniel > > > > > > > > Tomek L > > > > *From:* Daniel Sahlberg > *Sent:* Wednesday, October 20, 2021 12:03 PM > *To:* Tomasz Lubinski > *Cc:* Subversion > *Subject:* Re: Subversion 1.14.1 and serf 1.3.9 > > > > Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski >: > > Yes problem occurs only with correct user/password (self-signed SSL > certificate used). In case of incorrect user/password or repository name, > it ends with correct error message without segmentation fault. > > The problem is when I’m trying to open RA session using > svn_client_open_ra_session. > > I’m using my build. > > > > Any chance you can verify if it is a problem only when using OpenSSL 3 (ie > did you try it with OpenSSL 1.1.1)? > > > > Kind regards, > > Daniel > >
RE: Subversion 1.14.1 and serf 1.3.9
I’m using Virtual SVN, server shows accepted connection with code 200. I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib 1.2.7 (that was used by me some time ago) and it seems that it works OK, now. Very strange problem with assembly code in zlib 1.2.11. Tomek L From: Daniel Sahlberg Sent: Thursday, October 21, 2021 10:36 AM To: Tomasz Lubinski Cc: Subversion Subject: Re: Subversion 1.14.1 and serf 1.3.9 Den tors 21 okt. 2021 kl 07:58 skrev Tomasz Lubinski mailto:t.lubin...@verocel.pl> >: I tried once again, now with svn.exe built from 1.14.1 sources. With OPENSSL 1.1.1l. It seems that it crashes somewhere in zlib. Logs attached. Can you check the server logs and firewalls as I asked in the other mail? I think we have seen crashes in zlib if zlib gets incomplete data. Which would indicate that either the server is crashing or that a firewall cuts of the connection. Kind regards Daniel (PS. Please put your post below the text you are replying to, it makes it a bit easier to follow the discussion compared to top-posting). Tomek L From: Daniel Sahlberg mailto:daniel.l.sahlb...@gmail.com> > Sent: Wednesday, October 20, 2021 3:21 PM To: Tomasz Lubinski mailto:t.lubin...@verocel.pl> > Cc: Subversion mailto:users@subversion.apache.org> > Subject: Re: Subversion 1.14.1 and serf 1.3.9 Den ons 20 okt. 2021 13:49Tomasz Lubinski mailto:t.lubin...@verocel.pl> > skrev: I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with segmentation fault. Now I receive message: Error running context: The server unexpectedly closed the connection. OK. It is obviously a fault if OpenSSL triggers a segfault if it looses the connection to the server, but just loosing the connection is bad in itself. Do you get any error messages in the server log? What is the server version (and possibly platform/distribution)? Is there any chance that a firewall (either hardware or software) is blocking the connection? Kind regards Daniel Tomek L From: Daniel Sahlberg mailto:daniel.l.sahlb...@gmail.com> > Sent: Wednesday, October 20, 2021 12:03 PM To: Tomasz Lubinski mailto:t.lubin...@verocel.pl> > Cc: Subversion mailto:users@subversion.apache.org> > Subject: Re: Subversion 1.14.1 and serf 1.3.9 Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski mailto:t.lubin...@verocel.pl> >: Yes problem occurs only with correct user/password (self-signed SSL certificate used). In case of incorrect user/password or repository name, it ends with correct error message without segmentation fault. The problem is when I’m trying to open RA session using svn_client_open_ra_session. I’m using my build. Any chance you can verify if it is a problem only when using OpenSSL 3 (ie did you try it with OpenSSL 1.1.1)? Kind regards, Daniel
Re: Subversion 1.14.1 and serf 1.3.9
Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski : > I’m using Virtual SVN, server shows accepted connection with code 200. > > > > I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib > 1.2.7 (that was used by me some time ago) and it seems that it works OK, > now. > > Very strange problem with assembly code in zlib 1.2.11. > > > > Tomek L > Thanks for reporting back! That is indeed a very strange problem, even more so since TortoiseSVN seems to use zlib 1.2.11. Maybe you can check the same action using TortoiseSVN? Kind regards, Daniel > > *From:* Daniel Sahlberg > *Sent:* Thursday, October 21, 2021 10:36 AM > *To:* Tomasz Lubinski > *Cc:* Subversion > *Subject:* Re: Subversion 1.14.1 and serf 1.3.9 > > > > Den tors 21 okt. 2021 kl 07:58 skrev Tomasz Lubinski < > t.lubin...@verocel.pl>: > > I tried once again, now with svn.exe built from 1.14.1 sources. With > OPENSSL 1.1.1l. It seems that it crashes somewhere in zlib. > > Logs attached. > > > > Can you check the server logs and firewalls as I asked in the other mail? > > > > I think we have seen crashes in zlib if zlib gets incomplete data. Which > would indicate that either the server is crashing or that a firewall cuts > of the connection. > > > > Kind regards > > Daniel > > > > (PS. Please put your post below the text you are replying to, it makes it > a bit easier to follow the discussion compared to top-posting). > > > > > > > > Tomek L > > > > *From:* Daniel Sahlberg > *Sent:* Wednesday, October 20, 2021 3:21 PM > *To:* Tomasz Lubinski > *Cc:* Subversion > *Subject:* Re: Subversion 1.14.1 and serf 1.3.9 > > > > Den ons 20 okt. 2021 13:49Tomasz Lubinski skrev: > > I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with > segmentation fault. Now I receive message: > > Error running context: The server unexpectedly closed the connection. > > > > OK. It is obviously a fault if OpenSSL triggers a segfault if it looses > the connection to the server, but just loosing the connection is bad in > itself. > > > > Do you get any error messages in the server log? What is the server > version (and possibly platform/distribution)? > > > > Is there any chance that a firewall (either hardware or software) is > blocking the connection? > > > > Kind regards > > Daniel > > > > > > > > Tomek L > > > > *From:* Daniel Sahlberg > *Sent:* Wednesday, October 20, 2021 12:03 PM > *To:* Tomasz Lubinski > *Cc:* Subversion > *Subject:* Re: Subversion 1.14.1 and serf 1.3.9 > > > > Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski >: > > Yes problem occurs only with correct user/password (self-signed SSL > certificate used). In case of incorrect user/password or repository name, > it ends with correct error message without segmentation fault. > > The problem is when I’m trying to open RA session using > svn_client_open_ra_session. > > I’m using my build. > > > > Any chance you can verify if it is a problem only when using OpenSSL 3 (ie > did you try it with OpenSSL 1.1.1)? > > > > Kind regards, > > Daniel > >
Re: Subversion 1.14.1 and serf 1.3.9
On Thu, Oct 21, 2021 at 2:00 PM Daniel Sahlberg wrote: > > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski : >> >> I’m using Virtual SVN, server shows accepted connection with code 200. >> >> >> >> I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib >> 1.2.7 (that was used by me some time ago) and it seems that it works OK, now. >> >> Very strange problem with assembly code in zlib 1.2.11. >> >> >> >> Tomek L > > > Thanks for reporting back! That is indeed a very strange problem, even more > so since TortoiseSVN seems to use zlib 1.2.11. > > Maybe you can check the same action using TortoiseSVN? > > Kind regards, > Daniel Indeed, zlib's assembly code seems to be unreliable on Windows. When I build / test (for signing new releases) on Windows, I never use the assembly build of zlib anymore (ever since I ran into problems with it years ago). I suppose TortoiseSVN also does not use the assembly build of zlib. -- Johan
Re: Subversion 1.14.1 and serf 1.3.9
Den tors 21 okt. 2021 kl 14:05 skrev Johan Corveleyn : > On Thu, Oct 21, 2021 at 2:00 PM Daniel Sahlberg > wrote: > > > > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski < > t.lubin...@verocel.pl>: > >> > >> I’m using Virtual SVN, server shows accepted connection with code 200. > >> > >> > >> > >> I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib > 1.2.7 (that was used by me some time ago) and it seems that it works OK, > now. > >> > >> Very strange problem with assembly code in zlib 1.2.11. > >> > >> > >> > >> Tomek L > > > > > > Thanks for reporting back! That is indeed a very strange problem, even > more so since TortoiseSVN seems to use zlib 1.2.11. > > > > Maybe you can check the same action using TortoiseSVN? > > > > Kind regards, > > Daniel > > Indeed, zlib's assembly code seems to be unreliable on Windows. When I > build / test (for signing new releases) on Windows, I never use the > assembly build of zlib anymore (ever since I ran into problems with it > years ago). > > I suppose TortoiseSVN also does not use the assembly build of zlib. > You are probably right. Thanks for clarifying! @Tomasz Lubinski , can you try to use zlib without the assembly code? Kind regards, Daniel
Re: Subversion 1.14.1 and serf 1.3.9
On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn wrote: > > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski > > : > >> Very strange problem with assembly code in zlib 1.2.11. > Indeed, zlib's assembly code seems to be unreliable on Windows. When I > build / test (for signing new releases) on Windows, I never use the > assembly build of zlib anymore (ever since I ran into problems with it > years ago). I thought we had that documented somewhere but I can't seem to find it now. I remember reading a recommendation not to use the assembly build of zlib because of various issues. It may have been in the mailing list archives. Compilers these days have gotten so good that I think it's a waste of time to write hand-coded assembly unless there's a very specific and very special use case requiring exact control over something. Data structure and algorithm design make a far bigger impact than trying to save a few cycles. :-) Hope you get better results now! Cheers, Nathan
Re: svn binary packages for macOS
On Mon, Oct 18, 2021 at 2:55 AM Daniel Sahlberg wrote: >> Would it make sense to give them a heads up before removing the links in >> case they would like to release newer packages and remain on the list? > > > Yes, if we have any contact channels (I'm not sure about sending to an > anonymous info address) and as long as it doesn't violate ASF vendor > neutrality. It is about caring for the ecosystem. Nathan, can you do this > with the PMC chair hat? Apologies for the delayed reply... I'm also not too sure about sending to an anonymous info address. If someone knows who is the proper contact, I'll be happy to send a message. Cheers, Nathan
