RE: [PATCH] Keychain conditions fix-up for Darwin / Python

2016-09-21 Thread Bert Huijben
this case Subversion has been configured with the switch "--disable- > keychain", I assume > this is triggering the problem. After some discussion on irc with Johannes and input from a few others I applied a patch that resolved the problems in r1761755. The patch is nominated for backp

RE: [PATCH] Re: ra_local doesn't report post-commit errors

2016-09-20 Thread Bert Huijben
d I would be +1 on backporting such a fix to 1.9 (and if possible 1.8). To keep translations easy I would recommend trying if we can just copy some message support from 'svn'. Bert

RE: [PATCH] Re: ra_local doesn't report post-commit errors

2016-09-19 Thread bert
a warning’. There are better ways to fix that problem… and not just for your favorite RA layer, ignoring others. These warnings on the fs layer were designed to be logged server side (e.g. in the apache error log); not to be transferred to the client. Bert Sent from Mail for Windows 10 From

Check SHA vs Content (was: RE: svn commit: r1759233 - /subversion/trunk/subversion/libsvn_wc/questions.c)

2016-09-05 Thread Bert Huijben
igurable... or depending on filesize. We certainly want the new behavior for non-pristine working copies (on the IDEA list for years), but I'm not sure if we always want this behavior as only option. This mail is partially, to just discuss this topic on the list, to make sure everybody k

RE: fsfs: Segfault when rep line lists the all-zeroes checksum

2016-08-30 Thread Bert Huijben
hecksum of some very unlikely data, so users might be able to trigger this under some very unusual circumstances. Bert

RE: [PATCH] Fix a conflict resolution issue related to binary files (patch v4)

2016-08-28 Thread Bert Huijben
ure reference, you might have tried building trunk@HEAD after > locally reverting r1758069; i.e.: > > svn up > svn merge -c -r1758069 > > make check > > Stefan wrote on Sun, Aug 28, 2016 at 18:33:55 +0200: > > Got approved by Bert. > > >

RE: svn commit: r1757761 - /subversion/trunk/subversion/libsvn_client/conflicts.c

2016-08-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: vrijdag 26 augustus 2016 11:58 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1757761 - > /subversion/trunk/subversion/libsvn_client/co

RE: svn commit: r1757761 - /subversion/trunk/subversion/libsvn_client/conflicts.c

2016-08-26 Thread Bert Huijben
ll not always work if the file is not explicitly closed before. On Windows it depends on apr opening the file with delete share flags (10% perf hit in some cases) and nobody else opening the file. In general strictly closing before deleting is a safer procedure. Bert

RE: svn commit: r1757532 - /subversion/trunk/subversion/mod_dav_svn/repos.c

2016-08-24 Thread Bert Huijben
n. I would imagine that this could really help on updates with a lot of files, especially on threaded apache. (The other patch handles the checkout case) Bert

RE: svn commit: r1751207 - in /subversion/branches/1.9.x: ./ STATUS subversion/libsvn_subr/win32_crashrpt.c

2016-07-08 Thread Bert Huijben
> -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: donderdag 7 juli 2016 19:02 > To: Bert Huijben <b...@qqmail.nl> > Cc: Subversion Development <dev@subversion.apache.org> > Subject: Re: svn commit: r1751207 - in /subver

RE: svn commit: r1751207 - in /subversion/branches/1.9.x: ./ STATUS subversion/libsvn_subr/win32_crashrpt.c

2016-07-04 Thread Bert Huijben
e the patch I would say this introduces *more* unspecified behavior. In practice 64 bit is reserved for each integer type provided in varargs in the Windows AMD64 calling convention, so it doesn't change that much and the runtime result will be +- identical But when we use the system sprintf(), fprintf(), anyway... why not just use "0x%p" for all calling conventions? (Rest of the patch looks ok) Bert

RE: Cleaning up the FAQ

2016-06-24 Thread Bert Huijben
es around the world at least every year -commonly more often- and I don't think anybody would really check for the US 2007 changes specifically any more. I just checked the archive for the iana timezone database (https://www.iana.org/time-zones) and we are now on the fifth set of rules released in 2016. There were 6 in 2015, 10 in 2014... I don't think the 2007 rule change warrants its own article when you don't look at it with US-only-glasses. Bert

RE: [PATCH] clean up release notes - pass 3

2016-06-01 Thread Bert Huijben
If we can find a browser that breaks, sure.. (Given the transfer from , which did support numbers if I remember correctly, I'm guessing that this is all just theory) Bert

RE: Issues to close

2016-05-09 Thread Bert Huijben
thing that makes all these related is that we never designed for a ‘lock a complete tree’ scenario in Subversion. And I still don’t know why users really want this, as with Subversions implementation it doesn’t really help you in any scenario. Bert From: Stefan Hett

RE: random, unpredictable sort of svn diff

2016-05-09 Thread Bert Huijben
r the ra layer) reports its changes, which is mostly based on how things are stored in an apr hash in libsvn_repos which performs the tree diff server side. Bert > > -- > Ivan Zhakov

