On Sat, Jul 24, 2010 at 01:19:15PM +0530, Ramkumar Ramachandra wrote:
> Hi Daniel,
>
> Daniel Shahaf writes:
> > Revving these interfaces falls under the "editor v2" header, for which see
> > svn_editor.h (not implemented yet) and notes/editor-v2.txt.
>
> I see. Thanks for the pointer. Looks like
Hi Daniel,
Daniel Shahaf writes:
> Revving these interfaces falls under the "editor v2" header, for which see
> svn_editor.h (not implemented yet) and notes/editor-v2.txt.
I see. Thanks for the pointer. Looks like I'll have to wait until
editor v2 is finished to dump sha1sums then.
> BTW: adding
Ramkumar Ramachandra wrote on Sat, Jul 24, 2010 at 03:37:06 +0530:
> Hi Stefan,
>
> Stefan Sperling writes:
> > I'd say get the basics right first, before worrying about features
> > like this. In my opinion that means that it needs to produce the same
> > output as svnadmin dump does. (I'm planni
Hi Stefan,
Stefan Sperling writes:
> I'd say get the basics right first, before worrying about features
> like this. In my opinion that means that it needs to produce the same
> output as svnadmin dump does. (I'm planning to revert r965892 soon,
> so you don't need to worry about the Prop-content-
Ramkumar Ramachandra wrote on Sat, Jul 24, 2010 at 02:26:47 +0530:
> Hi Daniel,
>
> Daniel Shahaf writes:
> > Good question.
> >
> > I'd probably say "last revision successfully dumped was rN" and then exit
> > with
> > a non-zero code, leaving it to the admin to clean up the mess (i.e., to
> >
Hi Daniel,
Daniel Shahaf writes:
> Good question.
>
> I'd probably say "last revision successfully dumped was rN" and then exit with
> a non-zero code, leaving it to the admin to clean up the mess (i.e., to
> truncate
> the dumpfile after the end of rN's data).
>
> Unfortunately, since you dump
Ramkumar Ramachandra wrote on Fri, Jul 23, 2010 at 23:56:57 +0530:
> Hi Daniel,
>
> Daniel Shahaf writes:
> > Or, you could have svnrdump report the highest revision it dumped, and the
> > admin can remember that and invoke svnrdump -r N+1:HEAD next time. (Much
> > cheaper than parsing the entire
On Fri, Jul 23, 2010 at 11:56:57PM +0530, Ramkumar Ramachandra wrote:
> Hi Daniel,
>
> Daniel Shahaf writes:
> > Or, you could have svnrdump report the highest revision it dumped, and the
> > admin can remember that and invoke svnrdump -r N+1:HEAD next time. (Much
> > cheaper than parsing the ent
Hi Daniel,
Daniel Shahaf writes:
> Or, you could have svnrdump report the highest revision it dumped, and the
> admin can remember that and invoke svnrdump -r N+1:HEAD next time. (Much
> cheaper than parsing the entire dumpfile --- which you would have to do in
> order to figure how many revision
Ramkumar Ramachandra wrote on Fri, Jul 23, 2010 at 23:41:21 +0530:
> Hi Stefan,
>
> Stefan Sperling writes:
> > Can you explain what you mean by "resume support"?
> > svnadmin dump has no such feature AFAIK.
>
> I like to think of svnrdump as a combination of `svnsync` and
> `svnadmin dump`. To i
Hi Stefan,
Stefan Sperling writes:
> Can you explain what you mean by "resume support"?
> svnadmin dump has no such feature AFAIK.
I like to think of svnrdump as a combination of `svnsync` and
`svnadmin dump`. To illustrate resume support, consider the following
scenario: Suppose a server adminis
On Fri, Jul 23, 2010 at 09:39:46PM +0530, Ramkumar Ramachandra wrote:
> Hi Stefan,
>
> Stefan Sperling writes:
> > svnrdump is something entirely different to svnsync.
> > svnrdump is analogous to 'svnadmin dump', which does not create any
> > svn:sync-* properties itself. It just dumps them if th
Hi Stefan,
Stefan Sperling writes:
> svnrdump is something entirely different to svnsync.
> svnrdump is analogous to 'svnadmin dump', which does not create any
> svn:sync-* properties itself. It just dumps them if they are already
> there. So if you dump a repository which was mirrored using svnsy
Hi Daniel,
Daniel Shahaf writes:
> Isn't it passed to apply_textdelta()?
Oops, looks like I missed that earlier :p
Fixed now.
Thanks.
-- Ram
On Fri, Jul 23, 2010 at 06:11:06PM +0530, Ramkumar Ramachandra wrote:
> Hi again,
>
> With the latest fixes, I thought I'd follow up on this.
>
> Stefan Sperling writes:
> > - svnrdump doesn't dump revision 0.
> >It should dump revision 0, because that revision can contain important
> >r
Ramkumar Ramachandra wrote on Fri, Jul 23, 2010 at 18:11:06 +0530:
> >Text-delta-base-md5
>
> I dug deeper, but it seems like I don't get this information over the
> wire: to actually implement this, I'll have to fetch the file to which
> the delta is being applied along with its md5sum. If th
Hi again,
With the latest fixes, I thought I'd follow up on this.
Stefan Sperling writes:
> - svnrdump doesn't dump revision 0.
>It should dump revision 0, because that revision can contain important
>revprops such as metadata for svnsync (svn:sync-last-merge-rev etc.)
Fixed. After a fe
Hi Stefan,
Stefan Sperling writes:
> Copy of what and when? This baton is global for the entire edit...
>
> Going through the code, I see that you're using this to indicate to
> dump_node() whether an add_directory() or add_file() was in fact a copy.
> Why not remove this field from the struct an
Ramkumar Ramachandra wrote on Wed, Jul 21, 2010 at 17:16:10 +0530:
> I'm still writing a unittest in Python, although I'm still trying to figure
> out how to test it without using that ugly awk query to compare it against
> the `svnadmin dump` output.
Have a look at svnsync_tests.py and svntest/ve
Hi Stefan,
It's been a while, and I've fixed most of the issues that you pointed
out intermittently over the last few days. I'm still writing a
unittest in Python, although I'm still trying to figure out how to
test it without using that ugly awk query to compare it against the
`svnadmin dump` out
On Thu, Jul 15, 2010 at 09:02:20PM +0200, Ramkumar Ramachandra wrote:
> Stefan Sperling writes:
> > > +};
> > > +
> > > +struct handler_baton
> > > +{
> > > + svn_txdelta_window_handler_t apply_handler;
> > > + void *apply_baton;
> > > + apr_pool_t *pool;
> >
> > Yet another pool. What's it for
Hi Stefan,
Stefan Sperling writes:
> Review below.
First, thanks for the detailed review! I'll be travelling over the
next few days starting tomorrow, and didn't want to delay the response
to your review: I've marked some items "TODO" so that I can grep for
them when I'm back in India and fix the
Hi Bert,
Bert Huijben writes:
> > > - I've seen a "Prop-delta: true" line which svnadmin dump does not
> print.
> >
> > Correct. `svnadmin dump` has a logic for determining when the prop is
> > really a delta (as opposed to a delta against /dev/null). Since
> > there's no harm printing extra Pro
Hi Stefan,
Stefan Sperling writes:
> > This isn't in the dump-load-format spec document (atleast afaik), and
> > it's very hard to get this right (yes, I tried). Moreover, it's very
> > ungratifying to have a few extra newlines (reverse engineered from
> > `svnadmin dump`) printed at the end of 10
Hi Michael,
C. Michael Pilato writes:
> You fake it, just like the code behind 'svnadmin dump' does. :-)
> Seriously, Revision 0 is nothing but a revision header and revision
> properties. There is no node data to transmit.
Right, thanks. Will look at the code behind `svnadmin dump` :)
-- Ram
; Git Mailing List
> Subject: Re: [PATCH v2] Add svnrdump
>
> Hi Stefan,
>
> Stefan Sperling writes:
> > Playing with svnrdump and comparing its output to the output of
> > svnadmin dump --deltas, I noticed that:
>
> Thanks for testing!
>
> > - svnrdu
On 07/14/2010 01:47 PM, Jonathan Nieder wrote:
> C. Michael Pilato wrote:
>
>> Revprops aren't handled by the replay API for any revision.
>
> Hmm? What is the rev_props argument to the
>
> typedef svn_error_t (*svn_ra_replay_revstart_callback_t)(
> svn_revnum_t re
C. Michael Pilato wrote:
> Revprops aren't handled by the replay API for any revision.
Hmm? What is the rev_props argument to the
typedef svn_error_t (*svn_ra_replay_revstart_callback_t)(
svn_revnum_t revision,
void *replay_baton,
On Wed, Jul 14, 2010 at 01:31:02PM -0400, C. Michael Pilato wrote:
> Revprops aren't handled by the replay API for any revision.
Ah, I didn't know that.
I was assuming they were transmitted via the replay API but I didn't check.
Thanks,
Stefan
On 07/14/2010 01:24 PM, Stefan Sperling wrote:
> On Wed, Jul 14, 2010 at 06:01:49PM +0200, Ramkumar Ramachandra wrote:
>> Yeah, I forgot to ask about this: passing 0 as an argument to the
>> replay API doesn't seem to work. Why? How do I dump revision 0 then?
>
> Indeed. This seems to be a problem
On Wed, Jul 14, 2010 at 06:01:49PM +0200, Ramkumar Ramachandra wrote:
> Yeah, I forgot to ask about this: passing 0 as an argument to the
> replay API doesn't seem to work. Why? How do I dump revision 0 then?
Indeed. This seems to be a problem in the replay API.
This is not a problem for svnsync i
On 07/14/2010 12:01 PM, Ramkumar Ramachandra wrote:
> Hi Stefan,
>
> Stefan Sperling writes:
>> Playing with svnrdump and comparing its output to the output of
>> svnadmin dump --deltas, I noticed that:
>
> Thanks for testing!
>
>> - svnrdump doesn't dump revision 0.
>>It should dump revisi
Hi Stefan,
Stefan Sperling writes:
> Playing with svnrdump and comparing its output to the output of
> svnadmin dump --deltas, I noticed that:
Thanks for testing!
> - svnrdump doesn't dump revision 0.
>It should dump revision 0, because that revision can contain important
>revprops such
On Tue, Jul 13, 2010 at 10:11:05PM +0200, Stefan Sperling wrote:
> Review below.
A couple of additional remarks:
Playing with svnrdump and comparing its output to the output of
svnadmin dump --deltas, I noticed that:
- svnrdump doesn't dump revision 0.
It should dump revision 0, because that
On Fri, Jul 09, 2010 at 04:29:10PM +0200, Ramkumar Ramachandra wrote:
> Hi,
>
> Along with the changes suggested by Bert and Daniel, this new version
> includes a few small bugfixes and feature additions contributed by
> David and Will, among others. Unfortunately, a diff of the changes
> made is
Hi,
Along with the changes suggested by Bert and Daniel, this new version
includes a few small bugfixes and feature additions contributed by
David and Will, among others. Unfortunately, a diff of the changes
made is not available due to whitespace/ style conversion issues:
please check the recent
36 matches
Mail list logo
