Measured: btrfs COW and sqlite exclusive locking

Out of curiosity, I modified the svn client to use the btrfs facility for fast file copies (copy-on-write, also known as reflink), to see what benefits it might possibly give in terms of performance and disk space. While at it, I also measured the benefits of the sqlite exclusive locking th

Re: Measured: btrfs COW and sqlite exclusive locking

8 jul 2012 kl. 19.26 skrev Daniel Shahaf: Yes, please specify what the client used COW for. Was it for populating the working tree files from the pristine store? Was it for something else? It was only intended for that, but it's possible that the copying code is used for other purposes as

Re: Measured: btrfs COW and sqlite exclusive locking

9 jul 2012 kl. 18.08 skrev Daniel Shahaf: Thanks for clarifying. I'm not familiar enough with the library to have much more to say, but I thought I would point out svn_tristate_t (cf your maybe_t). Thank you, I didn't know about svn_tristate_t. I'll be sure to use it in any production versi

Re: Measured: btrfs COW and sqlite exclusive locking

10 jul 2012 kl. 22.38 skrev Peter Samuelson: Whatever it is in the data path that makes it slower, it probably is not a fair comparison. Even though we normally don't want to do our own fdatasync(), it is fair to consider the additional I/O load that is generated by Subversion operations. Th

sqlite3.c won't compile with -std=c89

sqlite3.c (from the amalgamation) cannot in general be compiled with - std=c89, which the Subversion build universally uses in trunk. How do we make an exception for a single file, to have it compiled with a different set of flags? On OS X, sqlite3.c includes a system header file, OSAtomic.h

Re: sqlite3.c won't compile with -std=c89

24 mar 2013 kl. 02.39 skrev Ben Reser: I build trunk on OS X at least once a day with sqlite-amalgamation and it builds fine for me. It throws a bunch of warnings but I don't think the warnings have anything to do with -std=c89. What errors or problems are you seeing? What compiler are you us

Re: sqlite3.c won't compile with -std=c89