RE: svn commit: r1742820 - /subversion/trunk/build/run_tests.py

2016-05-08 Thread Bert Huijben
sys' is not defined FAIL: lock_tests.py 57: refresh timeout of DAV lock ]]] Most (if not all) can't find sys. After this patch (combined with the previous +- 3 patches). It appears to be specific for the ra-dav test runs... I'm not sure which exact patch introduced this error though. Bert

RE: Requiring python 2.7 (Was: RE: svn commit: r1741742 - in /subversion/trunk:contrib/client-side/svn-merge-vendor.py contrib/server-side/fsfsverify.pytools/server-side/svn-backup-dumps.py)

2016-05-03 Thread Bert Huijben
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: maandag 2 mei 2016 14:05 > To: Bert Huijben <b...@qqmail.nl> > Cc: Stefan Fuhrmann <stef...@apache.org>; dev@subversion.apache.org > Subject: Re: Requiring python 2.7

Requiring python 2.7 (Was: RE: svn commit: r1741742 - in /subversion/trunk:contrib/client-side/svn-merge-vendor.py contrib/server-side/fsfsverify.pytools/server-side/svn-backup-dumps.py)

2016-05-02 Thread Bert Huijben
platforms if we change things for swig, and some of the installed python scripts. Bert Sent from Mail for Windows 10 From: Stefan Fuhrmann Sent: maandag 2 mei 2016 07:02 To: dev@subversion.apache.org Subject: Re: svn commit: r1741742 - in /subversion/trunk:contrib/client-side/svn-merge-vendor.py

RE: [PATCH/RFC] use-sasl=true in --without-sasl builds: make that a fatalerror?

2016-04-30 Thread Bert Huijben
Isn’t this a documented default value? If it is, changing the behavior will likely break many users that don’t use sasl. Bert Sent from my Windows 10 phone From: Daniel Shahaf Sent: zaterdag 30 april 2016 02:53 To: dev@subversion.apache.org Subject: [PATCH/RFC] use-sasl=true in --without-sasl

RE: pgp keys for signing releases

2016-04-28 Thread Bert Huijben
Not entirely sure, but I think you should still publish your pgp key to the major key stores. Once you put your fingerprint on id.apache.org, it knows how to fetch your key from there. Bert Sent from Mail for Windows 10 From: Stefan Sent: donderdag 28 april 2016 01:15 To: dev

RE: Really funny test failure on Windows

2016-04-24 Thread Bert Huijben
issues) Bert Sent from Mail for Windows 10 From: Ivan Zhakov Sent: zaterdag 23 april 2016 20:08 To: Branko Čibej Cc: Subversion Development Subject: Re: Really funny test failure on Windows On 23 April 2016 at 18:43, Branko Čibej <br...@apache.org> wrote: > This just happened when I wa

RE: svn commit: r1740316 - in /subversion/trunk: NOTICE subversion/libsvn_subr/version.c

2016-04-21 Thread Bert Huijben
+1 on backport. Feel free to call it a documentation/trivial change that doesn't need full votes. Bert > -Original Message- > From: kot...@apache.org [mailto:kot...@apache.org] > Sent: donderdag 21 april 2016 15:51 > To: comm...@subversion.apache.org > Subj

RE: svn commit: r1740170 -/subversion/trunk/subversion/libsvn_client/conflicts.c

2016-04-21 Thread Bert Huijben
ten it. I think I missed that the context isn't complete and the format string specifies a local path first, and a repos_relpath later. Bert

RE: [PATCH] Remove mention of SVK in svnsync.txt

2016-04-20 Thread Bert Huijben
ore information about conventions we use, such as our preferred > log message format, see our community guide: > http://subversion.apache.org/docs/community-guide/ In this specific case I like the heads-up on the mailinglist though. But +1 on removing it. Bert

RE: svn commit: r1736432 - /subversion/trunk/subversion/tests/cmdline/update_tests.py

2016-03-29 Thread Bert Huijben
his change. Good fix. Perhaps we can extend it later on to verify in which mode we currently run the test suite (assuming the suite sets up the apache server) Bert

RE: Incomplete xml output when using --xml to non-existent server

2016-03-03 Thread Bert Huijben
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: donderdag 3 maart 2016 09:19 > To: Bert Huijben <b...@qqmail.nl> > Cc: Branko Čibej <br...@apache.org>; Subversion Development > <dev@subversion.apache.org> > Subjec

RE: Incomplete xml output when using --xml to non-existent server

2016-03-02 Thread Bert Huijben
answered now... This is not really fixable in a backwards compatible way as there is no way to express errors in the schema. (How do we express an error to access a file somewhere deep inside a tree? That would make the entire tree invalid as expressed in todays schema) Bert

