"Hyrum K. Wright" writes:
> On Tue, Apr 13, 2010 at 7:08 AM, Philip Martin
> wrote:
>> > The rep sharing cache is just a cache, and can be truncated or
>> > deleted without impact on the correctness of the system.
>>
>> That's a way to fix a corrupt hotcopy but I don't think it prevents
>> the c
Hi,
deleting the working copy root doesn't work (and I don't it think
should), but the error message we print is somewhat confusing:
$ pwd
/tmp/svn-sandbox/trunk
$ svn rm .
subversion/svn/delete-cmd.c:91: (apr_err=155007)
subversion/svn/util.c:900: (apr_err=155007)
subversion/libsvn_
Philip Martin writes:
> Daniel Shahaf writes:
>
>> Philip Martin wrote on Tue, 13 Apr 2010 at 13:08 +0100:
>>> Summary: FSFS hotcopy doesn't handle SQLite databases properly, this
>>> affects the new revprop packing db and the 1.6 rep sharing db.
>>
>> revprops.db consists of a single table; per
Philip Martin writes:
> did that it was taking over 17s). That's an order of magnitude slower
> which could be a problem, the SELECT on the source will block writes
> to the database during the copy.
Writing that has made me think of another solution. If we do a SELECT
on the source database,
> -Original Message-
> From: phi...@apache.org [mailto:phi...@apache.org]
> Sent: woensdag 14 april 2010 15:06
> To: comm...@subversion.apache.org
> Subject: svn commit: r933938 - in /subversion/trunk: build.conf
> subversion/include/private/svn_sqlite.h subversion/libsvn_fs_fs/fs_fs.c
>
Hi!
#3610 [1] is about ignoring white space changes to be able to apply
patches that have been mangled, i.e. a mailing software converting tabs
to spaces, removing trailing white spaces or leading white spaces.
It means that if a certain option is given, we will match and apply
hunks if the only
"Bert Huijben" writes:
>> --- subversion/trunk/subversion/libsvn_subr/sqlite.c (original)
>> +++ subversion/trunk/subversion/libsvn_subr/sqlite.c Wed Apr 14 13:05:56
>> 2010
>> @@ -28,6 +28,7 @@
>> #include "svn_io.h"
>> #include "svn_dirent_uri.h"
>> #include "svn_checksum.h"
>> +#include "sq
I've got a patch coming up...
On Wed, Apr 14, 2010 at 10:26, Philip Martin wrote:
> "Bert Huijben" writes:
>
>>> --- subversion/trunk/subversion/libsvn_subr/sqlite.c (original)
>>> +++ subversion/trunk/subversion/libsvn_subr/sqlite.c Wed Apr 14 13:05:56
>>> 2010
>>> @@ -28,6 +28,7 @@
>>> #inclu
Fixed in r933969
On Wed, Apr 14, 2010 at 10:27, Greg Stein wrote:
> I've got a patch coming up...
>
> On Wed, Apr 14, 2010 at 10:26, Philip Martin
> wrote:
>> "Bert Huijben" writes:
>>
--- subversion/trunk/subversion/libsvn_subr/sqlite.c (original)
+++ subversion/trunk/subversion/lib
On Tue, 2010-04-13, s...@apache.org wrote:
> Author: stsp
> Date: Tue Apr 13 19:45:17 2010
> New Revision: 933767
>
> URL: http://svn.apache.org/viewvc?rev=933767&view=rev
> Log:
> On the svn-patch-improvements branch, revamp handling of deleted directories.
>
> While not originally intended, thi
Greg Stein writes:
> I've got a patch coming up...
Hmm...
$ (cd ../src && ./gen-make.py)
WARNING: "internal_statements.h" header not found, file
subversion/libsvn_subr/sqlite.c
$ (cd ../src && ./gen-make.py)
$
The first build-outputs.mk doesn't list internal_statements.h as a
dependency of sq
On Wed, Apr 14, 2010 at 10:52, Philip Martin wrote:
> Greg Stein writes:
>
>> I've got a patch coming up...
>
> Hmm...
>
> $ (cd ../src && ./gen-make.py)
> WARNING: "internal_statements.h" header not found, file
> subversion/libsvn_subr/sqlite.c
> $ (cd ../src && ./gen-make.py)
> $
>
> The first
On Wed, Apr 14, 2010 at 04:21:56PM +0200, Daniel Näslund wrote:
> Hi!
>
> #3610 [1] is about ignoring white space changes to be able to apply
> patches that have been mangled, i.e. a mailing software converting tabs
> to spaces, removing trailing white spaces or leading white spaces.
>
> It means
On Wed, Apr 14, 2010 at 03:48:49PM +0100, Julian Foad wrote:
> On Tue, 2010-04-13, s...@apache.org wrote:
> > (push_if_unique): New helper function, needed because we do not use
> >a hash table anymore to ensure path uniqueness.
>
> Why not use a hash table? It looks like doing so would hav
Paul Burba wrote:
> After thinking about this some more I see three options:
>
> A) Keep the pre-927243 behavior as the default and thus support the
> incremental dump use case by default. Add a new option to svnadmin
> load, --skip-missing-merge-sources (or maybe
> --filter-missing-merge-sources
On Wed, Apr 14, 2010 at 05:35:36PM +0200, Stefan Sperling wrote:
> On Wed, Apr 14, 2010 at 04:21:56PM +0200, Daniel Näslund wrote:
> > Hi!
> >
> > #3610 [1] is about ignoring white space changes to be able to apply
> > patches that have been mangled, i.e. a mailing software converting tabs
> > to
On Wed, Apr 14, 2010 at 11:19, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/questions.c Wed Apr 14 15:19:13 2010
> @@ -85,6 +85,11 @@
> * if verify_checksum is TRUE. If checksum does not match, return the error
> * SVN_ERR_WC_CORRUPT_TEXT_BASE.
> *
> + * If COMPARE_TEXTBASES is true
2010/4/14 Philipp Marek :
> Hello Jan!
>
> On Dienstag, 13. April 2010, Jan Horák wrote:
>> Dne 12.4.2010 8:02, Philipp Marek napsal(a):
>> > Sorry for the delay; but reading the thread "Severe performance issues
>> > with large directories" I just remembered that the backend has a little
>> > bit
On Tue, Apr 13, 2010 at 15:45, wrote:
>...
> +++
> subversion/branches/svn-patch-improvements/subversion/libsvn_client/patch.c
> Tue Apr 13 19:45:17 2010
>...
> + /* Finally, delete empty directories. */
> + for (i = 0; i < empty_dirs->nelts; i++)
> + {
> + const char *empty_dir;
> +
phi...@apache.org writes:
> Author: philip
> Date: Wed Apr 14 16:35:11 2010
> New Revision: 934008
>
> URL: http://svn.apache.org/viewvc?rev=934008&view=rev
> Log:
> * subversion/libsvn_subr/sqlite.c
> (svn_sqlite__hotcopy): Use the SQLite backup interface if available.
>
> Modified:
> subve
On Wed, Apr 14, 2010 at 12:43, Philip Martin wrote:
> phi...@apache.org writes:
>
>> Author: philip
>> Date: Wed Apr 14 16:35:11 2010
>> New Revision: 934008
>>
>> URL: http://svn.apache.org/viewvc?rev=934008&view=rev
>> Log:
>> * subversion/libsvn_subr/sqlite.c
>> (svn_sqlite__hotcopy): Use the
Philip Martin wrote:
> phi...@apache.org writes:
>
>> Author: philip
>> Date: Wed Apr 14 16:35:11 2010
>> New Revision: 934008
>>
>> URL: http://svn.apache.org/viewvc?rev=934008&view=rev
>> Log:
>> * subversion/libsvn_subr/sqlite.c
>> (svn_sqlite__hotcopy): Use the SQLite backup interface if ava
On Wed, Apr 14, 2010 at 12:35, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_subr/sqlite.c Wed Apr 14 16:35:11 2010
> @@ -975,23 +975,55 @@ svn_sqlite__hotcopy(const char *src_path
> const char *dst_path,
> apr_pool_t *scratch_pool)
> {
> - svn_sql
Greg Stein writes:
>> + SVN_ERR(svn_sqlite__open(&dst_db, dst_path, svn_sqlite__mode_rwcreate,
>> + NULL, 0, NULL, scratch_pool, scratch_pool));
>> + backup = sqlite3_backup_init(dst_db->db3, "main", src_db->db3, "main");
>> + if (!backup)
>> + return SVN
When debugging some repository performance problems, I narrowed it
down to repositories with large numbers of locked files. For example,
if I do an "svn ls -v http://server/repo/path"; on a repository with
26k locked files, the server generates an 11MB xml response
that included lock information a
Philip Martin wrote on Wed, 14 Apr 2010 at 12:31 +0100:
> Philip Martin writes:
>
> > did that it was taking over 17s). That's an order of magnitude slower
> > which could be a problem, the SELECT on the source will block writes
> > to the database during the copy.
>
> Writing that has made me
kmra...@rockwellcollins.com wrote:
> When debugging some repository performance problems, I narrowed it
> down to repositories with large numbers of locked files. For example,
> if I do an "svn ls -v http://server/repo/path"; on a repository with
> 26k locked files, the server generates an 11MB xm
On Wed, 14 Apr 2010, Stefan Sperling wrote:
> Yes. Just use whatever comes from the patch, including context lines.
> This is consistent with the current behaviour. I think we should avoid
> special cases where this rule is currently not true anymore.
> (I'm not sure how UNIX patch behaves wrt con
phi...@apache.org wrote on Wed, 14 Apr 2010 at 16:35 -:
> - /* We could use the SQLite backup interface (from 3.6.11 and still
> - experimental) and the copy would be done in chunks with the lock
> - released between chunks. */
> +#if SQLITE_VERSION_AT_LEAST(3,6,11)
> + {
Given that
I've merged the latest swig-rb fixes to 1.6.x, rerun 'make check', as well
as all the binding tests, and everything looks good to me. As I recall,
there were a few Windows failures in 1.6.10, so in my paranoia, I'd request
folks that encountered those to place rerun the tests and verify that they
Over the early part of this year Mike Pilato and other Collabnet
employees met with many of our customers to get feeback on Subversion,
see
http://svn.apache.org/repos/asf/subversion/trunk/notes/feedback/cmpilato-user-calls
One merge related item that came up was: '--reintegration should
tolerate
Daniel Shahaf writes:
> I see you have now implemented this (r933938; diff appended). I assume
> this solution is reasonably fast (compared to the 0.25s and 3s figures
> you cited upthread)?
Yes. There is very little additional overhead taking a lock unless
blocked by a writer. The problem is
Paul Burba wrote:
> In a perfect world maybe we'd give a error along the lines of 'hey,
> you are trying to reintegrate into a shallow WC and some of the paths
> affected by the merge aren't present, you are going to get tree
> conflicts, is this really what you want? :-)'
>
> But going this route
Daniel Shahaf writes:
> phi...@apache.org wrote on Wed, 14 Apr 2010 at 16:35 -:
>> - /* We could use the SQLite backup interface (from 3.6.11 and still
>> - experimental) and the copy would be done in chunks with the lock
>> - released between chunks. */
>> +#if SQLITE_VERSION_AT_LEA
On Wed, Apr 14, 2010 at 2:34 PM, C. Michael Pilato wrote:
> Paul Burba wrote:
>> In a perfect world maybe we'd give a error along the lines of 'hey,
>> you are trying to reintegrate into a shallow WC and some of the paths
>> affected by the merge aren't present, you are going to get tree
>> confli
On Wed, Apr 14, 2010 at 08:18:06PM +0200, Alan Barrett wrote:
> On Wed, 14 Apr 2010, Stefan Sperling wrote:
> > Yes. Just use whatever comes from the patch, including context lines.
> > This is consistent with the current behaviour. I think we should avoid
> > special cases where this rule is curr
Paul Burba wrote:
> On Wed, Apr 14, 2010 at 2:34 PM, C. Michael Pilato
> wrote:
>> Paul Burba wrote:
>>> In a perfect world maybe we'd give a error along the lines of 'hey,
>>> you are trying to reintegrate into a shallow WC and some of the paths
>>> affected by the merge aren't present, you are
C. Michael Pilato wrote:
> Paul Burba wrote:
>> On Wed, Apr 14, 2010 at 2:34 PM, C. Michael Pilato
>> wrote:
>>> Paul Burba wrote:
In a perfect world maybe we'd give a error along the lines of 'hey,
you are trying to reintegrate into a shallow WC and some of the paths
affected by t
On Wed, Apr 14, 2010 at 12:21:02PM -0400, Greg Stein wrote:
> On Tue, Apr 13, 2010 at 15:45, wrote:
> >...
> > +++
> > subversion/branches/svn-patch-improvements/subversion/libsvn_client/patch.c
> > Tue Apr 13 19:45:17 2010
> >...
> > + /* Finally, delete empty directories. */
> > + for (i =
On Wed, Apr 14, 2010 at 05:49:51PM +0200, Daniel Näslund wrote:
> On Wed, Apr 14, 2010 at 05:35:36PM +0200, Stefan Sperling wrote:
> > I.e. we'll add some optional magic in match_hunk(), making it skip over
> > whitespace on either side (as determined by isspace()), but comparing
> > any other char
On Wed, Apr 14, 2010 at 09:27:25PM +0200, Daniel Näslund wrote:
> On Wed, Apr 14, 2010 at 08:18:06PM +0200, Alan Barrett wrote:
> > I don't buy the argument that it's necessary, for consistency with
> > current svn behaviour, to copy context lines from the patch to
> > the output file.
It is consi
On Wed, Apr 14, 2010 at 03:36:31PM -0400, C. Michael Pilato wrote:
> I would feel more warm and fuzzy if
> I knew that the tree conflict information that we leave around is clear
> about the reason for the conflict. That a missing-due-to-sparse-checkouts
> directory is the reason for the conflict,
On Wed, Apr 14, 2010 at 15:53, Stefan Sperling wrote:
> On Wed, Apr 14, 2010 at 12:21:02PM -0400, Greg Stein wrote:
>> On Tue, Apr 13, 2010 at 15:45, wrote:
>> >...
>> > +++
>> > subversion/branches/svn-patch-improvements/subversion/libsvn_client/patch.c
>> > Tue Apr 13 19:45:17 2010
>> >...
>
On Wed, Apr 14, 2010 at 3:49 PM, C. Michael Pilato wrote:
> C. Michael Pilato wrote:
>> Paul Burba wrote:
>>> On Wed, Apr 14, 2010 at 2:34 PM, C. Michael Pilato
>>> wrote:
Paul Burba wrote:
> In a perfect world maybe we'd give a error along the lines of 'hey,
> you are trying to rei
Philip Martin wrote on Wed, 14 Apr 2010 at 12:17 +0100:
> -svn_error_t *
> -svn_fs_fs__open_rep_cache(svn_fs_t *fs,
> - apr_pool_t *pool)
> +static svn_error_t*
> +open_rep_cache(fs_fs_data_t *ffd,
> + const char *fs_path,
> + apr_pool_t *fs_pool
fyi,
I found that _get_revision_number()'s -1 revision for added nodes
would leak at least into an error message from 'svn log'.
Checking that out I noticed that -1 is the revnum returned for
_revision_unspecified; 'svn log' in that case assumes HEAD. Probably
other callers do the same or similar
On Wed, 14 Apr 2010, Daniel Nslund wrote:
> If we would implement --ignore-whitespaces to have the behaviour you
> suggested we would have to rewrite the parts dealing with
> modified_stream to make us able to distinguish between context lines and
> added lines. At the moment, we filter out the lea
On Tue, Apr 13, 2010 at 4:37 PM, C. Michael Pilato wrote:
> ... Have you
> tried the suggested fix to see how it affects our test suite runs? Would
> you be willing/able to generate, test, and transmit a patch to that affect?
Will do, it will take a day or so.
Cheers, Roderich
On Wed, Apr 14, 2010 at 2:26 PM, Hyrum K. Wright
wrote:
> I've merged the latest swig-rb fixes to 1.6.x, rerun 'make check', as well
> as all the binding tests, and everything looks good to me. As I recall,
> there were a few Windows failures in 1.6.10, so in my paranoia, I'd request
> folks that
49 matches
Mail list logo