The attached patch is an alternative way of solving this particular problem. [[[ Work around a problem on older OS X systems: sqlite3.c includes , which uses 'inline' and thus cannot be compiled with -std=c89 that we are using for all files. * subversion/libsvn_subr/sqlite3wrapper.c (topleve

Re: sqlite3.c won't compile with -std=c89

Unfortunately I missed a second compilation of sqlite3.c, in wc- queries-test.c. Here's an updated patch. Sorry about not getting it right the first time. [[[ Work around a problem on older OS X systems: sqlite3.c includes , which uses 'inline' and thus cannot be compiled with -std=c89 that we

Re: sqlite3.c won't compile with -std=c89

25 mar 2013 kl. 05.42 skrev Branko Čibej: I'm not too happy with this patch because the hack is not restricted to only those versions of OS X that actually need it. It's not needed, to my knowledge, at least since 10.6; the latest version ofthat header uses __inline rather than inline,

[PATCH] Make conflict message translatable

The conflict message "local %s %s, incoming %s %s upon %s" in svn_cl__get_human_readable_tree_conflict_description is not correctly prepared for localisation. First, two of the parameters are inserted untranslated (in English), making proper translation impossible; second, piecing together a

Re: [PATCH] Make conflict message translatable

29 mar 2013 kl. 03.03 skrev Julian Foad: Mattias Engdegård wrote: The patch assumes that svn_node_none, svn_node_unknown or svn_wc_operation_none cannot occur here. Please confirm or refute. I haven't checked whether these can occur in this message. svn_node_unknown can certainly

Re: [PATCH] Make conflict message translatable

2 apr 2013 kl. 15.51 skrev Julian Foad: A quick update. I tried your patch and the test suite fails here: FAIL: upgrade_tests.py 24: wc with add-add and del-del tree conflicts That's failing in local_reason_str() with kind=none and reason=deleted, so at least we need that function to handl

Updating sv.po

The Swedish translation has not been updated for many years and is in rough shape. I'd like to try giving it a thorough overhaul, some lubrication and a new coat of paint. This is going to take a while. Finding no listed maintainer to contact, I'm assuming the translation is orphaned at the

[PATCH] Re-localise conflict prompt

The conflict prompt is no longer localised, probably because of an oversight. Only the "long" descriptions are marked for translation but there is no actual corresponding gettext call; the "short" descriptions not at all. This patch attempts to rectify that. I'm not altogether happy with th

Re: Subversion 1.7.0 GO / NO-GO

Mattias Engdegård (CC'd) reports on IRC that apr_atomic_xchgptr() in recent APR's is broken, and the brokenness can affect Subversion under certain circumstances: <@danielsh> wayita: t < wayita> gcc 4.0.x or older < wayita> apr 1.3.x or newer < wayita> x86-64 on

Re: Subversion 1.7.0 GO / NO-GO

APR has a testsuite that includes a test for apr_atomic_xchgptr. Does that test detect the problem? Not as written, but it can trivially be made to. A patch has been added to the ARP bugzilla.

vc-svn.el non-update

I took the liberty to clarify the purpose of contrib/client-side/emacs/ vc-svn.el - to provide for a working vc-mode in Emacs 21 - since it has occasionally been used when it shouldn't, confusing the user. The file now also clearly states that new development should go in the Emacs tree inst

Re: [PATCH] Re-localise conflict prompt

8 apr 2013 kl. 11.15 skrev Philip Martin: Mattias Engdegård writes: The conflict prompt is no longer localised, probably because of an oversight. Were they localised in the past? Yes, they were. This is what happens in 1.7: $ LC_ALL=fr_FR.UTF-8 svn up Conflit découvert dans '/

Re: [PATCH] Re-localise conflict prompt

8 apr 2013 kl. 12.06 skrev Stefan Sperling: So I think it is OK to have short menu option names in English and provide long descriptions in the native language. Does that work for you, Mattias? Of course, if there is anything we're doing in the code that makes translation harder than necessar

Re: [PATCH] Re-localise conflict prompt

9 apr 2013 kl. 16.08 skrev Julian Foad: In general I think the interactive parts should be localized as much as possible, and if that means we need to do something special to the command-line option processing to ensure the same options can be used both on the command line and interactively

Re: [PATCH] Re-localise conflict prompt

10 apr 2013 kl. 20.52 skrev Mattias Engdegård: In this example, the valid shorthands for --accept ("mc" etc) also double as prompt answers, but that would not have to be the case in translations. On second thought, perhaps we should just drop --accept=mc and require the long

Re: [PATCH] Re-localise conflict prompt

11 apr 2013 kl. 14.03 skrev Stefan Sperling: The keys people type at the conflict prompt will eventually become part of muscle memory. What is mnemonic to one person might not be mnemonic to someone else. [...] In which case having to type different keys at a menu prompt depending on the langu

Re: [PATCH] Re-localise conflict prompt

11 apr 2013 kl. 14.24 skrev C. Michael Pilato: On 04/11/2013 03:45 AM, Mattias Engdegård wrote: [...] 3. The options that appear in the conflict prompt. These, I strongly believe, should all be translated, since it is essentially a menu of choices for the user. Note that this means that they

Re: [PATCH] Re-localise conflict prompt

12 apr 2013 kl. 12.21 skrev Branko Čibej: On 11.04.2013 20:47, Mattias Engdegård wrote: And if you would agree to that, why should we deny others the same benefits? For the same reason that I'd deny them the dubious benefit of, e.g., the following: nepredznačeno celo_št

Re: [PATCH] Re-localise conflict prompt

12 apr 2013 kl. 19.52 skrev Daniel Shahaf: On Fri, Apr 12, 2013 at 07:44:23PM +0200, Mattias Engdeg?rd wrote: This is about a user being asked a question in her native language and given a set of answers labelled in that language. Why force her to reply in a code dissonant to those answers?

Re: [PATCH] Re-localise conflict prompt

12 apr 2013 kl. 20.33 skrev Mattias Engdegård: To make progress, I'll prepare another patch that avoids this particular point of disagreement. And here it is. Now the (unlocalised) --accept options are explicitly shown in the long help, but not the prompt labels, since they are redu

[PATCH] Avoid warning when char is unsigned

This trivial non-essential patch avoids a warning when building with - Wall. [[[ Avoid a "condition always true" warning on platforms where char is unsigned by default, such as PowerPC and ARM. * subversion/libsvn_subr/utf_validate.c (first_non_fsm_start_char, first_non_fsm_start_char_cstring

Re: [PATCH] Re-localise conflict prompt

13 apr 2013 kl. 01.31 skrev Daniel Shahaf: Please use text/* MIME type for attachments. Yes, sorry about that; the same patch attached, properly typed this time. The short codes ("mc", "mf", etc) are also valid as arguments to -- accept. Perhaps mention that? I did consider that, but d

[PATCH] Proper plural localisation of conflict summary

This is a good example of how a string that does not distinguish between singular and plural in English still needs to be localised in a number-aware way: SVN_ERR(svn_cmdline_printf(scratch_pool, _(" Text conflicts: %d remaining (and %d already resolved) \n"), n_te

Re: [PATCH] Proper plural localisation of conflict summary

13 apr 2013 kl. 23.47 skrev Daniel Shahaf: Mattias Engdegård wrote on Sat, Apr 13, 2013 at 23:27:41 +0200: + SVN_ERR(svn_cmdline_printf(pool, _(" %s: %s (%s)\n"), + prefix, remaining, resolved)); Why is this marked for translation? To allow for var

Re: [PATCH] Proper plural localisation of conflict summary

14 apr 2013 kl. 03.57 skrev Daniel Shahaf: We don't usually translate strings that don't contain alphanumerics. If you want to translate those, no opinion here either way, but you'll probably find a fair number of strings around the codebase to add _() around. As you wish. I just noted this

Bug in conflict summary after partial resolution

If a file has both text and property conflicts, only resolving one of them leads to an incorrect conflict summary message. Example: $ svnadmin create repo $ svn co file://$PWD/repo d1 $ svn co file://$PWD/repo d2 $ cd d1 $ echo a > f; svn add f; svn ps p x f $ svn ci -m m $ cd ../d2 $ echo b >

Incorrect UTF-8-smashing of conflict localisations

When a property conflict is presented, some localised messages will be mutilated. Example (French locale): Actualisé à la révision 1. Conflit sur la propriété 'p' découvert sur 'f'. Tentative de d'ajout d'une nouvelle propri?\195?\169t?\195?\169 'p' mais elle existe d?\195?\169j?\195?\160.

[PATCH] Missing newline in propset error message

There is a missing newline in the error when propset is used on a nonexisting file: $ svn ps a b file 'file' is not under version controlsvn: E155010: The node '/tmp/d1/ file' was not found. Here is a patch. (I didn't add a newline to the string directly since it occurs in many places.)

Re: [PATCH] Missing newline in propset error message

14 apr 2013 kl. 16.19 skrev Mattias Engdegård: Here is a patch. (I didn't add a newline to the string directly since it occurs in many places.) Committed as r1467803, kindly approved by Ben Reser.

Re: [PATCH] Avoid warning when char is unsigned

15 apr 2013 kl. 14.45 skrev Philip Martin: Avoid a "condition always true" warning on platforms where char is unsigned by default, such as PowerPC and ARM. Looks correct, +1 Thanks - committed as r1468255.

Re: [PATCH] Proper plural localisation of conflict summary

14 apr 2013 kl. 19.35 skrev Ben Reser: Agreed I really don't see any reason not to fix these. Yes we've been sloppy with these sorts of localization issues in the past, doesn't mean we should continue to do so. So, what about applying, approving or rejecting the patch? (The one of http://svn.

Re: [PATCH] Proper plural localisation of conflict summary

16 apr 2013 kl. 20.28 skrev C. Michael Pilato: So, what about applying, approving or rejecting the patch? (The one of http://svn.haxx.se/dev/archive-2013-04/0339.shtml) It's required for at least one translation and very likely for several more. It does not change the English output in any wa

Re: _("%s: %s\n") was: Re: [PATCH] Proper plural localisation of conflict summary

17 apr 2013 kl. 00.39 skrev Daniel Shahaf: Nice. I suppose that means we now have a bunch of places where _() should be added --- such as svn_cl__info_print_time(). I am not quite sure how to find all of them, other than by using a finished translation and then looking for English or mis-pu

Re: [PATCH] Re-localise conflict prompt

This version of the patch is like the previous one, but the prompt labels have been translated into English as well. This makes them more descriptive and easier to understand. As an extra added benefit, it makes them easier to translate unambiguously, in particular single short words like "

[PATCH] Make h and ? work at the conflict prompt

The conflict help text says (s) - show this list (also 'h', '?') but h and ? don't actually work. Here is a patch. [[[ Make "h" and "?" work at the conflict prompt as promised by the help text. * subversion/svn/conflict-callbacks.c (prompt_user): Test for "h" and "?" before calling fin

Re: log --search test failures on trunk and 1.8.x

20 apr 2013 kl. 12.27 skrev Stefan Sperling: W: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c(68) : Assertion failed: (unsigned)(c + 1) <= 256 ]]] Seems like a bogus check to me. Is there a notion of debug vs. release builds in Visual Studio, and if so, does this happen in release mode buil

Re: log --search test failures on trunk and 1.8.x

21 apr 2013 kl. 20.07 skrev Branko Čibej: Yes, the obvious ones are German (ß == SS) equivalence and turkic (i == İ) and (ı == I) equivalences (and that's aready three characters); but then in French, lowercase accented letters are equivalent to uppercase unaccented letters, whereas for exam

Re: sqlite3.c won't compile with -std=c89

25 mar 2013 kl. 23.03 skrev Mattias Engdegård: [[[ Work around a problem on older OS X systems: sqlite3.c includes , which uses 'inline' and thus cannot be compiled with -std=c89 that we are using for all files. * subversion/libsvn_subr/sqlite3wrapper.c (toplevel): Define &

Make option parsing error messages translatable

It is quite annoying that some of the more common error messages, the svn: invalid option: --gurgle kind, are entirely untranslatable because they are printed directly by APR which does not have any concept of translation at all. (This was reported before but met with silence: http://svn.hax

Re: Updated Swedish translation

3 maj 2013 kl. 00.49 skrev janI: I looked at the patch, and found a single item which I think should be changed. Many thanks! you translate "bogus" with "felaktig", in my opion that is too strong..."bogus" does not really mean "Error" but something like "we do not understand what you w

Re: Updated Swedish translation

2 maj 2013 kl. 02.12 skrev Daniel Shahaf: Thanks for this work, Mattias. Is the "Project-Id-Version: subversion 1.7" header correct? Thanks for spotting it - I don't think that string matters in any way, but I changed it (to 1.8) before committing the translation.

Re: Make option parsing error messages translatable

3 maj 2013 kl. 16.10 skrev Daniel Shahaf: It's a hack. It hardcodes the specific first and third arguments to the (os->errfn)("%s: %s: %c\n", _, "invalid option", _); call in APR's unix/getopt.c. The only benefit we get in return is translating six two-word error messages in option parsin

Re: svn commit: r1479268 - /subversion/trunk/subversion/po/sv.po

5 maj 2013 kl. 22.20 skrev Daniel Shahaf: * subversion/po/sv.po: Fix bad spacing (found by Per Larsson) Should you use the parseable crediting syntax here? Thank you, this has now been corrected.

Re: Updated Swedish translation

4 maj 2013 kl. 13.20 skrev Daniel Shahaf: On Sat, May 04, 2013 at 01:12:42PM +0200, Mattias Engdeg?rd wrote: 2 maj 2013 kl. 02.12 skrev Daniel Shahaf: Thanks for this work, Mattias. Is the "Project-Id-Version: subversion 1.7" header correct? Thanks for spotting it - I don't think that stri

Re: Make option parsing error messages translatable

6 maj 2013 kl. 23.39 skrev Daniel Shahaf: The patch achieves its end in an unmaintainable way. It's liable to break when APR's implementation details change, and since it ultimately attempts to parse something which wasn't intended to be parsed, it might do the _wrong_ thing (as opposed to

Re: Make option parsing error messages translatable

7 maj 2013 kl. 01.00 skrev Daniel Shahaf: Of course there is, if someday APR uses "invalid option" in another meaning than the one this patch assumes it does. Believe it or not, that is already how gettext translation works. If you think that really is a problem, then Subversion has got it i

Re: Make option parsing error messages translatable

8 maj 2013 kl. 15.34 skrev Stefan Sperling: I think this problem should be fixed in APR. APR should provide some official way of translating error messages. I agree. While it would be easy to do technically, getting such a change accepted into APR, a new APR release to be made, and a new S

Re: Make option parsing error messages translatable

8 maj 2013 kl. 14.57 skrev Daniel Shahaf: Apples and oranges. The issue you're talking about is that _("hello world") would have to be translated differently in two places within our code. Your patch potentially uses _() either on string literals from APR's future code (which, unlike string

Re: Incorrect UTF-8-smashing of conflict localisations

14 apr 2013 kl. 14.20 skrev Mattias Engdegård: When a property conflict is presented, some localised messages will be mutilated. This patch fixes the bug. [[[ When generating the .prej file for property conflicts, don't destroy the inserted localised strings by converting the entire fi

Re: Incorrect UTF-8-smashing of conflict localisations

12 maj 2013 kl. 18.18 skrev Stefan Sperling: This patch fixes the bug. +1, thanks. Committed in r1481981.

Re: svn commit: r1483292 - in /subversion/trunk/subversion: include/private/svn_string_private.h libsvn_subr/string.c libsvn_subr/types.c

16 maj 2013 kl. 12.38 skrev Stefan Fuhrmann: Measurement was done on the server side (network and client are not a bottleneck for log -g, yet). The server has to parse through appox. 2GB of svn:mergeinfo. In contrast to strtoul, this code lacks an overflow check. Presumably that was intended

[PATCH] SVN_UNALIGNED_ACCESS_IS_OK for ppc

[[[ * subversion/include/svn_types.h: Set SVN_UNALIGNED_ACCESS_IS_OK for PowerPC. ]]] Index: subversion/include/svn_types.h === --- subversion/include/svn_types.h (revision 1483563) +++ subversion/include/svn_types.h (work

over-tolerant code in run_file_install?

When trying to consolidate file copying into svn_io_copy_file, I ran into the code around workqueue.c:590 which derailed my plans somewhat: /* With a single db we might want to install files in a missing directory. Simply trying this scenario on error won't do any harm and at lea

Re: over-tolerant code in run_file_install?

20 maj 2013 kl. 22.41 skrev Daniel Shahaf: Have you checked IRC logs for the day r1142088 was committed on? Thanks for the reference. As far as I can make out from the conversation, the change was made in order to handle working copies whose directory structure had been trashed by the user

Re: over-tolerant code in run_file_install?

21 maj 2013 kl. 12.02 skrev Bert Huijben: Before we had a single DB we stored the workqueue items per directory. (We had a wc.db per directory, just like the old entries). If the workqueue contained an item that specified to install an item in the directory we could safely assume that the

Re: Crashes in 1.8.0 test suite on Solaris Sparc (wrong alignment in cache_lookup())

20 jun 2013 kl. 16.54 skrev Ivan Zhakov: It seems the code is missing #ifdef SVN_UNALIGNED_ACCESS_IS_OK . The attached patch should fix problem, but I'm not sure that this is right solution for the problem. Assuming the hash function does not need to be portable (which appears likely from a

Re: Crashes in 1.8.0 test suite on Solaris Sparc (wrong alignment in cache_lookup())

20 jun 2013 kl. 21.44 skrev Stefan Fuhrmann: A capable compiler should unroll the inner loop such that we end up with ~10 cycles / 4 bytes. That would be slightly faster than the "* 33" loop. That depends on a lot of things (such as the latency/throughput of the multiplier). By the way, th

Re: Crashes in 1.8.0 test suite on Solaris Sparc (wrong alignment in cache_lookup())

21 jun 2013 kl. 00.32 skrev Stefan Fuhrmann: After some IRC discussion, we added r1495209 which provides actual platform-independence. With the messy code and extra htonl() call cost where not inlined, I doubt it's worth it. I'd just #if out the 4-byte acceleration as originally proposed (

Re: localisation: status, migration to pootle

2 aug 2013 kl. 21.27 skrev Andreas Stieger: I would like to hear from active translation maintainers if they are happy to move their respective translations into Pootle and work on that system. If so I am willing to coordinate the import, even if just for trying it out. With sufficient suppor

Re: localisation: status, migration to pootle

8 aug 2013 kl. 08.21 skrev Daniel Shahaf: Mattias Engdegård wrote on Wed, Aug 07, 2013 at 23:43:36 +0200: Sorry about the late reply; I rarely have time to read the development list. It seems unlikely that many translators do - how are they notified about the need to update their

Re: man pages for Subversion

12 aug 2013 kl. 12.38 skrev Julian Foad: Hi James. I have one thing to throw into the mix, which you might be interested in looking at. I experimented a few months ago with generating both the C help strings and man pages from an XML source file. My patch to do this is attached; it is co

Re: localisation: status, migration to pootle

8 aug 2013 kl. 20.39 skrev Daniel Shahaf: Should we retroactively send a round of "Hey, 1.8.x has been released, please update translations on trunk and 1.8.x" ? That is probably a good idea, and since it isn't going to happen by itself, I shall do that myself this time. This does not mean t

Re: localisation: status, migration to pootle

14 aug 2013 kl. 21.37 skrev Ben Reser: It would be better to put something in the docs now and then we can automate later. Would this do? [[ * publish/docs/community-guide/releasing.part.html, publish/docs/community-guide/releasing.toc.html: Add section about notifying translators. ]] In

Re: localisation: status, migration to pootle

15 aug 2013 kl. 00.10 skrev Ben Reser: +1, please go ahead and commit. Thank you, done in r1514395.

Re: Call for translations: Subversion 1.8

15 aug 2013 kl. 08.54 skrev Fabien COELHO: Sure I can do it, but it will take some time. Is there some kind of time frame? Say "by the end of the month" would be a nice:-) The 1.8.2 release is pending and may take place sooner than that; I have not heard of a fixed date for it, however. Tak

APR_UINT64_FMT_T in localised format strings

Localised strings must consist entirely of literals; they cannot contain preprocessor macros. For example, svnserve/serve.c:2234 has return svn_error_createf(SVN_ERR_RA_SVN_MALFORMED_DATA, NULL, _("Invalid move_behavior value %" AP

Re: localisation: status, migration to pootle

Sorry about resuming an old thread, but since most translations are not kept up to date, what about switching to the Translation Project instead? There are experienced teams for the languages that Subversion is currently translated into and many more. The risk for orphaned localisations w

Re: localisation: status, migration to pootle

22 feb 2014 kl. 13.57 skrev Mattias Engdegård: Sorry about resuming an old thread, but since most translations are not kept up to date, what about switching to the Translation Project instead? Given the lack of response, the conclusion is that there is no interest for such a migration

Switch to Translation project for Subversion?

[sent to current Subversion translators as listed in COMMITTERS] This is a proposal to use the Translation project for the Subversion translations, since most of the existing ones have not been kept up to date. There are experienced teams for the languages that Subversion is currently tra

Re: Switch to Translation project for Subversion?

12 mar 2014 kl. 09.22 skrev Lübbe TortoiseSVN: I'd like to make another suggestion: at TortoiseSVN we switched to transifex.com a few years ago and we are very happy with it. If Subversion moved there, I'd help with the translations again. Both projects could profit from synergies. Apolog

Re: Switch to Translation project for Subversion?

25 apr 2014 kl. 17.37 skrev Julian Foad: We should run the po-update script regularly, to find such problems early. It's quick, so I don't see why we should not run it as part of a default build, if the relevant dependencies are found on the system. Then the distribution script won't need

Re: String formatting with APR_INT64_T etc. & gettext localization

25 apr 2014 kl. 18.53 skrev Julian Foad: 1. Use PRIu64 etc. from . Good, if you can get it all to work on Windows. 2. Use a helper function to format an integer as a string; insert the result with "%s". Probably the most practical solution for the time being. 3. Double-formatting, using

Re: Switch to Translation project for Subversion?

26 apr 2014 kl. 08.03 skrev 宋冬生: I'm worry about the license issue, snippet from http://translationproject.org/html/welcome.html: *** translators need to disclaim the copyright on their translations for the FSF *** That text is incomplete or obsolete; each package maintainer decides whether

Re: String formatting with APR_INT64_T etc. & gettext localization

1. Use PRIu64 etc. from . Good, if you can get it all to work on Windows. No problem with a bit of configury magic. See for example . Perhaps – I was mainly thinking about gettext and its runtime. A non- standard build of it may be required then. (I

Re: String formatting with APR_INT64_T etc. & gettext localization

1 maj 2014 kl. 08.13 skrev Dongsheng Song: _("The repository trunk version is %"PRId64".") Will translate to: _("The repository trunk version is %lld.") // ILP32 _("The repository trunk version is %I64d.") // MSVC _("The repository trunk version is %ld.") // LP64 No, gettext recognises stand

[PATCH] generate subversion.pot in dist.sh

Translators will need the subversion.pot file; it should be present in the source distribution. Presumably, the right way to ensure that is to have dist.sh generate it, similar to the way the configure script is created. [[[ Have dist.sh generate subversion.pot for the benefit of translator

Re: [PATCH] generate subversion.pot in dist.sh

Sorry about the reminder, but are there any objections to the patch or could it be applied? I have received no comments on it, but perhaps the Apache mail server gremlins swallowed them. 6 maj 2014 kl. 23.52 skrev Mattias Engdegård: Translators will need the subversion.pot file; it should

Re: [PATCH] fix potentially undefined operation warning

16 maj 2014 kl. 19.24 skrev Andreas Stieger: I think he has. Further, the call is to svn__base36toui64() which, if I read correctly, uses the pointer as a return, e.g. in this case it does not matter whether the first parameter was incremented. Never versions of gcc might detect this and no

Re: Subversion 1.7.0 GO / NO-GO

I suppose we could recommend --disable-nonportable-atomics in the release notes. It is undetermined at this time whether Windows 64-bit is affected. Win64 should be safe.

Re: Translation of Subversion

6 mars 2018 kl. 14.00 skrev Julian Foad : > > > What really needs to be done to make life for translators somewhat bearable > > is to split the long strings into individual paragraphs; this is standard > > practice. Right now, even if only a single word has changed in the > > documentation of "

Re: [PATCH] Split long strings into paragraphs to ease translation

6 mars 2018 kl. 23.38 skrev Branko Čibej : > > I have trouble understanding this approach. It forces translators to use > the same paragraph structure as the original text. This may not make any > sense for the target language. Yes, I too had similar concerns when I first came across it, but it h

Re: [PATCH] Split long strings into paragraphs to ease translation

6 mars 2018 kl. 23.09 skrev Julian Foad : > > The attached patch "split-long-strings-1.patch" (unfinished; see included log > message) puts code in place to achieve this for 'svn' help, and demonstrates > by splitting the 'svn log' and 'svn merge' strings. In print_command_info3: + for (i

Re: [PATCH] Split long strings into paragraphs to ease translation

9 mars 2018 kl. 15.37 skrev Julian Foad : > > Completed (initially) in r1826352. Help strings are split into paragraphs (at > their existing blank lines in fact) across most but not all 'svn*' > command-line tools. Thank you! > Can you try it and see if it seems to be working, Mattias? Will d

Re: [PATCH] Split long strings into paragraphs to ease translation

9 mars 2018 kl. 15.37 skrev Julian Foad : > > Now let's see what follow-up we need. > > Can you try it and see if it seems to be working, Mattias? Done, and it seems to work well. Some observations: * As expected, lots of work to split the translated messages, although having a mostly up-to-da

Re: [PATCH] Split long strings into paragraphs to ease translation

13 mars 2018 kl. 10.30 skrev Julian Foad : > >> * The split into separate messages was done at empty line boundaries >> throughout, but for very short paragraphs (1-2 lines), it would have been >> more helpful to bunch a few of them together in order to get better context. >> * Conversely, some

msguniq in po-update.sh

Sorry about messing up the build with my ill-considered merge of r1841318 (sv.po). Instead of attempting to merge from 1.11.x, which is what caused the duplicated msgids, I should just have copied the entire file from that branch and be done with it. That was just careless on my part. However,

Re: [PATCH] generate subversion.pot in dist.sh

20 maj 2014 kl. 17.57 skrev Ben Reser: Why should the pot file be present in the distribution package? Shouldn't translators be working against a SVN checkout and not a distribution package? The goal is to permit us to use a different translation model, where translators aren't working d

Re: [PATCH] generate subversion.pot in dist.sh

20 maj 2014 kl. 23.11 skrev Ben Reser: That seems like a really strange workflow to me. If translators are dependent on source distributions how are we supposed to have translations done for upcoming unreleased changes? I think we can come up with a better way of doing this than includin

Re: [PATCH] generate subversion.pot in dist.sh

ource distribution, like many other projects do (in particular those using TP, where it is standard procedure), shouldn't be much to argue about, should it? 21 maj 2014 kl. 22.36 skrev Mattias Engdegård: 20 maj 2014 kl. 23.11 skrev Ben Reser: That seems like a really strange workflow

Re: [PATCH] generate subversion.pot in dist.sh

9 jun 2014 kl. 22.02 skrev Ben Reser: With respect to Subversion for minor releases you can obviously use the release candidates. For patch releases you don't get release candidate tarballs. Once we've produced a tarball there isn't any opportunity to change anything. String changes are n

Move contrib/client-side/emacs/dsvn.el off the svn tree

After being abandoned for quite some time, dsvn.el will now become a proper MELPA package under a new maintainer at https://github.com/rosbo018/dsvn.el . Would someone please remove contrib/client-side/emacs/dsvn.el from the svn tree?

Re: Move contrib/client-side/emacs/dsvn.el off the svn tree

30 okt. 2022 kl. 16.55 skrev Daniel Sahlberg : > On second thoughts (and after suggestion by hartmannathan on IRC [1]), I > think we should keep the file frozen in time but clearly indicate that it is > out of date and that the current version can be found elsewhere. I've > committed this as r1