RE: Incomplete xml output when using --xml to non-existent server

2016-03-02 Thread Bert Huijben
o care for handling error conditions. (Sometimes it is easier to work around things by just performing things recursively on an ancestor directory) Bert

RE: Unversioned files with invalid UTF-8 sequence in name confuse svn

2016-03-01 Thread Bert Huijben
t; working copy would break in a different way. > > I guess we would need some "change locale" operation, which would at least > update the saved locale in the .svn directory. There is no saved locale in the .svn directory... Bert

RE: Unversioned files with invalid UTF-8 sequence in name confuse svn

2016-02-29 Thread Bert Huijben
ound out cleanup is not going to help here... we just can't access this file (or directory, or symlink), so we can't delete it or anything to help you. Bert

RE: Outdated ./subversion/libsvn_ra_serf/README

2016-02-29 Thread Bert Huijben
were already moved to the standard locations. I just removed the file in r1732848. (Copied last version to the bottom of this mail for easy reference) Bert [[ ra_serf status == This library is an RA-layer implementation of a WebDAV client that uses Serf. Serf's homepage is

RE: (unknown)

2016-02-22 Thread Bert Huijben
[Moving thread to dev@s.a.o from users@] > -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: maandag 22 februari 2016 13:21 > To: 'Daniel Shahaf' <d...@daniel.shahaf.name>; 'Michal Matyl' > <michal.ma...@zf.com> > Cc: us...@subve

RE: svn commit: r1730716 - in /subversion/trunk/subversion: include/private/svn_wc_private.h include/svn_client.h libsvn_client/resolved.c libsvn_wc/conflicts.c svn/resolve-cmd.c

2016-02-17 Thread Bert Huijben
t_conflict_option_merged_text || > + (option_id == > svn_client_conflict_option_update_any_moved_away_children > +&& incoming_change == svn_wc_conflict_action_edit)) && The new variable incoming_change is used uninitialized here, breaking the build

RE: svn commit: r1730617 -/subversion/trunk/subversion/libsvn_repos/log.c

2016-02-15 Thread Bert Huijben
Are you sure the pool arguments are in the right order here? The usual order is result_pool, scratch_pool while most of the calls here appear to use the opposite order. Bert Sent from Mail for Windows 10 From: stef...@apache.org Sent: maandag 15 februari 2016 22:47 To: comm

RE: svn commit: r1730546 - in /subversion/trunk/subversion:include/private/svn_wc_private.h libsvn_client/resolved.clibsvn_wc/conflicts.c

2016-02-15 Thread Bert Huijben
on recursive operations. Bert Sent from Mail for Windows 10 From: Stefan Sperling Sent: maandag 15 februari 2016 18:17 To: Bert Huijben Cc: dev@subversion.apache.org Subject: Re: svn commit: r1730546 - in /subversion/trunk/subversion:include/private/svn_wc_private.h libsvn_client/resolved.clibsvn_wc

RE: svn commit: r1730546 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/resolved.c libsvn_wc/conflicts.c

2016-02-15 Thread Bert Huijben
_depth_empty, > + FALSE, FALSE, TRUE, > + conflict_choice, > + NULL, NULL, /* legacy conflict_func/baton > */ > + ctx->cancel_func, > + ctx->cancel_baton, > + ctx->notify_func2, > + ctx->notify_baton2, > + scratch_pool); > + err = svn_error_compose_create(err, svn_wc__release_write_lock(ctx- > >wc_ctx, > + > lock_abspath, > + > scratch_pool)); > + svn_io_sleep_for_timestamps(local_abspath, scratch_pool); > + SVN_ERR(err); Same thing here... I don't think this sleep operation is necessary. Same conditions, in case it is really necessary: add output argument to note the cases where they are really necessary, etc. (Never needed on directories, things that are already deleted, etc. etc.) Bert

RE: SVN::Client::log() first argument Re: svn commit: r1729519 - /subversion/trunk/tools/client-side/svn-graph.pl

2016-02-15 Thread Bert Huijben
ecific for 'targets' argument in one of our .i files, but no matching implementation. I'm trying to find why, but the only things I can find would indicate that this is just based on how swig implements array mappings for perl. Bert

RE: svn commit: r1729060 - /subversion/trunk/tools/client-side/svn-graph.pl

2016-02-09 Thread Bert Huijben
are helper functions on the client to create an Ra session from that, which automatically hook a few other features that are now ignored. Bert

RE: [RFE] Make 'svn patch' read from STDIN

2016-02-07 Thread Bert Huijben
itself. And given that the diff parse code has to read the file multiple times we will need a tempfile anyway. Bert Sent from Outlook Mail for Windows 10 phone From: Daniel Shahaf Sent: zondag 7 februari 2016 01:22 To: Andreas Scherer; dev@subversion.apache.org Subject: Re: [RFE] Make 'svn patch

