From: Jonathan Nieder <jrnieder@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Florian Achleitner <florian.achleitner.2.6.31@gmail.com>,
davidbarr@google.com, git@vger.kernel.org
Subject: Re: [PATCH] Add a svnrdump-simulator replaying a dump file for testing.
Date: Tue, 24 Jul 2012 14:50:49 -0500 [thread overview]
Message-ID: <20120724195049.GD5210@burratino> (raw)
In-Reply-To: <7v8veakyar.fsf@alter.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> Florian Achleitner <florian.achleitner.2.6.31@gmail.com> writes:
>> To ease testing without depending on a reachable svn server, this
>> compact python script mimics parts of svnrdumps behaviour.
>> It requires the remote url to start with sim://.
[...]
>> To allow using the same dump file for simulating multiple
>> incremental imports the highest visible revision can be limited by
>> setting the environment variable SVNRMAX to that value. This
>> effectively limits HEAD to simulate the situation where higher
>> revs don't exist yet.
>
> It is unclear how this is different from giving the ceiling by
> specifying it as the "END" in -rSTART:END command line. Is this
> feature really needed?
I think the idea is that you put this script (or a symlink to it) on
your $PATH with higher precedence than svnrdump and run a command
that expected to be able to use svnrdump. Then instead of going to
the network, the command you run magically uses your test data
instead.
If the command you are testing wanted to run "svnrdump" without the
upper endpoint set, we need to handle that request, either by emitting
all the revs we have, or by stopping somewhere. The revlimit feature
provides the "stopping somewhere" behavior which is not strictly
needed but is presumably very useful when testing incremental fetch.
Florian, do you mind if I make the revlimit feature a separate patch
when applying this?
Anyway, it looks good and reasonable to me, so will apply.
Thanks.
Jonathan
next prev parent reply other threads:[~2012-07-24 19:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-22 21:03 GSOC remote-svn Florian Achleitner
2012-07-22 21:43 ` Jonathan Nieder
2012-07-23 9:42 ` Florian Achleitner
2012-07-23 12:04 ` Jonathan Nieder
2012-07-23 12:44 ` [PATCH] Add a svnrdump-simulator replaying a dump file for testing Florian Achleitner
2012-07-23 12:59 ` Jonathan Nieder
2012-07-23 13:16 ` Florian Achleitner
2012-07-23 13:16 ` Florian Achleitner
2012-07-23 16:24 ` Matthieu Moy
2012-07-23 19:28 ` Florian Achleitner
2012-07-23 19:46 ` Matthieu Moy
2012-07-23 20:02 ` Jeff King
2012-07-23 15:06 ` Junio C Hamano
2012-07-23 20:08 ` Florian Achleitner
2012-07-23 20:38 ` Junio C Hamano
2012-07-24 19:50 ` Jonathan Nieder [this message]
2012-07-25 6:20 ` Florian Achleitner
2012-07-24 12:06 ` Erik Faye-Lund
2012-07-23 7:59 ` GSOC remote-svn Matthieu Moy
2012-07-23 11:59 ` Jonathan Nieder
2012-07-23 9:42 ` Florian Achleitner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120724195049.GD5210@burratino \
--to=jrnieder@gmail.com \
--cc=davidbarr@google.com \
--cc=florian.achleitner.2.6.31@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).