[PATCH] extend svn_subst_translate_string() to record whether re-encoding and/or line ending translation were performed
Following Daniel Shahaf's suggestion of splitting the "allow svnsync to translate non-UTF-8 log messages to UTF-8" work into two patches, I have revised my changes, prepared one of the two patches, and have attached the one patch and suggested log message to this e-mail. Adds a public API function, svn_subst_translate_string2(), an extension of svn_subst_translate_string(), that has two, additional output parameters for determining whether re-encoding and/or line ending translation were performed. As discussed at: http://thread.gmane.org/gmane.comp.version-control.subversion.user/100020 http://thread.gmane.org/gmane.comp.version-control.subversion.devel/122518 http://thread.gmane.org/gmane.comp.version-control.subversion.devel/122550 * subversion/include/svn_subst.h (svn_subst_translate_string2): New function. (svn_subst_translate_string): Deprecated in favor of svn_subst_translate_string2(). * subversion/libsvn_subr/subst.c (translate_newline): Added the new parameter EOL_TRANSLATED, the value at which is set to TRUE if translate_newline() wrote out the line ending in NEWLINE_BUF with a different line ending in EOL_STR. (translation_baton): Added the TRANSLATED_EOL field. (create_translation_baton): Added a new parameter TRANSLATED_EOL that is passed to the resulting translation_baton. (translate_chunk): Modified the three calls to translate_newline() to pass the TRANSLATED_EOL pointer from the translation baton. (stream_translated): New static function. Its implementation is the old implementation of svn_subst_stream_translated(), but accepting another parameter, TRANSLATED_EOL, that is passed to the in/out translation batons that it creates. (svn_subst_stream_translated): Now a wrapper for stream_translated(). (translate_cstring2): New static function. Its implementation is the old implementation of svn_subst_translate_cstring2(), but modified to accept another parameter, TRANSLATED_EOL, that is passed to stream_translated(). (svn_subst_translate_cstring2): Now a wrapper for translate_cstring2(). (svn_subst_translate_string2): New function. The task of recording whether it translated a line ending is delegated to translate_cstring2(). Index: subversion/include/svn_subst.h === --- subversion/include/svn_subst.h (revision 1003341) +++ subversion/include/svn_subst.h (working copy) @@ -588,16 +588,41 @@ svn_subst_stream_detranslated(svn_stream_t **strea /* EOL conversion and character encodings */ -/** Translate the data in @a value (assumed to be in encoded in charset +/** @deprecated Provided for backward compatibility with the 1.6 API. Callers + * should use svn_subst_translate_string2(). + * + * Translate the data in @a value (assumed to be encoded in charset * @a encoding) to UTF8 and LF line-endings. If @a encoding is @c NULL, * then assume that @a value is in the system-default language encoding. * Return the translated data in @a *new_value, allocated in @a pool. */ +SVN_DEPRECATED svn_error_t *svn_subst_translate_string(svn_string_t **new_value, const svn_string_t *value, const char *encoding, apr_pool_t *pool); +/** Translate the data in @a value (assumed to be encoded in charset + * @a encoding) to UTF8 and LF line-endings. If @a encoding is @c NULL, + * then assume that @a value is in the system-default character encoding. + * If @a translated_to_utf8 is not @c NULL, then + * @code *translated_to_utf8 @endcode is set to @c TRUE if at least one + * character of @a value in the source charset was translated to UTF-8; to + * @c FALSE otherwise. If @a translated_line_endings is not @c NULL, then + * @code *translated_line_endings @endcode is set to @c TRUE if at least one + * line ending was changed to LF; to @c FALSE otherwise. Return the translated + * data in @a *new_value, allocated in @a pool. + * + * @since New in 1.7 + */ +svn_error_t * +svn_subst_translate_string2(svn_string_t **new_value, +svn_boolean_t *translated_to_utf8, +svn_boolean_t *translated_line_endings, +const svn_string_t *value, +const char *encoding, +apr_pool_t *pool); + /** Translate the data in @a value from UTF8 and LF line-endings into * native locale and native line-endings, or to the output locale if * @a for_output is TRUE. Return the translated data in @a Index: subversion/libsvn_subr/subst.c === --- subversion/libsvn_subr/subst.c (revision 1003341) +++ subversion/libsvn_subr/subst.c (working copy) @@ -628,7 +628,8 @@ translate_newline(const char *eol_str, char *newline_buf,
RE: trunk failing tests on Windows XP (32 bit): prop-tests.py 33, stat-tests.py 5, upgrade-tests.py 11
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: vrijdag 1 oktober 2010 1:51 > To: Subversion Development > Subject: trunk failing tests on Windows XP (32 bit): prop-tests.py 33, > stat-tests.py 5, upgrade-tests.py 11 > > Hi devs, > > The following tests fail on my machine (Windows XP 32-bit, built with > VCE 2008, ra_local): > > - prop-tests.py 33: test properties of obstructed subdirectories > svn: Can't open directory > 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin > e\svn-test-work\working_copies\prop_tests-33\A\C': > The directory name is invalid. > > - stat-tests.py 5: status on versioned items whose type has changed > svn: Can't open directory > 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin > e\svn-test-work\working_copies\stat_tests-5\A': > The directory name is invalid. > > - upgrade_tests.py 11: missing directories and obstructing files > svn: Can't open directory > 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdlin > e\svn-test-work\working_copies\upgrade_tests-11\A\D': > The directory name is invalid. > > They all seem to try to open some path as a directory, but it isn't a > directory (but an empty file or something). > > Am I the only one seeing this? Is this known/normal? This seems to be related to the APR version you use. (Paul Burba reported this same problem earlier this week). Bert
trunk failing tests on Windows XP (32 bit): prop-tests.py 33, stat-tests.py 5, upgrade-tests.py 11
Hi devs, The following tests fail on my machine (Windows XP 32-bit, built with VCE 2008, ra_local): - prop-tests.py 33: test properties of obstructed subdirectories svn: Can't open directory 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies\prop_tests-33\A\C': The directory name is invalid. - stat-tests.py 5: status on versioned items whose type has changed svn: Can't open directory 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies\stat_tests-5\A': The directory name is invalid. - upgrade_tests.py 11: missing directories and obstructing files svn: Can't open directory 'C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\working_copies\upgrade_tests-11\A\D': The directory name is invalid. They all seem to try to open some path as a directory, but it isn't a directory (but an empty file or something). Am I the only one seeing this? Is this known/normal? Please find the fail log files in attachment. Cheers, -- Johan [[[ CMD: svnadmin.exe create "svn-test-work\repositories\prop_tests-33" --bdb-txn-nosync "--fs-type=fsfs" CMD: svnadmin.exe dump svn-test-work\local_tmp\repos | svnadmin.exe load svn-test-work\repositories\prop_tests-33 --ignore-uuid CMD: svn.exe co file:///C:/research/svn/client_build/svn_trunk/Release/subversion/tests/cmdline/svn-test-work/repositories/prop_tests-33 "svn-test-work\working_copies\prop_tests-33" --config-dir "C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config" --password rayjandom --no-auth-cache --username jrandom Asvn-test-work\working_copies\prop_tests-33\A Asvn-test-work\working_copies\prop_tests-33\A\B Asvn-test-work\working_copies\prop_tests-33\A\B\lambda Asvn-test-work\working_copies\prop_tests-33\A\B\E Asvn-test-work\working_copies\prop_tests-33\A\B\E\alpha Asvn-test-work\working_copies\prop_tests-33\A\B\E\beta Asvn-test-work\working_copies\prop_tests-33\A\B\F Asvn-test-work\working_copies\prop_tests-33\A\mu Asvn-test-work\working_copies\prop_tests-33\A\C Asvn-test-work\working_copies\prop_tests-33\A\D Asvn-test-work\working_copies\prop_tests-33\A\D\gamma Asvn-test-work\working_copies\prop_tests-33\A\D\G Asvn-test-work\working_copies\prop_tests-33\A\D\G\pi Asvn-test-work\working_copies\prop_tests-33\A\D\G\rho Asvn-test-work\working_copies\prop_tests-33\A\D\G\tau Asvn-test-work\working_copies\prop_tests-33\A\D\H Asvn-test-work\working_copies\prop_tests-33\A\D\H\chi Asvn-test-work\working_copies\prop_tests-33\A\D\H\omega Asvn-test-work\working_copies\prop_tests-33\A\D\H\psi Asvn-test-work\working_copies\prop_tests-33\iota Checked out revision 1. CMD: svn.exe propset red blue "svn-test-work\working_copies\prop_tests-33\A\C" --config-dir "C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config" --password rayjandom --no-auth-cache --username jrandom property 'red' set on 'svn-test-work\working_copies\prop_tests-33\A\C' CMD: svn.exe proplist --verbose --xml "svn-test-work\working_copies\prop_tests-33\A" "svn-test-work\working_copies\prop_tests-33\A\B\E\beta" "svn-test-work\working_copies\prop_tests-33\A\D" "svn-test-work\working_copies\prop_tests-33\A\C" "svn-test-work\working_copies\prop_tests-33\A\B" "svn-test-work\working_copies\prop_tests-33\A\D\G\tau" "svn-test-work\working_copies\prop_tests-33\A\D\G\rho" "svn-test-work\working_copies\prop_tests-33\A\D\G\pi" "svn-test-work\working_copies\prop_tests-33\A\D\H\psi" "svn-test-work\working_copies\prop_tests-33\A\mu" "svn-test-work\working_copies\prop_tests-33\A\D\G" "svn-test-work\working_copies\prop_tests-33\A\D\H\omega" "svn-test-work\working_copies\prop_tests-33\A\D\H\chi" "svn-test-work\working_copies\prop_tests-33\A\B\F" "svn-test-work\working_copies\prop_tests-33\A\B\E" "svn-test-work\working_copies\prop_tests-33\A\B\E\alpha" "svn-test-work\working_copies\prop_tests-33\A\B\lambda" "svn-test-work\working_copies\prop_tests-33\A\D\H" "svn-test-work\working_copies\prop_tests-33\iota" "svn-test-work\working_copies\prop_tests-33\A\D\gamma" "svn-test-work\working_copies\prop_tests-33" --config-dir "C:\research\svn\client_build\svn_trunk\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config" --password rayjandom --no-auth-cache --username jrandom blue CMD: svn.exe proplist --verbose --xml "svn-test-work\working_copies\prop_tests-33\A" "svn-test-work\working_copies\prop_tests-33\A\B\E\beta" "svn-test-work\working_copies\prop_tests-33\A\D" "svn-test-work\working_copies\prop_tests-33\A\B\E\alpha" "svn-test-work\working_copies\prop_tests-33\A\B" "svn-test-work\working_copies\prop_tests-33\A\D\G\tau" "svn-test-work\working_copies\prop_tests-33\A\D\G\rho" "svn-test-work\working_copies\prop_tests-33\A\D\G\pi" "svn-test-work\working_copies\prop_tests-33\A\D\
Re: svn commit: r1003227 - /subversion/site/publish/docs/community-guide/releasing.part.html
s...@apache.org wrote on Thu, Sep 30, 2010 at 20:05:54 -: > +++ subversion/site/publish/docs/community-guide/releasing.part.html Thu Sep > 30 20:05:53 2010 > @@ -1096,7 +1096,7 @@ manager.) > - > + > How not to make a Subversion release What is the effect of this change? I don't see any reference in the CSS, etc, to an "h2" or "h3" class?
Re: svn commit: r1003211 - /subversion/trunk/tools/dev/unix-build/Makefile.svn
> + @echo "perl: `perl -version | grep ^This | cut -d' ' -f4 | sed -e > 's/^v//'`" Simpler: perl -V:version
disallow merges into mixed-rev WCs by default?
I'd like to propose that we disallow merges into mixed-revision working
copies by default for 1.7, and only allow such merges if a special command
line option has been passed.
The reason for this is that merges into mixed-rev WCs can easily create
conflicts which are tedious to resolve. Even if you know about the problem
and try to run "svn update" before every merge, it's quite easy to forget
about running "svn update".
Also, we've been advertising this as best practice for some time.
Quoting the book on the matter:
Never merge into working copies with a mixture of working revision
numbers, or with “switched” subdirectories (as described next in the
section called “Traversing Branches”). A merge target should be a
working copy which represents a single location in the repository at a
single point in time.
Note that while the book recommends not to merge into working copies
with switched subtrees, I don't intend to enforce this by default.
I've talked about this with Paul on IRC and he had no objections.
See http://colabti.org/irclogger/irclogger_log/svn-dev?date=2010-09-30#l468
for the full discussion.
Below is a work-in-progress diff that starts making this change.
Tests fail with it. I've only checked the merge tests for now.
Before continuing with this, fixing up tests, bumping APIs, and eventually
adding the command line option that allows merges into mixed-rev WCs,
I'd like to ask whether anyone has concerns about this idea.
Below is the list of currently failing merge tests, and the
work-in-progress diff.
Thanks,
Stefan
FAIL: merge_tests.py 1: performing a merge, with mixed results
FAIL: merge_tests.py 9: merge change into unchanged binary file
FAIL: merge_tests.py 15: merge should skip over unversioned obstructions
FAIL: merge_tests.py 16: merge into missing must not break working copy
FAIL: merge_tests.py 23: merge between branches (Issue #)
FAIL: merge_tests.py 31: merge a replacement of a file to mixed rev wc
FAIL: merge_tests.py 32: ignore whitespace when merging
FAIL: merge_tests.py 33: ignore eolstyle when merging
FAIL: merge_tests.py 44: merge to path with switched children
FAIL: merge_tests.py 69: subtrees added after start of merge range are ok
FAIL: merge_tests.py 70: cyclic merges don't add mergeinfo from own history
FAIL: merge_tests.py 77: merges that remove all mergeinfo work
FAIL: merge_tests.py 89: target and subtrees need nonintersecting revs
FAIL: merge_tests.py 90: merge two successive edits to the same property
FAIL: merge_tests.py 91: merge an EOL unification and set svn:eol-style
FAIL: merge_tests.py 103: automatic conflict resolutions work with merge
FAIL: merge_tests.py 105: committed case only move causes revert to fail
FAIL: merge_tests.py 107: merge del and ps variants from a foreign repos
FAIL: merge_tests.py 111: merge into locally added file
FAIL: merge_tests.py 112: merge into locally added directory
Index: subversion/libsvn_client/merge.c
===
--- subversion/libsvn_client/merge.c(revision 1003282)
+++ subversion/libsvn_client/merge.c(working copy)
@@ -8815,6 +8815,54 @@ merge_cousins_and_supplement_mergeinfo(const char
return SVN_NO_ERROR;
}
+/* Perform checks to determine whether of the working copy at TARGET_ABSPATH
+ * can safely be used as a merge target. Checks are performed according to
+ * the FORBID_MIXED_REV, FORBID_LOCAL_MODS, and FORBID_SWITCHED_SUBTREES
+ * parameters. If any checks fail, raise SVN_ERR_CLIENT_NOT_READY_TO_MERGE.
+ *
+ * E.g. if all the FORBID_* parameters are TRUE, TARGET_ABSPATH must
+ * be a single-revision, pristine, unswitched working copy.
+ * In other words, it must reflect a subtree of the repostiory as found
+ * at single revision -- although sparse checkouts are permitted. */
+static svn_error_t *
+ensure_wc_is_suitable_merge_target(const char *target_abspath,
+ svn_client_ctx_t *ctx,
+ svn_boolean_t forbid_mixed_rev,
+ svn_boolean_t forbid_local_mods,
+ svn_boolean_t forbid_switched_subtrees,
+ apr_pool_t *scratch_pool)
+{
+ svn_wc_revision_status_t *wc_stat;
+
+ /* Get a WC summary with min/max revisions set to the BASE revision. */
+ SVN_ERR(svn_wc_revision_status2(&wc_stat, ctx->wc_ctx, target_abspath, NULL,
+ FALSE, ctx->cancel_func, ctx->cancel_baton,
+ scratch_pool, scratch_pool));
+
+ if (forbid_switched_subtrees && wc_stat->switched)
+return svn_error_create(SVN_ERR_CLIENT_NOT_READY_TO_MERGE, NULL,
+_("Cannot merge into a working copy "
+ "with a switched subtree"));
+
+ if (forbid_local_mods && wc_stat->modified)
+return svn_error_create(SVN_ERR_CLIENT_NOT_READY_TO_MERGE, NULL,
+
Re: Interrupting an update after change of externals causes corrupt working copy
Hi devs, As per Daniel Shahaf's suggestion, I'm continuing this discussion on the dev list. See the previous mails in this thread on the users list for some context (or http://svn.haxx.se/users/archive-2010-09/0406.shtml). I'll summarize below. This issue reproduces with 1.6.12 as well as with trunk. It would be interesting to know the WC-NG folks take on this. Note: the subject line may be slightly exaggerated, as there seems to be a good workaround to repair things (at least in case of intra-repository externals). Summary --- Steps to reproduce: 1) Change a directory external definition. 2) svn update 3) Interrupt (Ctrl-C) while it is processing the "switch" of the external. I did this after some files of the external were already Updated. Result: svn status now shows a lot of files and directories as S (switched), and some directories missing. Running svn info on the switched files/dirs shows that they still point to the old external location. Running svn update again fixes the "missing" dirs, but not the switched nodes. "svn revert" does nothing (which is logical: there are no local changes). "svn cleanup" does nothing. Workaround: Running "svn switch $new_url $external_dir" brings everything back to normal. So: - Wouldn't it be better if "svn update" could repair this (as in "resuming the interrupted update from before")? - Should I file an issue for this? - I'm not sure how all this plays out with externals from remote repositories (haven't tested this). With or without a change of the remote location. Would an "svn switch --relocate" fix things in the same way then? Note: this can be easily reproduced with any large (public) repository (I think). Just define some externals in working copy only (no need to commit), update, change external definition (no need to commit), update, interrupt. Cheers, -- Johan
Re: 1.6.13 up for signing/testing
On Wed, Sep 29, 2010 at 03:08:54PM -0500, Hyrum K. Wright wrote: > 1.6.13 tarballs are up for testing and signing. The magic revision is > r1002816: > http://people.apache.org/~hwright/svn/1.6.13/ Summary: +1 to release Tested: [bdb | fsfs] x [ra_local | ra_svn | ra_neon | ra_serf] swig bindings Test results: All passed, except: - all tests fail for perl and ruby bindings, known local issue with perl and ruby failing to locate libraries, haven't been able to figure out how to fix it - merge_test 63 over ra_serf, but it's just an output ordering problem which others cannot reproduce, discussed on IRC - transient failures which should be fixed by backporting r877814 and r991534 to 1.6.x for the next release Platform: OpenBSD 4.8 Dependencies: bdb:4.8.30 GNU-iconv: 1.13.1 apr:1.4.2 apr-util: 1.3.9 httpd: 2.2.15 neon: 0.29.3 serf: 0.7.x cyrus-sasl: 2.1.23 sqlite: 3.6.23.1 Signatures: subversion-1.6.13.tar.bz2.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (OpenBSD) iEYEABECAAYFAkyki5oACgkQ5dMCc/WdJfDmnQCgnNXf+7UscRwPeVXLbq+xqfA3 zm4AmwZIFX95lTuhMAE+9XDwRSUc4OBO =Lal6 -END PGP SIGNATURE- subversion-1.6.13.tar.gz.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (OpenBSD) iEYEABECAAYFAkyki6YACgkQ5dMCc/WdJfBc7wCeIfKLweeHEgTFwDf6Ws332D2F sT4AoKURlnNaygnfeD6c25DPkTZa1jkZ =VyQ9 -END PGP SIGNATURE- subversion-1.6.13.zip.asc: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (OpenBSD) iEYEABECAAYFAkyki7MACgkQ5dMCc/WdJfCNpwCfQsK6xe6x6eIQvyc8ylEYx8tI Q8YAnA62tq2ElxdMN5F4YtEJCb3gtCxr =/GPo -END PGP SIGNATURE-
Re: [PATCH] for building subversion 1.6.12 for haiku
scott mc writes:
> On Wed, Sep 29, 2010 at 5:45 PM, Philip Martin
> wrote:
>
>> Please write a log message:
> -
>
> This patch makes use of find_directory() on Haiku to locate the proper
> directories to use. Currently B_USER_SETTINGS_DIRECTORY points to
> /boot/home/config/settings, so this puts the .subversion directory in
> /boot/home/config/settings/subversion instead of $HOME/subversion or
> $HOME/.subversion.
We like the filename and functions to be explicitly specified:
* subversion/libsvn_subr/config_file.c
(svn_config__sys_config_path): What changed.
>>> +++ subversion/libsvn_subr/config_impl.h (working copy)
>>> @@ -114,8 +114,11 @@
>>> or svn_config_get_user_config_path() instead. */
>>> #ifdef WIN32
>>> # define SVN_CONFIG__SUBDIRECTORY"Subversion"
>>> -#else /* ! WIN32 */
>>> +#elif defined __HAIKU__ /* HAIKU */
>>> # define SVN_CONFIG__SYS_DIRECTORY "/etc/subversion"
>>
>> Should this be used in svn_config__sys_config_path?
>>
>
> I'm unclear on what SVN_CONFIG__SYS_DIRECTORY is used for. Through
> several attempts I was able to move the $HOME/.subversion directory to
> /boot/home/config/settings/subversion which fits in better with how
> Haiku stores users' settings. So I left SVN_CONFIG__SYS_DIRECTORY the
> same as other OSes for now.
Is Haiku multi-user? Does /boot/home/config/settings apply to one user
or all users?
On Linux we have /etc/subversion for per-system settings that apply to
all users, and $HOME/.subversion for per-user settings specific to
each user.
On Windows there are per-system and per-user registry settings as well
as per-system and per-user directories.
> -#else /* ! WIN32 */
> +#elif defined(__HAIKU__)
> + {
> +char folder[B_PATH_NAME_LENGTH];
>
> +status_t error = find_directory(B_USER_SETTINGS_DIRECTORY, -1, false,
> +folder, sizeof(folder));
> +if (error)
> + return SVN_NO_ERROR;
> +
> +*path_p = svn_dirent_join_many(pool, folder,
> + SVN_CONFIG__USR_DIRECTORY, fname, NULL);
> + }
> +#else /* ! WIN32 && !__HAIKU__ */
> +
>*path_p = svn_dirent_join_many(pool, SVN_CONFIG__SYS_DIRECTORY, fname,
> NULL);
>
> #endif /* WIN32 */
> @@ -1117,8 +1134,21 @@
> SVN_CONFIG__SUBDIRECTORY, fname, NULL);
>}
>
> -#else /* ! WIN32 */
> +#elif defined(__HAIKU__)
>{
> +char folder[B_PATH_NAME_LENGTH];
> +
> +status_t error = find_directory(B_USER_SETTINGS_DIRECTORY, -1, false,
> +folder, sizeof(folder));
> +if (error)
> + return SVN_NO_ERROR;
> +
> +*path = svn_dirent_join_many(pool, folder,
> + SVN_CONFIG__USR_DIRECTORY, fname, NULL);
> + }
> +#else /* ! WIN32 && !__HAIKU__ */
> +
> + {
These two functions are returning the same path. Is that what is intended?
--
Philip
Re: 1.6.13 up for signing/testing
On Wed, Sep 29, 2010 at 4:08 PM, Hyrum K. Wright wrote: > 1.6.13 tarballs are up for testing and signing. The magic revision is > r1002816: > http://people.apache.org/~hwright/svn/1.6.13/ > > As usual, signatures from full committers please send back to me. > Testing by enthusiastic users is also welcomed (but remember that this > is not yet a blessed release, with all that that implies). If you are > a package maintainer, please do not included this release in your > distribution until after it has been formally released. > > I'd like to collect all the signatures in time to do a release by October 1. VERIFIED: - Hyrum's sig for http://people.apache.org/~hwright/svn/1.6.13/obstkuchen/subversion-1.6.13.zip Other than the expected differences in svn_version.h, http://people.apache.org/~hwright/svn/1.6.13/obstkuchen/subversion-1.6.13.zip is identical to https://svn.apache.org/repos/asf/subversion/branches/1@1002816. TESTED: --- [ fsfs | bdb ] x [ file | svn | http (neon) | http (serf) ] JavaHL Bindings Ruby Bindings RESULTS: All tests pass. +1 to release. PLATFORM: - MS Windows 7 Home Premium 6.1.7600 Build 7600 Intel Core i7 M 620 2.67GHz 4 GB RAM Microsoft Visual Studio 2008 Version 9.0.30729.1 SP DEPENDENCIES: - APR: 1.4.2 APR-UTIL: 1.3.9 Neon: 0.29.3 zlib: 1.2.3 OpenSSL: 0.9.8m Apache: 2.2.15 BDB: 4.8.30 sqlite: 3.7.2 Python: ActivePython 2.6.5.14 Perl: 5.10.1 Ruby: ruby 1.8.7 java: 1.6.0_21 junit: 4.8.2 swig: 1.3.40 serf: 0.3.0 SIGNATURE: --- user: "Paul T. Burba " 1024-bit DSA key, ID 53FCDC55, created 2006-06-21 For http://people.apache.org/~hwright/svn/1.6.13/obstkuchen/subversion-1.6.13.zip: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (MingW32) iD8DBQBMpKa+2RaJMFP83FURAiviAJ0VNK0QE1IEHAY2KEiwLUjnEhWtIQCfcE8V HxcQYun5O4McVhsyBgrsINM= =Mzci -END PGP SIGNATURE- Paul
Re: 1.6.13 up for signing/testing
"Hyrum K. Wright" writes: > 1.6.13 tarballs are up for testing and signing. Summary: +1 to release. Platform: Linux (Debian/stable). Verified: signatures, MD5 checksums, SHA1 checksums only expected difference compared to tags/1.6.13 Tested: 1.6.13 tarball with local dependencies (not deps tarball) (local, svn, svn+sasl, serf, neon) x (fsfs, bdb) + swig-pl/py/rb + javahl Dependencies: subversion : 1.6.13 apache2-threaded-dev : 2.2.9-10+lenny8 libapr1-dev : 1.2.12-5+lenny2 libaprutil1-dev : 1.2.12+dfsg-8+lenny4 libdb4.6-dev : 4.6.21-11 libneon27-dev : 0.28.2-6.1 libsasl2-dev : 2.1.22.dfsg1-23+lenny1 libsqlite3-dev : 3.6.21-2~bpo50+1 perl : 5.10.0-19lenny2 python2.5-dev : 2.5.2-15+lenny1 ruby1.8-dev : 1.8.7.72-3lenny1 openjdk-6-jdk : 6b11-9.1+lenny2 serf : tags/0.7.0 Results: All tests pass. Signatures: subversion-1.6.13.tar.bz2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAABCAAGBQJMpJztAAoJEHbXiOHtGlmc2dsH/2/0en/JPvzg0TgojzCwDoA9 MU4y0ak75ROxMz1ODDOY9eRBQ5Xqu+Ev8LU0uOcTw45gkDcDYj6yxHyM7DNC+lQ7 AbZ3e1Y/dupCKVUr6jybpjeqcSYsyeJ32eQGnWYvLDogrLd19gkH8eHQp8lnJ1Gk qRMTWBXRiWH+5IlMnUrdRakFQSWZIM7O7s5pJi9/TwskszEESSficQsna73J4yHZ rqwQBIQ1Y1fAp+/qF+Vq6sbwIsLPYLuDxmfMMmr8kwuJaJ0NZG8hYuOzYDWilxRk TCzPUwGDn7Y9ybRuH3HiBORYi0R0QpwP6eSt5tEb7qx0dDuU04wmwUfv9bdr9l0= =s9uC -END PGP SIGNATURE- subversion-1.6.13.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAABCAAGBQJMpJz/AAoJEHbXiOHtGlmc94AIAIpftjgM//P7yNuhK1dqpVvq 06P3YxBfcV9MRLXVL9Fr9cbHjeI2OPNLCzF2vS3ptTZ5stxczUznvBJiRUctxyxX qXz98dbL6iKuGgdWfwk1RCKtQWhf8Y5cRET/GRb8jh5VqHzbxcDjvRZfCsqeo30j 4FeRIYikX1UROZGtPIQAN7neKHAxY0IXP7mOqbWSCs4uoQ4/1KPZZrSS4Txi9dDS zf69/jvxa4UOUOeLpMMnSg8F8PyW8btGAQY+zcnPOXtrB54xC2Pw+zVmnNbo2Orp 63Jor+EosO6EUcIuZxb14c6VPO3tXrCE1KnZaFfb95Ha7hG2fqnsoi08fFhyDwM= =uop+ -END PGP SIGNATURE- -- Philip
svnadmin verify - warnings about mergeinfo "prior to the oldest dumped revision"
Looks like the "svnadmin dump" merginfo precautions are also triggered in "verify" mode, which isn't desirable: $ svnadmin verify -r12920:HEAD svn-repo_cut-29-09-2010 * Verified revision 12920. * Verified revision 12921. * Verified revision 12922. * Verified revision 12923. * Verified revision 12924. * Verified revision 12925. * Verified revision 12926. * Verified revision 12927. * Verified revision 12928. * Verified revision 12929. WARNING: Mergeinfo referencing revision(s) prior to the oldest dumped revision (12920). WARNING: Loading this dump may result in invalid mergeinfo. * Verified revision 12930. * Verified revision 12931. [...] - Julian
Re: 1.6.13 up for signing/testing
On Thu, Sep 30, 2010 at 10:22 AM, Paul Burba wrote: > You'll recall we've seen some odd failures with this test before: > > http://svn.haxx.se/dev/archive-2010-04/0173.shtml > http://svn.haxx.se/dev/archive-2010-04/0418.shtml > > These failures where related to the pre-commit python hook script and > were solved by running Apache manually and not as a service. That's > how I ran my tests and everything worked fine. I figured as much. FWIW, I did run Apache manually because I knew there was some problem. But I am on Windows 7 now, and I was not there to babysit the test. So it is possible there was a prompt I was not there to respond to. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: 1.6.13 up for signing/testing
On Thu, Sep 30, 2010 at 8:21 AM, Mark Phippard wrote: > On Wed, Sep 29, 2010 at 4:08 PM, Hyrum K. Wright > wrote: >> 1.6.13 tarballs are up for testing and signing. The magic revision is >> r1002816: >> http://people.apache.org/~hwright/svn/1.6.13/ > > I am going to send my signature in a minute, but I did have one test > failure with Neon and Serf on Windows. I am assuming this is a local > issue. Here are details: > > CMD: svn.exe ci -m "log msg" > "svn-test-work\working_copies\svnlook_tests-11" --config-dir > "C:\SVN\subversion-1.6.13\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config" > --password rayjandom --no-auth-cache --username jrandom 3600.568000> > Sending svn-test-work\working_copies\svnlook_tests-11\A\D\G\rho > Sending svn-test-work\working_copies\svnlook_tests-11\A\mu > Transmitting file data ..svn: Commit failed (details follow): > svn: MERGE of '/svn-test-work/repositories/svnlook_tests-11/A': timed > out waiting for server (http://localhost) > Traceback (most recent call last): > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", > line 1225, in run > rc = self.pred.run(**kw) > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\testcase.py", > line 121, in run > return self.func(sandbox) > File "C:\SVN\subversion-1.6.13\subversion/tests/cmdline/svnlook_tests.py", > line 594, in test_txn_flag > 'ci', '-m', 'log msg', wc_dir) > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\actions.py", > line 208, in run_and_verify_svn > expected_exit, *varargs) > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\actions.py", > line 241, in run_and_verify_svn2 > exit_code, out, err = main.run_svn(want_err, *varargs) > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", > line 580, in run_svn > *(_with_auth(_with_config_dir(varargs > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", > line 356, in run_command > None, *varargs) > File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", > line 515, in run_command_stdin > raise Failure > Failure > FAIL: svnlook_tests.py 11: test 'svnlook * -t' Mark, You'll recall we've seen some odd failures with this test before: http://svn.haxx.se/dev/archive-2010-04/0173.shtml http://svn.haxx.se/dev/archive-2010-04/0418.shtml These failures where related to the pre-commit python hook script and were solved by running Apache manually and not as a service. That's how I ran my tests and everything worked fine. Paul
[PATCH] Fix svnrdump test 27 on Windows
Hi,
This is an experimental patch to fix svnrdump test 27 "dump:
subdirectory with changes on root" on Windows. It's experimental
because it's based simply on a hunch, and I don't have Windows to test
it. Could someone who has Windows test it for me?
Thanks.
Index: subversion/svnrdump/dump_editor.c
===
--- subversion/svnrdump/dump_editor.c (revision 1002954)
+++ subversion/svnrdump/dump_editor.c (working copy)
@@ -147,7 +147,7 @@ make_dir_baton(const char *path,
new_db->copyfrom_rev = copyfrom_rev;
new_db->added = added;
new_db->written_out = FALSE;
- new_db->deleted_entries = apr_hash_make(eb->pool);
+ new_db->deleted_entries = apr_hash_make(pool);
return new_db;
}
@@ -375,7 +375,7 @@ open_root(void *edit_baton,
eb->propstring = svn_stringbuf_create("", eb->pool);
*root_baton = make_dir_baton(NULL, NULL, SVN_INVALID_REVNUM,
- edit_baton, NULL, FALSE, pool);
+ edit_baton, NULL, FALSE, eb->pool);
LDR_DBG(("open_root %p\n", *root_baton));
return SVN_NO_ERROR;
@@ -415,12 +415,14 @@ add_directory(const char *path,
{
struct dir_baton *pb = parent_baton;
void *val;
- struct dir_baton *new_db
-= make_dir_baton(path, copyfrom_path, copyfrom_rev, pb->eb, pb, TRUE,
pool);
+ struct dir_baton *new_db;
svn_boolean_t is_copy;
LDR_DBG(("add_directory %s\n", path));
+ new_db = make_dir_baton(path, copyfrom_path, copyfrom_rev, pb->eb,
+ pb, TRUE, pb->eb->pool);
+
/* Some pending properties to dump? */
SVN_ERR(dump_props(pb->eb, &(pb->eb->dump_props), TRUE, pool));
@@ -483,7 +485,7 @@ open_directory(const char *path,
}
new_db = make_dir_baton(path, copyfrom_path, copyfrom_rev, pb->eb, pb,
- FALSE, pool);
+ FALSE, pb->eb->pool);
*child_baton = new_db;
return SVN_NO_ERROR;
}
Re: 1.6.13 up for signing/testing
SUMMARY: +1 to release PLATFORM: Windows 7 VS 2008 SP1 Java 1.6 COMPONENTS: Apache2.2.15 APR 1.4.2 APR-UTIL1.3.0 OpenSSL 0.9.8o Neon(from deps) Serf 0.7.0 ZLib (from deps) SQLite (from deps) VERIFIED: md5 and sha1 sums gpg signature verified TESTED: JavaHL ra_local | ra_svn | ra_neon | ra_serf X fsfs RESULTS: All passed except the following on Neon and Serf, which I assume to be a local problem (new system). svnlook_tests.py 11: test 'svnlook * -t' SIGNATURES: subversion-1.6.13.zip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iEYEABECAAYFAkyjouMACgkQJl34oANalqlfLACeOd71ZFq0NVbho0TFReJ6yuyg RLQAoMPUpJA2a1T0CKybDbfR4SvXYRUK =uyM3 -END PGP SIGNATURE- subversion-deps-1.6.13.zip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) iEYEABECAAYFAkyjouoACgkQJl34oANalql15gCbBHGRP+I2RoFBElbtytWkzrV0 XusAoKA7ypuSBhXQkNbD1Lz+ORDzcKm+ =/pPZ -END PGP SIGNATURE- -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: 1.6.13 up for signing/testing
On Wed, Sep 29, 2010 at 4:08 PM, Hyrum K. Wright wrote: > 1.6.13 tarballs are up for testing and signing. The magic revision is > r1002816: > http://people.apache.org/~hwright/svn/1.6.13/ I am going to send my signature in a minute, but I did have one test failure with Neon and Serf on Windows. I am assuming this is a local issue. Here are details: CMD: svn.exe ci -m "log msg" "svn-test-work\working_copies\svnlook_tests-11" --config-dir "C:\SVN\subversion-1.6.13\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config" --password rayjandom --no-auth-cache --username jrandom Sendingsvn-test-work\working_copies\svnlook_tests-11\A\D\G\rho Sendingsvn-test-work\working_copies\svnlook_tests-11\A\mu Transmitting file data ..svn: Commit failed (details follow): svn: MERGE of '/svn-test-work/repositories/svnlook_tests-11/A': timed out waiting for server (http://localhost) Traceback (most recent call last): File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", line 1225, in run rc = self.pred.run(**kw) File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\testcase.py", line 121, in run return self.func(sandbox) File "C:\SVN\subversion-1.6.13\subversion/tests/cmdline/svnlook_tests.py", line 594, in test_txn_flag 'ci', '-m', 'log msg', wc_dir) File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\actions.py", line 208, in run_and_verify_svn expected_exit, *varargs) File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\actions.py", line 241, in run_and_verify_svn2 exit_code, out, err = main.run_svn(want_err, *varargs) File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", line 580, in run_svn *(_with_auth(_with_config_dir(varargs File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", line 356, in run_command None, *varargs) File "C:\SVN\subversion-1.6.13\subversion\tests\cmdline\svntest\main.py", line 515, in run_command_stdin raise Failure Failure FAIL: svnlook_tests.py 11: test 'svnlook * -t' -- Thanks Mark Phippard http://markphip.blogspot.com/