RE: svn commit: r1728324 - /subversion/trunk/subversion/tests/svn_test_main.c

2016-02-04 Thread Bert Huijben
ting the stack to the old state. With an inner function this is not guaranteed to work. (I'm guessing many compilers would just inline the single call, but then...) Bert

RE: svncutter can be removed

2016-02-03 Thread Bert Huijben
h '/foo'). In my experience using svndumpfilter without --drop-*, but without --renumber-revs is the most likely cause of these problems. Forgetting to add that flag just creates invalid dumpfiles, so I don't think we should have allowed that scenario. (Where is my time machine?) BTW: svndumpfilter existed since Subversion 1.0, so it certainly predates 2009. Not sure about when its specific features were introduced though. Bert

RE: svn commit: r1727785 - /subversion/trunk/subversion/libsvn_ra_svn/marshal.c

2016-02-01 Thread Bert Huijben
> -Original Message- > From: Stefan Fuhrmann [mailto:stef...@apache.org] > Sent: maandag 1 februari 2016 07:29 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1727785 - > /subversion/trunk/subversion/libsvn_ra_svn/marshal.c > > > > On 31.01.

RE: svn commit: r1727785 - /subversion/trunk/subversion/libsvn_ra_svn/marshal.c

2016-01-31 Thread Bert Huijben
cleanup)? I think this commit has the wrong log message. Bert > > Modified: > subversion/trunk/subversion/libsvn_ra_svn/marshal.c > > Modified: subversion/trunk/subversion/libsvn_ra_svn/marshal.c > URL: > http://svn.apache.org/viewvc/subversio

RE: svn commit: r1727276 - in /subversion/trunk/subversion: libsvn_client/resolved.c svn/conflict-callbacks.c

2016-01-28 Thread Bert Huijben
ow use _() to localize the option here, instead of in the callee. I was assuming the N_() in the array was that it wasn't evaluated there, but added to the localization strings anyway... to allow later code to use the localized variants via the api. We currently don't provide access to our gettext instance via our api, so I have no idea how localization should work when we are used as a library and don't provide the localized values. Bert

RE: svn commit: r1723876 - in /subversion/branches/fs-node-api/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_fs/fs-loader.h libsvn_fs/node_compat.c libsvn_fs_fs/node.c

2016-01-27 Thread Bert Huijben
ut the member variable... I don't see a problem with the accessor function. It might not be needed later on after more cleanup as callers most likely already have all/most these pointers itself) Bert

RE: svn commit: r1723882 - /subversion/trunk/subversion/tests/libsvn_ra/ra-test.c

2016-01-27 Thread Bert Huijben
Do not check DIRENT->SIZE due known problem in ra_serf. > This >test for different bug. Wasn't it easier to 'just' fix ra_serf here? If I remember correctly serf always retrieves the node kind on retrieved nodes, so this shouldn't be hard to fix. Bert

RE: Perl interface: SVN::Core::dirent_canonicalize segfaults on undef

