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
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, 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
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
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
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
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 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 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 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 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 =
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
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
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
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
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
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:
> 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
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
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
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
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
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
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
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
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
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
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: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
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 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;
> +
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 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
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
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 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
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 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
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 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
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
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
"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
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
> -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
>
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,
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
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_
"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
49 matches
Mail list logo
