Hello Marco,
On Wednesday 07 July 2010, Marco Jansen wrote:
> So therefor, what we would like to see is to be able to have a
> transparent branch: One which fetches updates from both branch and
> trunk, without having them listed as changes or triggering commits. In
> essence it's reading from two
Hi,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > Add a dump editor and write out skeleton callback functions according
> > to the API documentation of svn_delta_editor_t. Also expose
> > get_dump_editor through a header.
>
> This commit message tells me nothing... Maybe:
>
>
svn co https://myrepos/svn/project1 /home/ostraaten/project1 -N
causes
Segmentation fault
My repos is Subversion version 1.6.9 (r901367)
I created my client from the trunk this morning revision 961534.
I was warned for segmentation fault with regards to the way I set
LD_LIBRARY_PATH. I used ldco
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
> > Jonathan Nieder writes:
> >> Ramkumar Ramachandra wrote:
>
> >>> - de->apply_textdelta = apply_textdelta;
> >>> + /* de->apply_textdelta = apply_textdelta; */
> [...]
> > Without this, the program segfaults because the necessary setup for
>
On Wed, Jul 7, 2010 at 1:32 PM, Bert Huijben wrote:
>> -Original Message-
>> From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of
>> Hyrum K. Wright
>> Sent: woensdag 7 juli 2010 6:03
>> To: Subversion Development
>> Subject: Do we better tolerate obstructed updates?
>>
On 07/04/2010 12:08 PM, Igor Sereda wrote:
> [[[
> Fix for svndumpfilter.
>
> * subversion/svndumpfilter/main.c
>
> Problem Reproduction Sequence:
>
> 1. Get a dump of a repository with empty revisions (for example, by
> pulling a subdirectory of a remote repo with svnsync).
> 2. Run svndu
Matt Doran wrote:
Stefan Fuhrmann wrote:
A couple of weeks ago, I started working on SVN's server performance.
Without access to a development repository, I found it hard to
develop a compelling solution to the underlying problems. Thus,
the baby-step patches I sent to this and other lists got
Peter Samuelson wrote:
[Stefan Fuhrmann]
* zlib: major deflate() and adler32() speedup, minor inflate() speedup
What is the story with the s->level > 0 thing in deflate.c? I note
that you slide the hash table only if s->level > 0, but the comment
right above this states:
Hi,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > Here's a diff of the modifications I made after your review:
>
> That’s quite helpful.
>
> > +++ b/svndumpr.c
> > @@ -76,31 +76,19 @@ static svn_error_t *replay_revend(svn_revnum_t revision,
> [...]
> > + /* Populte ctx->auth_bat
Hi,
Ramkumar Ramachandra writes:
> Please note that it has been built and tested only against the
> Subversion trunk: for Subversion 1.6, you can try using my
> ra-svn-1.6. Also, there seems to be some unresolved issue on 64-bit
> systems. We're working on fixing this.
This is fixed. I'm currentl
Ramkumar Ramachandra wrote:
> Jonathan Nieder writes:
>> Ramkumar Ramachandra wrote:
>>> - de->apply_textdelta = apply_textdelta;
>>> + /* de->apply_textdelta = apply_textdelta; */
[...]
> Without this, the program segfaults because the necessary setup for
> applying a text delta hasn't been s
> -Original Message-
> From: hy...@hyrumwright.org [mailto:hy...@hyrumwright.org] On Behalf Of
> Hyrum K. Wright
> Sent: woensdag 7 juli 2010 6:03
> To: Subversion Development
> Subject: Do we better tolerate obstructed updates?
>
> The bindings tests are currently failing, and there appea
Ramkumar Ramachandra wrote:
> Here's a diff of the modifications I made after your review:
That’s quite helpful.
> +++ b/svndumpr.c
> @@ -76,31 +76,19 @@ static svn_error_t *replay_revend(svn_revnum_t revision,
[...]
> + /* Populte ctx->auth_baton with the auth baton
> +non-interacti
Hi Daniel,
Daniel Shahaf writes:
> Ramkumar Ramachandra wrote on Wed, 7 Jul 2010 at 18:31 +0200:
> > Stefan Sperling writes:
> > > I'd prefer adding this as a new command, such as "svnrdump" ("remote
> > > dump").
> >
> > Actually, since I can never support dumpfilev2 with this tool, it
> > prob
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > +++ b/dump_editor.c
> > @@ -128,7 +128,7 @@ svn_error_t *get_dump_editor(const svn_delta_editor_t
> > **editor,
> > de->close_directory = close_directory;
> > de->change_dir_prop = change_dir_prop;
> > de->chang
Ramkumar Ramachandra wrote:
> Fill in replay_revstart to dump the revprops at the start of every
> revision. Add an additional write_hash_to_stringbuf helper function.
A write_hash_to_stringbuf helper does the work of
converting the property hashtable to dumpfile format.
> +++ b/
This change was proposed by Julian some time ago, because having
callback types that change the behaviour of svn_stream_readline(),
namely svn_io_line_filter_cb_t and svn_io_line_transformer_cb_t,
was the wrong approach.
See http://subversion.tigris.org/issues/show_bug.cgi?id=3555
The patch below
Ramkumar Ramachandra wrote:
> +++ b/dump_editor.c
> @@ -128,7 +128,7 @@ svn_error_t *get_dump_editor(const svn_delta_editor_t
> **editor,
> de->close_directory = close_directory;
> de->change_dir_prop = change_dir_prop;
> de->change_file_prop = change_file_prop;
> - de->appl
Ramkumar Ramachandra wrote on Wed, 7 Jul 2010 at 18:31 +0200:
> Stefan Sperling writes:
> > I'd prefer adding this as a new command, such as "svnrdump" ("remote dump").
>
> Actually, since I can never support dumpfilev2 with this tool, it
> probably doesn't make sense to plug it into `svnsync`.
I
Ramkumar Ramachandra wrote:
> Add a dump editor and write out skeleton callback functions according
> to the API documentation of svn_delta_editor_t. Also expose
> get_dump_editor through a header.
This commit message tells me nothing... Maybe:
Add a no-op svn_editor. The function to re
Ramkumar Ramachandra wrote on Wed, 7 Jul 2010 at 19:45 +0200:
> > How about adding a pre-* hook so that an administrator could disable
> > this? There might be some administrators that would want to disable
> > this.
I'm not convinced we should have this; but if we do, shouldn't it be
a pre-repla
Hi again,
Ramkumar Ramachandra wrote:
> Add the debug editor from subversion/libsvn_delta/debug_editor.c along
> with a header to expose the svn_delta__get_debug_editor function.
The description does not tell what the debug editor is for. Is it
for tracing?
In what follows, I am going to prete
Hi Mark,
Mark Phippard writes:
> On Wed, Jul 7, 2010 at 10:47 AM, Ramkumar Ramachandra
> wrote:
>
> > I have recently developed a new svn_editor_t editor for Subversion
> > that uses the replay API to generate a dumpfile v3 over the network
> > on-the-fly (without touching the filesystem except
On Tue, Jul 06, 2010 at 03:39:55PM +0200, Stefan Sperling wrote:
> I find myself frowning upon the fact that Subversion's build system
> is trying to modify files in the /etc directory by default.
>
> It is nice when it works and users expect it, but it is not so nice
> when it does not work, or w
Ramkumar Ramachandra wrote:
> Add a basic SVN command-line client along with a Makefile that does
> just enough to establish a connection with the ASF subversion server;
Thanks for splitting this out.
Let’s see what’s needed to set up a connection:
> +++ b/Makefile
> @@ -0,0 +1,8 @@
> +svndumpr
Hi Jonathan,
Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
>
> > Add a basic SVN command-line client along with a Makefile that does
> > just enough to establish a connection with the ASF subversion server;
>
> Thanks for splitting this out.
Thanks for getting the review process started
On Wed, Jul 7, 2010 at 10:47 AM, Ramkumar Ramachandra
wrote:
> I have recently developed a new svn_editor_t editor for Subversion
> that uses the replay API to generate a dumpfile v3 over the network
> on-the-fly (without touching the filesystem except for some temporary
> files). I initially sta
On Wed, Jul 07, 2010 at 06:31:48PM +0200, Ramkumar Ramachandra wrote:
> > On Wed, Jul 07, 2010 at 04:47:33PM +0200, Ramkumar Ramachandra wrote:
> > Also, please don't send one patch per file, but send the entire thing
> > in one patch.
>
> Okay. It'll probably be a small patch with just dump_edito
Stefan Sperling wrote:
> Ramkumar Ramachandra wrote:
> > I have recently developed a new svn_editor_t editor for Subversion
> > that uses the replay API to generate a dumpfile v3 over the network
[...]
> I see value in adding this feature to Subversion.
> Generating a dump file from a remote repos
Hi Stefan,
Stefan Sperling writes:
> On Wed, Jul 07, 2010 at 04:47:33PM +0200, Ramkumar Ramachandra wrote:
> > Hi,
> >
> > I have recently developed a new svn_editor_t editor for Subversion
> > that uses the replay API to generate a dumpfile v3 over the network
> > on-the-fly (without touching th
On Wed, 2010-07-07 at 11:44 -0400, Marco Jansen wrote:
> So therefor, what we would like to see is to be able to have a transparent
> branch: One which fetches updates from both branch and trunk, without having
> them listed as changes or triggering commits. In essence it's reading from
> two branc
On 07/07/2010 12:19 PM, Stefan Sperling wrote:
>> I would also assume that, since my ~/projects/subversion directory is a 1.7
>> working copy, I would be unable to run the 1.6 test suite from
>> ~/projects/subversion/branches/1.6.x. But I don't see similar problems when
>> I try that. Whyzat? An
On Wed, Jul 07, 2010 at 10:12:25AM -0400, C. Michael Pilato wrote:
> Ah, Realization. How you come to me, sledgehammer in hand.
>
> amalia:~ $ cd ~/tests/ ### a 1.7 working copy directory
> amalia:~/tests $ svn st -v
> 2213 2072 cmpilato .
> amalia:~/tests $ mkdir -p A/B/C/
Greetings,
In the years I've been using SVN as a developer in a rather dynamic
development team, we've found one 'gap' we consider in SVN. The intention of
this mail is to figure out whether this first of all is indeed a gap, a
known gap and perhaps even planned feature, or actually implemented bu
On Wed, Jul 07, 2010 at 04:47:33PM +0200, Ramkumar Ramachandra wrote:
> Hi,
>
> I have recently developed a new svn_editor_t editor for Subversion
> that uses the replay API to generate a dumpfile v3 over the network
> on-the-fly (without touching the filesystem except for some temporary
> files).
Ah, Realization. How you come to me, sledgehammer in hand.
amalia:~ $ cd ~/tests/ ### a 1.7 working copy directory
amalia:~/tests $ svn st -v
2213 2072 cmpilato .
amalia:~/tests $ mkdir -p A/B/C/D/E/F/G
amalia:~/tests $ cd A/B/C/D/E/F/G
amalia:~/tests/A/B/C/D/E/F/G $
~/proj
On Wed, Jul 7, 2010 at 05:37, Julian Foad wrote:
>...
>> > "Merge into root's table" means we move the row into the root's table,
>> > unless a row that's identical apart from its id is already present, in
>> > which
>> > case we use the existing row's id.
>>
>> What do you mean "id"? That column
[Stefan Fuhrmann]
> * zlib: major deflate() and adler32() speedup, minor inflate() speedup
What is the story with the s->level > 0 thing in deflate.c? I note
that you slide the hash table only if s->level > 0, but the comment
right above this states:
/* Slide the hash table (could b
Hi,
I have recently developed a new svn_editor_t editor for Subversion
that uses the replay API to generate a dumpfile v3 over the network
on-the-fly (without touching the filesystem except for some temporary
files). I initially started building the tool to merge it into the
git.git tree and link
OK, created a bug report for this
http://subversion.tigris.org/issues/show_bug.cgi?id=3673.
Onno
Onno van der Straaten writes:
> I can do reproduce this with
> cd A/D/H
> svn move chi chi2
> cd ..
> svn move H h2
> cd wc
> svn commit
>
> Reproduction script is attached. Is this a problem with my 1.7 client?
It's a bug. If you do the moves in the reverse order it works:
svn mv A/D/H A/D/h2
Hi Philip,
I'm trying the 1.7 workaround now.
I created a new wc using the 1.7 client. When I run my script it fails
on svn move with the following message
svn: constraint failed
svn: REPOSITORY.root may not be NULL
I can do reproduce this with
cd A/D/H
svn move chi chi2
cd ..
svn move H h2
cd wc
Greg Stein wrote:
> Julian Foad wrote:
> > I've started looking at moving to a single DB per WC, and written some
> > notes in 'notes/wc-ng/single-db-per-wc'. I haven't looked into the
> > current state of the code yet, other than building it (success) and
> > running it (50% of tests pass, which
On Tue, Jul 06, 2010 at 10:02:58PM -0600, Hyrum K. Wright wrote:
> The bindings tests are currently failing, and there appear to be two
> root causes. One of them, causing test failures in both JavaHL and
> swig-rb, is that the tests expect an error with an operation that used
> to cause an obstru
44 matches
Mail list logo
