Re: Subversion 1.9.10/1.10.4 choke on non-ASCII resources on HP-UX
On 07.05.2019 08:45, Osipov, Michael wrote:
>
>
> Am 2019-05-03 um 11:53 schrieb Branko Čibej:
>> On 02.05.2019 11:40, Osipov, Michael wrote:
>>> Hi Branko,
>>>
>>> Am 2019-05-01 um 02:17 schrieb Branko Čibej:
On 30.04.2019 20:18, Osipov, Michael wrote:
> The terminal and locale are fine though:
>> $ locale
>> LANG=de_DE.utf8
>> LC_CTYPE="de_DE.utf8"
>> LC_COLLATE="de_DE.utf8"
>> LC_MONETARY="de_DE.utf8"
>> LC_NUMERIC="de_DE.utf8"
>> LC_TIME="de_DE.utf8"
>> LC_MESSAGES="de_DE.utf8"
>> LC_ALL=
LC_ALL should probably not be empty. Could be that on HP-UX, the empty
value causes Subversion to use the default C (or POSIX) locale. Try
setting
LC_ALL="de_DE.utf8"; export LC_ALL
Subversion tries setlocale(LC_ALL, "") first and only if that
fails, it
tries setlocale(LC_CTYPE, ""). Evidently the first call succeeds,
which
is strange but not strictly wrong. I think.
>>>
>>> Doesn't really work out.
>>>
>>> Here is the old server:
$ hostname
blnn724x
$ svn --version -q
1.9.4
$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_ALL=
$ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
README.txt
a/
c.txt
hallo.c
keyword-test.txt
test1234/
testprogramm.c
привет.txt
>>>
>>> the export didn't change anything, it still fails:
$ hostname
deblndw024v
$ svn --version -q
1.9.4
$ locale
LANG=de_DE.utf8
LC_CTYPE="de_DE.utf8"
LC_COLLATE="de_DE.utf8"
LC_MONETARY="de_DE.utf8"
LC_NUMERIC="de_DE.utf8"
LC_TIME="de_DE.utf8"
LC_MESSAGES="de_DE.utf8"
LC_ALL=de_DE.utf8
$ svn ls https://deblndw011x.ad001.siemens.net/repos/svn/Playground
README.txt
a/
c.txt
hallo.c
keyword-test.txt
test1234/
testprogramm.c
{U+043F}{U+0440}{U+0438}{U+0432}{U+0435}{U+0442}.txt
>>>
>>>
>>> Here is a basic program:
0# cat locale.c
#include
#include
#include
int main(void) {
char *l = NULL;
l = setlocale(LC_ALL, "");
printf("%s\n", l);
char *nl = NULL;
nl = nl_langinfo(CODESET);
printf("%s\n", nl);
return 0;
}
# aCC -o locale locale.c
>>> # ./locale
>>> C.utf8 C.utf8 C.utf8 C.utf8 C.utf8 C.utf8
>>> utf8
# LC_ALL=de_DE.utf8 ./locale
de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8 de_DE.utf8
utf8
>>>
>>> Looks good to me, doesn't it?
>>
>> It does ...
>>
>>> Anything else I can try? Bad libiconv or libapr?
>>
>> Either libiconv or apr_xlate don't handle UTF-8 on HP-UX? It would be
>> strange but not impossible.
>>
>> Given the earlier warning from msgfmt that
>> "Charset "UTF-8" is not supported" I suspect libiconv, since gettext
>> doesn't use APR.
>>
>> Is it possible that you're using a mis-configured GNU libiconv instead
>> of the stock system version? Since locale() does support UTF-8, I'd
>> expect the stock libiconv to support it, too. However, IIRC GNU tools
>> don't like the POSIX libiconv API very much.
>>
>> Subversion doesn't care; for string conversion, whatever stock libiconv
>> does (through apr_xlate) should be enough; it doesn't depend on NLS
>> being enabled.
>
> Given your pointers, that was it. For some reason I have screwed up
> the stack around the GNU stuff. Recompiling everyting again to PREFIX
> made it work. Subversion perfectly works now on HP-UX.
Great!
-- Brane
Re: Fwd: Error during Migrating from Perforce to SVN
On 06.05.2019 21:59, Ibrahim Ibbu wrote: > [root@sce-github svn-repos]# pwd > > /SVN/svn-repos > > [root@sce-github svn-repos]# ls -lrt > > total 24 > > drwxr-xr-x 2 root root 4096 May 5 02:41 locks > > -rw-r--r-- 1 root root 229 May 5 02:41 README.txt > > drwxr-xr-x 2 root root 4096 May 5 02:41 conf > > -r--r--r-- 1 root root 2 May 5 02:41 format > > drwxr-xr-x 2 root root 4096 May 5 02:41 hooks > > drwxr-sr-x 6 root root 4096 May 5 02:43 db > > > > I could not see any source code here, Please verify it once as I am > not sure on SVN stuff. > Of course you couldn't, this is the repository. You have to check out a working copy somewhere to get the repository contents. -- Brane
Re: Fw: Latest nightly tarball doesn't catch up Subversion trunk
Hi All, https://github.com/apache/infrastructure-puppet/blob/deployment/modules/buildbot_asf/files/projects/create-subversion-nightlies-index.sh I can get to it over the next few days, but in the meantime, feel free to check the script. Gav... On Tue, May 7, 2019 at 2:54 AM wuzhouhui wrote: > Forwarded to bui...@apache.org > > -Original Messages- > From: wuzhouhui > Sent Time: 2019-04-27 13:51:43 (Saturday) > To: Subversion > Cc: > Subject: Latest nightly tarball doesn't catch up Subversion trunk > > Hi, > > The https://ci.apache.org/projects/subversion/nightlies/index.html says > the nightly tarball is automatically generated from latest sources from > Subversion trunk. But I noticed that the latest night tarball (released > in 27-04-2019) doesn't catch up latest Subversion trunk. E.g. head of > CHANGES from subversion-nightly.tar.gz is: > > > Version 1.10.0 > > (?? ??? 2017, from /branches/1.10.x) > > http://svn.apache.org/repos/asf/subversion/tags/1.10.0 > > But the latest CHANGES of Subversion trunk is: > > > # To view a revision listed as (rXXX), visit: > > # https://svn.apache.org/rXXX > > # > > # To view an issue listed as (issue #), visit: > > # https://issues.apache.org/jira/browse/SVN- > > Is something goes wrong with nightly release procedure? > -- Gav...
Same level externals not possible
Hi folks, consider the following layout we need to solve for our legacy build: . |-- forms |-- src \-- inc inc shall point to forms as external. Wenn doing "svn ps" with "forms inc" or "./forms inc" I receive an error. Of course, according to the help output [1] this is not possible. But why can't I have same level externals? We currently apply the ugly workaround by creating 'inc' and adding externals beneath that. I am on Subversion 1.9.x, 1.10.x. Shall I open a JIRA issue for that? Michael [1] https://github.com/apache/subversion/blob/trunk/subversion/po/de.po#L16176-L16212
Re: Same level externals not possible
On 07.05.2019 13:53, Osipov, Michael wrote: > Hi folks, > > consider the following layout we need to solve for our legacy build: > > . > |-- forms > |-- src > \-- inc > > inc shall point to forms as external. Wenn doing "svn ps" with "forms > inc" or "./forms inc" I receive an error. Just to clarify, you want this: $ svn propset svn:externals './forms inc' . that is, on the parent directory of 'forms'? > Of course, according to the help output [1] this is not possible. But > why can't I have same level externals? We currently apply the ugly > workaround by creating 'inc' and adding externals beneath that. The reason you can't do that is that if we allowed the syntax you're proposing, it will conflict with the old, pre-1.5 svn:externals format, where the first parameter was the external name and the second was the full URL. -- Brane
Re: Same level externals not possible
Am 2019-05-07 um 14:20 schrieb Branko Čibej: On 07.05.2019 13:53, Osipov, Michael wrote: Hi folks, consider the following layout we need to solve for our legacy build: . |-- forms |-- src \-- inc inc shall point to forms as external. Wenn doing "svn ps" with "forms inc" or "./forms inc" I receive an error. Just to clarify, you want this: $ svn propset svn:externals './forms inc' . Correct. Expanded it is: /di1234/trunk |-- forms |-- src \-- inc that is, on the parent directory of 'forms'? Of course, according to the help output [1] this is not possible. But why can't I have same level externals? We currently apply the ugly workaround by creating 'inc' and adding externals beneath that. The reason you can't do that is that if we allowed the syntax you're proposing, it will conflict with the old, pre-1.5 svn:externals format, where the first parameter was the external name and the second was the full URL. I'd be happy if this compat-mode could be turned off via compile time option to make the case work as expected. I don't know how much effort that is since I don't know the Subversion codebase. Michael
Re: Same level externals not possible
On Tue, May 7, 2019 at 2:33 PM Osipov, Michael wrote: > > > > Am 2019-05-07 um 14:20 schrieb Branko Čibej: > > On 07.05.2019 13:53, Osipov, Michael wrote: > >> Hi folks, > >> > >> consider the following layout we need to solve for our legacy build: > >> > >> . > >> |-- forms > >> |-- src > >> \-- inc > >> > >> inc shall point to forms as external. Wenn doing "svn ps" with "forms > >> inc" or "./forms inc" I receive an error. > > > > Just to clarify, you want this: > > > > $ svn propset svn:externals './forms inc' . > > Correct. Expanded it is: > > /di1234/trunk > |-- forms > |-- src > \-- inc Can't you use the following? $ svn propset svn:externals '../forms inc' . or '../trunk/forms inc' (not sure) According to the book [1] '../' means "Relative to the URL of the directory on which the svn:externals property is set" [1] http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html -- Johan
Re: Same level externals not possible
Am 2019-05-07 um 14:49 schrieb Johan Corveleyn: On Tue, May 7, 2019 at 2:33 PM Osipov, Michael wrote: Am 2019-05-07 um 14:20 schrieb Branko Čibej: On 07.05.2019 13:53, Osipov, Michael wrote: Hi folks, consider the following layout we need to solve for our legacy build: . |-- forms |-- src \-- inc inc shall point to forms as external. Wenn doing "svn ps" with "forms inc" or "./forms inc" I receive an error. Just to clarify, you want this: $ svn propset svn:externals './forms inc' . Correct. Expanded it is: /di1234/trunk |-- forms |-- src \-- inc Can't you use the following? $ svn propset svn:externals '../forms inc' . This won't work because forms and inc have to be on the same level otherwise it'd be trivial. or '../trunk/forms inc' (not sure) We have considered that, but it won't work with branches. One would have to change the extenal pointer back and forths, too errorprone. Michael
Re: Same level externals not possible
On 07.05.2019 14:25, Osipov, Michael wrote: > > > Am 2019-05-07 um 14:20 schrieb Branko Čibej: >> On 07.05.2019 13:53, Osipov, Michael wrote: >>> Hi folks, >>> >>> consider the following layout we need to solve for our legacy build: >>> >>> . >>> |-- forms >>> |-- src >>> \-- inc >>> >>> inc shall point to forms as external. Wenn doing "svn ps" with "forms >>> inc" or "./forms inc" I receive an error. >> >> Just to clarify, you want this: >> >> $ svn propset svn:externals './forms inc' . > > Correct. Expanded it is: > > /di1234/trunk > |-- forms > |-- src > \-- inc > >> that is, on the parent directory of 'forms'? >> >>> Of course, according to the help output [1] this is not possible. But >>> why can't I have same level externals? We currently apply the ugly >>> workaround by creating 'inc' and adding externals beneath that. >> >> The reason you can't do that is that if we allowed the syntax you're >> proposing, it will conflict with the old, pre-1.5 svn:externals format, >> where the first parameter was the external name and the second was the >> full URL. > > I'd be happy if this compat-mode could be turned off via compile time > option to make the case work as expected. I don't know how much effort > that is since I don't know the Subversion codebase. Well, I would be quite unhappy with that because then every time someone reported a problem with externals, we'd have to ask how they compiled their client ... and the answer would probably be "I don't know." One simply doesn't design features that way. :) If your clients are UNIX-ish machines, you can commit 'inc' as a symlink to 'forms'. Or creating the link (even on Windows) could be part of a script that prepares the working copy for your legacy build. -- Brane
Re: Same level externals not possible
Am 2019-05-07 um 14:57 schrieb Branko Čibej: On 07.05.2019 14:25, Osipov, Michael wrote: Am 2019-05-07 um 14:20 schrieb Branko Čibej: On 07.05.2019 13:53, Osipov, Michael wrote: Hi folks, consider the following layout we need to solve for our legacy build: . |-- forms |-- src \-- inc inc shall point to forms as external. Wenn doing "svn ps" with "forms inc" or "./forms inc" I receive an error. Just to clarify, you want this: $ svn propset svn:externals './forms inc' . Correct. Expanded it is: /di1234/trunk |-- forms |-- src \-- inc that is, on the parent directory of 'forms'? Of course, according to the help output [1] this is not possible. But why can't I have same level externals? We currently apply the ugly workaround by creating 'inc' and adding externals beneath that. The reason you can't do that is that if we allowed the syntax you're proposing, it will conflict with the old, pre-1.5 svn:externals format, where the first parameter was the external name and the second was the full URL. I'd be happy if this compat-mode could be turned off via compile time option to make the case work as expected. I don't know how much effort that is since I don't know the Subversion codebase. Well, I would be quite unhappy with that because then every time someone reported a problem with externals, we'd have to ask how they compiled their client ... and the answer would probably be "I don't know." One simply doesn't design features that way. :) Fair enough ;-) Any chances that this will go way with the next LTS release? 1.5 is really really old... If your clients are UNIX-ish machines, you can commit 'inc' as a symlink to 'forms'. Or creating the link (even on Windows) could be part of a script that prepares the working copy for your legacy build. The software runs on HP-UX only, so yes we have real UNIX. We have also considered symlinks, but wanted actually the portable -- Subversion -- way. Michael
Re: Same level externals not possible
On 07.05.2019 15:19, Osipov, Michael wrote: > > > Am 2019-05-07 um 14:57 schrieb Branko Čibej: >> On 07.05.2019 14:25, Osipov, Michael wrote: >>> >>> >>> Am 2019-05-07 um 14:20 schrieb Branko Čibej: On 07.05.2019 13:53, Osipov, Michael wrote: > Hi folks, > > consider the following layout we need to solve for our legacy build: > > . > |-- forms > |-- src > \-- inc > > inc shall point to forms as external. Wenn doing "svn ps" with "forms > inc" or "./forms inc" I receive an error. Just to clarify, you want this: $ svn propset svn:externals './forms inc' . >>> >>> Correct. Expanded it is: >>> >>> /di1234/trunk >>> |-- forms >>> |-- src >>> \-- inc >>> that is, on the parent directory of 'forms'? > Of course, according to the help output [1] this is not possible. But > why can't I have same level externals? We currently apply the ugly > workaround by creating 'inc' and adding externals beneath that. The reason you can't do that is that if we allowed the syntax you're proposing, it will conflict with the old, pre-1.5 svn:externals format, where the first parameter was the external name and the second was the full URL. >>> >>> I'd be happy if this compat-mode could be turned off via compile time >>> option to make the case work as expected. I don't know how much effort >>> that is since I don't know the Subversion codebase. >> >> Well, I would be quite unhappy with that because then every time someone >> reported a problem with externals, we'd have to ask how they compiled >> their client ... and the answer would probably be "I don't know." >> >> One simply doesn't design features that way. :) > > Fair enough ;-) > > Any chances that this will go way with the next LTS release? 1.5 is > really really old... We promise backward compatibility across 1.x, so not likely. >> If your clients are UNIX-ish machines, you can commit 'inc' as a symlink >> to 'forms'. Or creating the link (even on Windows) could be part of a >> script that prepares the working copy for your legacy build. > > The software runs on HP-UX only, so yes we have real UNIX. We have > also considered symlinks, but wanted actually the portable -- > Subversion -- way. Understood. If you can come up with a syntax for what you want that is backwards-compatible and unambiguous, feel free to write up a proposal and send it to the dev@ list. For reference, what we currently support is documented here: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html -- Brane
Re: Same level externals not possible
On Tue, May 7, 2019 at 9:19 AM Osipov, Michael wrote: > Any chances that this will go way with the next LTS release? 1.5 is > really really old... The problem with that idea is that repositories in use today that contain pre-1.5-style externals will stop working.
