Re: change attribute visibility in board from command line/skript/ulp (eagle 6.6)
Stefan Sperling wrote: >On Fri, Nov 02, 2018 at 02:30:17PM +, Lorenz wrote: >> Hi all, >> >> I've defined attributes on parts in the schematic editor. >> >> Now I'm trying to show them in the layout running an ULP on the >> grouped parts in the board editor or from the contex menu. >> >> Without success so far. There seems to be no way to change attribute >> visibility in the board editor, besides using the attribute dialog. >> >> Anyone out there with an idea? >> -- >> >> Lorenz > >This is the Apache Subversion users mailing list. > >Are you sure you're posting to the correct list? No, I'm definitely sure this is the wrong list. Sorry for the noice. -- Lorenz
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 05.11.2018 04:45, Ryan Schmidt wrote: > > On Nov 4, 2018, at 11:57, Thorsten Schöning wrote: > >> Now "we" need to get GitHub to change their >> implementation and I didn't even get an automatic bot-reply to my >> question on Friday yet. :-) Lets see how things are going after I send >> them this thread... > I'd be interested to know the resolution, since I use the GitHub svn bridge > daily. I'll hold off on upgrading past Subversion 1.10.x for now but could > you keep us informed about what GitHub does to solve this? > > > Wasn't there going to be support in the Subversion client for dealing with > git repositories directly? Is that still in the works? There's a branch that has very rudimentary support for read-only checkouts from Git repositories. It hasn't been updated in a while. If anyone would like to help with that, please do join us on our dev@ list. -- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Nov 4, 2018, at 11:57, Thorsten Schöning wrote: > Now "we" need to get GitHub to change their > implementation and I didn't even get an automatic bot-reply to my > question on Friday yet. :-) Lets see how things are going after I send > them this thread... I'd be interested to know the resolution, since I use the GitHub svn bridge daily. I'll hold off on upgrading past Subversion 1.10.x for now but could you keep us informed about what GitHub does to solve this? Wasn't there going to be support in the Subversion client for dealing with git repositories directly? Is that still in the works?
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Thorsten Schöning wrote on Sun, 04 Nov 2018 18:57 +0100: > Guten Tag Branko Čibej, > am Sonntag, 4. November 2018 um 17:47 schrieben Sie: > > > I'm not sure what you mean by "handles more than only DAV successfully" > > I thought it might be possible that GitHub answers differently but > properly, because the other check mentioned something about HTTP v2. The terminology is a bit unfortunate here. There's a HTTP/2 protocol, rfc7540, but it has *nothing* to do with what Subversion design documents refer to as "HTTPv2". The latter is simply a different way for libsvn_ra_serf to communicate with mod_dav_svn, but it was designed and implemented in terms of HTTP/1 requests and responses. (Of course, one ought to be able to run HTTPv2 over HTTP/2 if one uses serf and httpd versions that support the latter.) In hindsight, we should have chosen a different name for that protocol revision.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 04.11.2018 18:57, Thorsten Schöning wrote: > Guten Tag Branko Čibej, > am Sonntag, 4. November 2018 um 17:47 schrieben Sie: > >> I'm not sure what you mean by "handles more than only DAV successfully" > I thought it might be possible that GitHub answers differently but > properly, because the other check mentioned something about HTTP v2. > Because of TLS, I was unable to look at the requests and responses > then, but it's like you said, they don't provide DAV-headers in their > response to OPTION. > >> And yes, the HTTP/DAV specification requires that header to be present >> in the response. > Which you didn't care about before and things worked for some years > for some users. We made this change because users complained about unhelpful error messages when they tried to connect to a server that did not even implement HTTP/DAV. The error message was "Malformed XML in response" which wasn't exactly helpful for diagnosing the problem. I admit I didn't have GitHub in mind when I added this check. ... > Now "we" need to get GitHub to change their > implementation and I didn't even get an automatic bot-reply to my > question on Friday yet. :-) Lets see how things are going after I send > them this thread... I keep wondering why the GitHub staff didn't contact us when they implemented their SVN-like server. This might all have been avoided if they had. We already spent time trying to work around GitHub's faulty implementation (q.v. r1707164), but there's a limit to how much we can or should do. The protocols in question are quite well documented after all, both in RFCs and in our own notes. -- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Nico Kadel-Garcia, am Sonntag, 4. November 2018 um 19:42 schrieben Sie: > Can you switch to using TortoiseGit locally, and avoid the extra > compatibility layers? My use case might be special: I have one large libs-repo for many different projects and that contains committed libs and some using svn:externals. Everyone checking out this libs-repo with any SVN-client, shell, Tortoise, Eclipse etc., gets everything from public SNV servers or even GitHub as needed. TortoiseGit is not of much help in this setup. Yes, that might change in future and could be handled totally different and all, but currently it is the way it is anbd I hope GitHub fixes things. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On Sun, Nov 4, 2018 at 10:05 AM Thorsten Schöning wrote: > > Hi all, > > GitHub documents to support Subversion clients and I'm using that for > many projects to include them in one of my working copies using > svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the > following error for all of those projects: > > > The server at '[...]' does not support the HTTP/DAV protocol. > > This happens to a long list of projects, some examples: > > > https://github.com/apache/commons-lang.git/tags/LANG_3_6 > > https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2 > > https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage Can you switch to using TortoiseGit locally, and avoid the extra compatibility layers? It would take decisions about your workflow to do this, but I've found its built-in git-svn toolkit to be effective and robust for upstream Subversion repositories even where I needed to retain contact with upstream Subversion repositories.. > I've asked about that problem on SO[1], which revealed that the switch > from 1.10 to 1.11 really is the problem. Downgrading resolves the > problem. > > Do you have any idea what could be the root cause? Is there something > that needs to be configured specially? > > Thanks! > > [1]: https://stackoverflow.com/a/53132753/2055163 > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow >
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Branko Čibej, am Sonntag, 4. November 2018 um 17:47 schrieben Sie: > I'm not sure what you mean by "handles more than only DAV successfully" I thought it might be possible that GitHub answers differently but properly, because the other check mentioned something about HTTP v2. Because of TLS, I was unable to look at the requests and responses then, but it's like you said, they don't provide DAV-headers in their response to OPTION. > And yes, the HTTP/DAV specification requires that header to be present > in the response. Which you didn't care about before and things worked for some years for some users. Now "we" need to get GitHub to change their implementation and I didn't even get an automatic bot-reply to my question on Friday yet. :-) Lets see how things are going after I send them this thread... Thank you both for your time anyway! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 04.11.2018 17:41, Branko Čibej wrote: > On 04.11.2018 16:05, Thorsten Schöning wrote: >> Hi all, >> >> GitHub documents to support Subversion clients and I'm using that for >> many projects to include them in one of my working copies using >> svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the >> following error for all of those projects: >> >>> The server at '[...]' does not support the HTTP/DAV protocol. >> This happens to a long list of projects, some examples: >> >>> https://github.com/apache/commons-lang.git/tags/LANG_3_6 >>> https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2 >>> https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage > The first two URLs return a 404. The third returns 410 and says "feature > gone" ... I think you'll need better examples. Sorry, that's incorrect, I wrote that before I fixed my svnoptions.sh script. Please ignore.
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 04.11.2018 17:47, Branko Čibej wrote:
> On 04.11.2018 17:06, Thorsten Schöning wrote:
>> Guten Tag Thorsten Schöning,
>> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>>
>>> Others have the same problem and while it is true that GitHub might
>>> have implemented something on their own, it might help to have a look
>>> at the changes between 1.10 and 1.11 regarding the protocol.
>> Guess I found it:
>>
>>>* Better error when http:// URL is not a Subversion repository (r1825302)
>>> /* Bail out early if we're not talking to a DAV server.
>>> Note that this check is only valid if we've received a success
>>> response; redirects and errors don't count. */
>>> if (opt_ctx->handler->sline.code >= 200
>>> && opt_ctx->handler->sline.code < 300
>>> && !opt_ctx->received_dav_header)
>>> {
>>> return svn_error_createf
>>> (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>>> _("The server at '%s' does not support the HTTP/DAV protocol"),
>>> session->session_url_str);
>>> }
>> "received_dav_header" is only set at one place, isn't that check
>> wrong? The code handles more than only DAV successfully from my point
>> of view:
>
> I'm not sure what you mean by "handles more than only DAV successfully"
> ... this code only checks if we received any DAV: header in the response
> to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
> HTTP protocol use that for capability negotiation at the start of a session.
>
> And yes, the HTTP/DAV specification requires that header to be present
> in the response.
FWIW, the fix could be as simple as GitHub's server returning something like
DAV: http://github.com/fake-svn-server
in their response headers ...
-- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 04.11.2018 17:06, Thorsten Schöning wrote:
> Guten Tag Thorsten Schöning,
> am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
>
>> Others have the same problem and while it is true that GitHub might
>> have implemented something on their own, it might help to have a look
>> at the changes between 1.10 and 1.11 regarding the protocol.
> Guess I found it:
>
>>* Better error when http:// URL is not a Subversion repository (r1825302)
>> /* Bail out early if we're not talking to a DAV server.
>> Note that this check is only valid if we've received a success
>> response; redirects and errors don't count. */
>> if (opt_ctx->handler->sline.code >= 200
>> && opt_ctx->handler->sline.code < 300
>> && !opt_ctx->received_dav_header)
>> {
>> return svn_error_createf
>> (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
>> _("The server at '%s' does not support the HTTP/DAV protocol"),
>> session->session_url_str);
>> }
> "received_dav_header" is only set at one place, isn't that check
> wrong? The code handles more than only DAV successfully from my point
> of view:
I'm not sure what you mean by "handles more than only DAV successfully"
... this code only checks if we received any DAV: header in the response
to the OPTIONS request, no more and no less. HTTP/DAV and Subversion's
HTTP protocol use that for capability negotiation at the start of a session.
And yes, the HTTP/DAV specification requires that header to be present
in the response.
-- Brane
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
On 04.11.2018 16:05, Thorsten Schöning wrote: > Hi all, > > GitHub documents to support Subversion clients and I'm using that for > many projects to include them in one of my working copies using > svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the > following error for all of those projects: > >> The server at '[...]' does not support the HTTP/DAV protocol. > This happens to a long list of projects, some examples: > >> https://github.com/apache/commons-lang.git/tags/LANG_3_6 >> https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2 >> https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage The first two URLs return a 404. The third returns 410 and says "feature gone" ... I think you'll need better examples. > I've asked about that problem on SO[1], which revealed that the switch > from 1.10 to 1.11 really is the problem. Downgrading resolves the > problem. > > Do you have any idea what could be the root cause? Is there something > that needs to be configured specially? The root cause is that GitHub does not implement Subversion's HTTP/DAV protocol correctly. In 1.11, the Subversion client has become stricter about the server requirements (see: https://svn.apache.org/r1825302). Specifically, we require that the server sends DAV response headers to the OPTIONS request, which we use for capability negotiation. Here's an example of a correct response: HTTP/1.1 200 OK Date: Sun, 04 Nov 2018 15:40:24 GMT Server: Apache/2.4.7 (Ubuntu) DAV: 1,2 DAV: version-control,checkout,working-resource DAV: merge,baseline,activity,version-controlled-collection DAV: http://subversion.tigris.org/xmlns/dav/svn/depth ... The GitHub server does not return any DAV: header for the OPTIONS request, so the response is considered incorrect. I suggest sending a bug report to GitHub; the attached script can be used to simulate Subversion's OPTIONS request. In the meantime, staying with 1.10.x appears to be the only option if you have to use GitHub's SVN protocol. -- Brane #!/bin/bash if [ -z "$1" ]; then echo "Usage: $0 " >&2 exit 2 fi HOST=$(echo "$1" | sed -e 's%^https*://\([^/]*\).*$%\1%') set -x curl -i -X OPTIONS \ -H "Host: $HOST" \ -H 'User-Agent: SVN/1.11.0' \ -H 'Content-Type: text/xml' \ -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/depth' \ -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo' \ -H 'DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops' \ --data-raw '' \ "$1"
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Thorsten Schöning,
am Sonntag, 4. November 2018 um 16:42 schrieben Sie:
> Others have the same problem and while it is true that GitHub might
> have implemented something on their own, it might help to have a look
> at the changes between 1.10 and 1.11 regarding the protocol.
Guess I found it:
>* Better error when http:// URL is not a Subversion repository (r1825302)
> /* Bail out early if we're not talking to a DAV server.
> Note that this check is only valid if we've received a success
> response; redirects and errors don't count. */
> if (opt_ctx->handler->sline.code >= 200
> && opt_ctx->handler->sline.code < 300
> && !opt_ctx->received_dav_header)
> {
> return svn_error_createf
> (SVN_ERR_RA_DAV_OPTIONS_REQ_FAILED, NULL,
> _("The server at '%s' does not support the HTTP/DAV protocol"),
> session->session_url_str);
> }
"received_dav_header" is only set at one place, isn't that check
wrong? The code handles more than only DAV successfully from my point
of view:
> if (svn_cstring_casecmp(key, "dav") == 0)
> {
> /* Each header may contain multiple values, separated by commas, e.g.:
>DAV: version-control,checkout,working-resource
>DAV: merge,baseline,activity,version-controlled-collection
>DAV: http://subversion.tigris.org/xmlns/dav/svn/depth */
> apr_array_header_t *vals = svn_cstring_split(val, ",", TRUE,
>opt_ctx->pool);
>
> opt_ctx->received_dav_header = TRUE;
> [...]
> /* SVN-specific headers -- if present, server supports HTTP protocol v2 */
> else if (!svn_ctype_casecmp(key[0], 'S')
>&& !svn_ctype_casecmp(key[1], 'V')
>&& !svn_ctype_casecmp(key[2], 'N'))
> {
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Thorsten Schöning wrote on Sun, Nov 04, 2018 at 16:42:11 +0100: > Guten Tag Thorsten Schöning, > am Sonntag, 4. November 2018 um 16:05 schrieben Sie: > > >> The server at '[...]' does not support the HTTP/DAV protocol. > > Others have the same problem and while it is true that GitHub might > have implemented something on their own, it might help to have a look > at the changes between 1.10 and 1.11 regarding the protocol. That took exactly two minutes to grep, diff, and blame. See https://svn.apache.org/r1825302. 1.11 has new behaviour whereby it deliberately errors out if the HTTP response does not include a "DAV:" header, apparently in to improve the failure mode on URLs that are not Subversion repository URLs. > I've already written to the GitHub support but nobody seemed to care yet. Well, we can't fix this issue on our end. Our client code works with our server code, but there is no way for us to ensure that our client code (continues to) work with third-party server reimplementations. That said, if any GitHub staff are reading this, you're welcome to contact us on the dev@ list and we'll see what we can do. Cheers, Daniel (We can't just "remove the new check" because that would regress the failure mode that check was added to improve.)
Re: Problems accessing GitHub's SVN-bridge with SVN 1.11
Guten Tag Thorsten Schöning, am Sonntag, 4. November 2018 um 16:05 schrieben Sie: >> The server at '[...]' does not support the HTTP/DAV protocol. Others have the same problem and while it is true that GitHub might have implemented something on their own, it might help to have a look at the changes between 1.10 and 1.11 regarding the protocol. I've already written to the GitHub support but nobody seemed to care yet. https://groups.google.com/forum/#!topic/tortoisesvn/qaJQ_K9Wbb8 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Problems accessing GitHub's SVN-bridge with SVN 1.11
Hi all, GitHub documents to support Subversion clients and I'm using that for many projects to include them in one of my working copies using svn:externals. Since upgrading TortoiseSVN from 1.10 to 1.11 I get the following error for all of those projects: > The server at '[...]' does not support the HTTP/DAV protocol. This happens to a long list of projects, some examples: > https://github.com/apache/commons-lang.git/tags/LANG_3_6 > https://github.com/pgjdbc/pgjdbc.git/tags/REL42.2.2 > https://github.com/ams-tschoening/kaitai_struct_tests.git/branches/libs_java_3rd_usage I've asked about that problem on SO[1], which revealed that the switch from 1.10 to 1.11 really is the problem. Downgrading resolves the problem. Do you have any idea what could be the root cause? Is there something that needs to be configured specially? Thanks! [1]: https://stackoverflow.com/a/53132753/2055163 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