2016-01-22 Thread Bert Huijben
use, but it takes someone to maintain such a thing. (I did exactly this for C#/.Net in the SharpSvn project) Bert

RE: Running SVN 1.9.x on ASF servers?

2016-01-21 Thread Bert Huijben
Hi Greg, Any news on this? I’m trying to find the list this discussion moved to. Bert From: Greg Stein [mailto:gst...@gmail.com] Sent: dinsdag 1 december 2015 22:20 To: Tony Stevenson <pct...@apache.org> Cc: David Nalley <ke4...@apache.org

RE: svn commit: r1725184 - /subversion/branches/1.9.x/STATUS

2016-01-18 Thread Bert Huijben
+1: stefan2 When I look at the patch (and the log message), it looks at a very simple change... but I have absolutely no idea what the side effects are. Given your descriptions, I would like to see it backported, but can you help us review this change? Thanks, Bert

RE: svn commit: r1723900 - in /subversion/branches/fs-node-api/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_fs/fs-loader.h libsvn_fs/node_compat.c libsvn_fs_fs/node.c tests/libsvn_fs/fs-t

2016-01-11 Thread Bert Huijben
le_checksum2(), but reference node by @a root and > + * @a path. > + */ > +svn_error_t * > svn_fs_file_checksum(svn_checksum_t **checksum, > svn_checksum_kind_t kind, > svn_fs_root_t *root, > @@ -2422,21 +2456,29 @@ svn_fs_file_md5_checksum(unsigned char d Bert

RE: svn commit: r1723385 - in /subversion/trunk/subversion: libsvn_client/relocate.c tests/cmdline/relocate_tests.py

2016-01-06 Thread Bert Huijben
while (index_from && index_to > + && sig_from_prefix[index_from] == sig_to_prefix[index_to]) > +{ > + sig_from_prefix[index_from] = sig_to_prefix[index_to] = '\0'; > + --index_from; > + --index_to; > +} > + I'm wondering, is it safe to do this this way... or should we use the safer svn_uri_dirname() to split of whole components from a url at a time. Are there cases where this might match half a directory (or host) name? Bert

RE: svn commit: r1723003 - /subversion/branches/1.9.x/STATUS

2016-01-05 Thread Bert Huijben
mergeinfo for merge of r1721488 into '.': U . --- Merging r1721648 into '.': Gsubversion\bindings\swig\INSTALL Asubversion\bindings\swig\include\proxy.py Gsubversion\bindings\swig\include\proxy.swg Cbuild\ac-macros\swig.m4 --- Recording mergeinfo for merge of r1721648 into '.': G . Summary of conflicts: Text conflicts: 1 ]] Bert

RE: votes? [HISTORY HELP?]

2016-01-02 Thread Bert Huijben
that aren’t completely updated. Perhaps something around the Subversion Corporation if ever? (Don’t think so…) Bert From: Greg Stein Sent: vrijdag 1 januari 2016 14:43 To: dev@subversion.apache.org Subject: votes? [HISTORY HELP?] Hey all, There have been a few occasions when I've noted

RE: [PATCH] improved behaviour of tools/backup/hot-backup.py

2015-12-21 Thread Bert Huijben
ust exist'? When I accidentally tried to use a wrong directory some weeks ago (while working on libsvn_fs_git) I found that when that file is missing we assume that the filesystem is BDB. Bert

RE: 1.8.15 up for signing/testing

2015-12-14 Thread Bert Huijben
ual Studio 2015 Update 1 on Windows 8.1 Enterprise x64. (32 bit binaries) apr 1.5.1 apr-util 1.5.4 apr_memcache 1.5.4 db 4.4.20 expat 2.1.0 httpd 2.4.17 mod_dav 2.4.17 openssl 1.0.2e sasl 2.1.26 serf 1.3.8 sqlite 3.9.2 zlib 1.2.8 [fsfs | bdb] x [local | svn | serf] Signatures committed. Bert

RE: 1.9.3 up for signing/testing

2015-12-14 Thread Bert Huijben
ual Studio 2015 Update 1 on Windows 8.1 Enterprise x64. (32 bit binaries) apr 1.5.1 apr-util 1.5.4 apr_memcache 1.5.4 db 4.4.20 expat 2.1.0 httpd 2.4.17 mod_dav 2.4.17 openssl 1.0.2e sasl 2.1.26 serf 1.3.8 sqlite 3.9.2 zlib 1.2.8 [fsfs | bdb] x [local | svn | serf] Bert

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-12-12 Thread Bert Huijben
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: zaterdag 12 december 2015 09:20 > To: Julian Foad <julianf...@gmail.com> > Cc: Philip Martin <philip.mar...@wandisco.com>; Bert Huijben > <b...@qqmail.nl>; dev@subv

RE: apr_hash_overlay returns hash with duplicate keys

2015-12-10 Thread Bert Huijben
Are both hash tables created with the same hash function? (I think stefan2 introduced some variants). Otherwise I would expect some key values to be changed somewhere after adding to the first hashtable… But I don’t think this is really a likely scenario. Bert Sent from Outlook Mail

RE: svn commit: r1718167 -/subversion/trunk/subversion/libsvn_ra_local/ra_plugin.c

2015-12-07 Thread Bert Huijben
> -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: maandag 7 december 2015 12:11 > To: Bert Huijben <b...@qqmail.nl> > Cc: Subversion Development <dev@subversion.apache.org> > Subject: Re: svn commit: r1718167 -

RE: 1.8.15 and 1.9.3

2015-12-07 Thread Bert Huijben
t dav_svn__status(request_rec *r) > the request. Ideally we would iterate over all processes but that > would need some MPM support, so we settle for simply showing the > process ID. */ > -#include >ap_rprintf(r, "Server process id: %d\n", (int)getpid()); > #endif > > ]]] I would be +1 on applying this patch under the obvious fix rule. Bert

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-28 Thread Bert Huijben
> -Original Message- > From: Daniel Shahaf [mailto:danie...@apache.org] > Sent: zaterdag 28 november 2015 18:32 > To: Philip Martin <philip.mar...@wandisco.com> > Cc: Bert Huijben <b...@qqmail.nl>; 'Branko Čibej' <br...@apache.org>; > dev@subversion.

RE: svn cleanup error "svn: E720032: Can't remove '...\.svn\tmp\svn-...'

2015-11-27 Thread Bert Huijben
les are kept alive by apr pools, in which the original file handle was allocated. And in case of JavaHL these would be kept alive by java objects... So I guess some explicit dispose/release/close call is missing somewhere. Once the pool is properly cleaned out/destroyed most likely the files will also be deleted, as that is an operation we commonly delay to pool cleanup. Bert

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-27 Thread Bert Huijben
> -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: vrijdag 27 november 2015 13:46 > To: Bert Huijben <b...@qqmail.nl> > Cc: 'Daniel Shahaf' <d...@daniel.shahaf.name>; 'Branko Čibej' > <br...@apache.org>; dev@subv

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-27 Thread Bert Huijben
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: vrijdag 27 november 2015 10:28 > To: 'Daniel Shahaf' <d...@daniel.shahaf.name>; 'Philip Martin' > <philip.mar...@wandisco.com> > Cc: 'Branko Čibej' <br...@apache.org>; dev@subv

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-27 Thread Bert Huijben
> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: vrijdag 27 november 2015 08:50 > To: Philip Martin <philip.mar...@wandisco.com> > Cc: Bert Huijben <b...@qqmail.nl>; 'Branko Čibej' <br...@apache.org>; > dev@subv

RE: svn commit: r1716575 - in /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c

2015-11-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: donderdag 26 november 2015 09:19 > To: dev@subversion.apache.org; Bert Huijben <b...@qqmail.nl> > Subject: Re: svn commit: r1716575 - in > /subversion/trunk/subversion/libsvn_ra_serf: c

RE: svn commit: r1716575 - in /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c

2015-11-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: donderdag 26 november 2015 09:54 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1716575 - in > /subversion/trunk/subversion/libsvn_

RE: svn commit: r1716575 - in /subversion/trunk/subversion/libsvn_ra_serf: commit.c ra_serf.h util.c

2015-11-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: donderdag 26 november 2015 09:54 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1716575 - in > /subversion/trunk/subversion/libsvn_

RE: svn commit: r1716593 - in /subversion/trunk/subversion: mod_dav_svn/repos.c tests/cmdline/lock_tests.py tests/cmdline/mod_dav_svn_tests.py tests/cmdline/svntest/main.py

2015-11-26 Thread Bert Huijben
ing for > requests that specify ?r=WORKINGREV in the url, e.g. > > https://svn.apache.org/repos/asf/subversion/trunk/README?r=1716593 I think you should document this as not sending ?p=<> in the url. Once you add a ?p=, an additional = specifying the same or lower revision is 100% safe. Bert

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-26 Thread Bert Huijben
> -Original Message- > From: Philip Martin [mailto:phi...@codematters.co.uk] > Sent: donderdag 26 november 2015 19:37 > To: Bert Huijben <b...@qqmail.nl> > Cc: 'Branko Čibej' <br...@apache.org>; dev@subversion.apache.org > Subject: Re: svn commit:

RE: JavaHL: "Not implemented" error in StatusEditor.addAbsent

2015-11-25 Thread Bert Huijben
ctly > reproducible for him. Should I ask for an "svn status -u" output? This should be perfectly reproducable when you call status on a directory that contains subdirectories that you are not allowed to read (via a mod_authz_svn config file or similar svnserve config). svn status -u explicitly ignores absent nodes. Bert

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-25 Thread Bert Huijben
> -Original Message- > From: Branko Čibej [mailto:br...@apache.org] > Sent: woensdag 25 november 2015 23:43 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1716548 - > /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c > > On 25.11.2015 2

RE: svn commit: r1716548 - /subversion/trunk/subversion/tests/libsvn_fs/fs-test.c

2015-11-25 Thread Bert Huijben
The question is: Why isn't the base revision properly saved in the txn when the HEAD revision is a no-op commit? I'm guessing that we safe something else and then accidentally fetch the last modified revision of that and use it as the BASE revision of the transaction. Ber

RE: svn commit: r1716394 - /subversion/trunk/subversion/tests/cmdline/svnrdump_tests.py

2015-11-25 Thread Bert Huijben
> -Original Message- > From: stef...@apache.org [mailto:stef...@apache.org] > Sent: woensdag 25 november 2015 14:32 > To: comm...@subversion.apache.org > Subject: svn commit: r1716394 - > /subversion/trunk/subversion/tests/cmdline/svnrdump_tests.py > > Author: stefan2 > Date: Wed Nov 25

RE: svn commit: r1715832 - /subversion/trunk/win-tests.py

2015-11-23 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: maandag 23 november 2015 15:31 > To: dev@subversion.apache.org; Bert Huijben <b...@qqmail.nl> > Subject: Re: svn commit: r1715832 - /subversion/trunk/win-tests.py > > On 23 Nove

RE: svn commit: r1715269 - /subversion/branches/1.9.x/STATUS

2015-11-20 Thread Bert Huijben
There is currently no way how a user with released software can encounter this problem. BTW I think I have a solution for the replay problem at the cost of a few lb of ram. Bert Sent from Outlook Mail for Windows 10 phone From: Julian Foad Sent: vrijdag 20 november 2015 12:04 To: Bert

RE: svn+ssh long-lived daemon

2015-11-20 Thread Bert Huijben
With the right tooling both operations should be equivalent. Perhaps it is easier to spend time on that. Bert Sent from Outlook Mail for Windows 10 phone From: Philip Martin Sent: vrijdag 20 november 2015 12:21 To: Ivan Zhakov Cc: Daniel Shahaf;dev@subversion.apache.org Subject: Re: svn+ssh

RE: svn commit: r1715228-/subversion/trunk/subversion/libsvn_ra_serf/util.c

2015-11-20 Thread Bert Huijben
with an update report that wants to fetch too many files. Bert Sent from Outlook Mail for Windows 10 phone From: Ivan Zhakov Sent: vrijdag 20 november 2015 10:27 To: Bert Huijben Cc: dev@subversion.apache.org Subject: Re: svn commit: r1715228-/subversion/trunk/subversion/libsvn_ra_serf/util.c On 20

RE: svn+ssh long-lived daemon

2015-11-20 Thread Bert Huijben
authentication could be introduced directly in the svnserve protocol. Both these options would also fix the problems raised. Bert Sent from Outlook Mail for Windows 10 phone From: Mark Phippard Sent: vrijdag 20 november 2015 15:20 To: Bert Huijben Cc: Philip Martin;Ivan Zhakov;Daniel Shahaf;dev

RE: svn+ssh long-lived daemon

2015-11-20 Thread Bert Huijben
ks fine, but currently libssh2 still lacks a few of the more recently added cypher types of ssh, with shorter handshake times. Bert

RE: svn commit: r1715228 -/subversion/trunk/subversion/libsvn_ra_serf/util.c

2015-11-20 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: vrijdag 20 november 2015 10:12 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org; d...@serf.apache.org > Subject: Re: svn commit: r1715228 - > /subversion/trunk/subve

RE: svn commit: r1715228 - /subversion/trunk/subversion/libsvn_ra_serf/util.c

2015-11-19 Thread Bert Huijben
tion is necessary even when earlier requests succeeded, depending on the auth scheme). If you want to try this for yourself, you need http 2.4.17 with mod_http2 (or newer) and OpenSSL 1.0.2 or newer. (If you patch Subversion a bit further you should be able to use h2c, which avoids the openssl dependency). Bert

RE: svn commit: r1715228 - /subversion/trunk/subversion/libsvn_ra_serf/util.c

2015-11-19 Thread Bert Huijben
> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: donderdag 19 november 2015 23:41 > To: 'Ivan Zhakov' <i...@visualsvn.com> > Cc: dev@subversion.apache.org > Subject: RE: svn commit: r1715228 - > /subversion/trunk/subve

RE: svn commit: r1715228 - /subversion/trunk/subversion/libsvn_ra_serf/util.c

2015-11-19 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: donderdag 19 november 2015 23:12 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1715228 - > /subversion/trunk/subversion/libsvn_ra_serf

RE: svn commit: r1715269 - /subversion/branches/1.9.x/STATUS

2015-11-19 Thread Bert Huijben
nless Content-Length or Content-Type is set. This should not affect normal Subversion usage, but it makes our http usage a bit cleaner. Bert

RE: svn commit: r1714181 - /subversion/branches/move-tracking-2/subversion/tests/cmdline/svntest/main.py

2015-11-14 Thread Bert Huijben
ry, 1, True, > + return run_command(svnmover_binary, 1, False, > *(_with_auth(_with_config_dir(varargs You missed changing the comment here that documents that you explicitly use binary output. Bert

RE: Merge 'svnmover' demo tool to trunk

2015-11-13 Thread Bert Huijben
where it should fetch a pristine from: BASE or WORKING (or anything inbetween). We can never release the code until at least those things are guaranteed stable. I don't think we can just make a final decision on the final future approach here yet... Bert

RE: Merge 'svnmover' demo tool to trunk

2015-11-10 Thread bert
I think we should keep the functions in the private namespace until we really expose this in our api/tools. Otherwise: +1. Bert From: Julian Foad Sent: dinsdag 10 november 2015 16:28 To: dev Subject: Merge 'svnmover' demo tool to trunk The work on the 'move-tracking-2' branch currently

RE: svn commit: r1712600 - /subversion/trunk/subversion/include/svn_fs.h

2015-11-05 Thread Bert Huijben
current time in > - * microseconds since 00:00:00 January 1, 1970 UTC. So it is > - * extremely unlikely that a transaction name will be reused. > + * sequence and reuse transaction names. I would have said it 'may' reuse transaction names. I don't think we promise that they will actually be reused or not. And perhaps the format may change again in the future. Bert

RE: dump-load of a repository modifies verbose log output: M line lost

2015-11-02 Thread Bert Huijben
ed to: > > http://subversion.tigris.org/issues/show_bug.cgi?id=4598 Yes this looks like a typical example of that bug. The original instance of this bug also related to a CVS import. Bert > > -- > Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> >

RE: svn commit: r1711582 - in /subversion/trunk/subversion: libsvn_fs_fs/tree.c tests/libsvn_fs/fs-test.c

2015-11-02 Thread Bert Huijben
> -Original Message- > From: i...@visualsvn.com [mailto:i...@visualsvn.com] On Behalf Of Ivan > Zhakov > Sent: zaterdag 31 oktober 2015 18:10 > To: Bert Huijben <b...@qqmail.nl> > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1711582 - in /

RE: svn commit: r1711582 - in /subversion/trunk/subversion: libsvn_fs_fs/tree.c tests/libsvn_fs/fs-test.c

2015-10-31 Thread Bert Huijben
ure that path is file. */ > + if (svn_fs_fs__dag_node_kind(node2) != svn_node_file) > +return svn_error_createf > + (SVN_ERR_FS_GENERAL, NULL, _("'%s' is not a file"), path2); > + I don't think you want to backport this, but returning SVN_ERR_FS_NOT_FILE would make more sense here, than returning SVN_ERR_FS_GENERAL. And I would like to see the regression test checking that for all filesystem layers for 1.10... but that is a bigger change. Bert

RE: svn commit: r1703689 - in /subversion/trunk/subversion: libsvn_client/merge.c tests/cmdline/merge_automatic_tests.py

2015-10-30 Thread Bert Huijben
lient/merge.c tests/cmdline/merge_automatic_tests.py > >>> +SVN_ERR(svn_stream_open_readonly(_stream, > mine_abspath, > >>> + scratch_pool, scratch_pool)); > >>> + > >>> + if (!special &&

RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Bert Huijben
on not-changed files) · 1.5-1.8 behavior required for ‘svn annotate -g’ (Wants to know all revisions. Uses that to trigger behavior. Deltas sometimes between unexpected revisions) Api only used for blame or otherwise determining actual changes. Bert From: b

RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread bert
cases... while we already have the code to fix those cases. We should revert the behavior where it makes sense. Reverting it everywhere 'just because' doesn't make sense. Bert Sent from Mail for Windows 10 From: Johan Corveleyn Sent: dinsdag 27 oktober 2015 02:53 To: Bert Huijben Cc

RE: No-op changes no longer dumped by 'svnadmin dump' in 1.9

2015-10-27 Thread Bert Huijben
> -Original Message- > From: Evgeny Kotkov [mailto:evgeny.kot...@visualsvn.com] > Sent: dinsdag 27 oktober 2015 14:38 > To: Bert Huijben <b...@qqmail.nl> > Cc: Johan Corveleyn <jcor...@gmail.com>; Stefan Fuhrmann > <stefan.fuhrm...@wandisco.com>; Julia

RE: svn commit: r1705843 - in /subversion/trunk/subversion: libsvn_client/externals.c tests/cmdline/externals_tests.py

2015-10-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: maandag 26 oktober 2015 09:05 > To: dev@subversion.apache.org; Bert Huijben <b...@qqmail.nl> > Subject: Re: svn commit: r1705843 - in /subversion/trunk/subversion: > libsvn_client/e

RE: svn commit: r1705843 - in /subversion/trunk/subversion: libsvn_client/externals.c tests/cmdline/externals_tests.py

2015-10-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: maandag 26 oktober 2015 09:05 > To: dev@subversion.apache.org; Bert Huijben <b...@qqmail.nl> > Subject: Re: svn commit: r1705843 - in /subversion/trunk/subversion: > libsvn_client/e

RE: svn commit: r1710631 - in /subversion/trunk/subversion: include/svn_fs.h libsvn_fs/fs-loader.c libsvn_repos/repos.c tests/svn_test_fs.c

2015-10-26 Thread Bert Huijben
> -Original Message- > From: Ivan Zhakov [mailto:i...@visualsvn.com] > Sent: maandag 26 oktober 2015 19:37 > To: dev@subversion.apache.org; Bert Huijben <b...@qqmail.nl> > Subject: Re: svn commit: r1710631 - in /subversion/trunk/subversion: > include/svn_fs

RE: svn commit: r1710613 - /subversion/trunk/subversion/libsvn_ra_serf/update.c

2015-10-26 Thread Bert Huijben
Accept-Encoding", > - "svndiff1;q=0.9,svndiff;q=0.8"); > + /* Do not advertise svndiff1 support if we're not interested in > + compression. */ > + serf_bucket_headers_setn(headers, "Accept-Encoding", > "svndiff;q=0.9"); Same here. Bert > } > >return SVN_NO_ERROR; >

<    1   2   3   4   5   6   7   8   9   10   >