From: Ramkumar Ramachandra <artagnon@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
David Michael Barr <david.barr@cordelta.com>,
Sverre Rabbelier <srabbelier@gmail.com>,
Michael J Gruber <git@drmicha.warpmail.net>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH 5/6] Add infrastructure to write revisions in fast-export format
Date: Mon, 7 Jun 2010 14:35:30 +0200 [thread overview]
Message-ID: <AANLkTilqFNqGj8rq3fHZld6ddkHLp_usQSQKgQqeAt0X@mail.gmail.com> (raw)
In-Reply-To: <20100604190222.GB21295@progeny.tock>
Hi Jonathan,
Jonathan Nieder wrote:
> The big downside is that as David mentioned it does not scale well with
> the size of the directory and number of expansions. But a patch is in
> the pipeline to fix that. I do not think it should hold the series up.
Right. The `dirents` branch is now merged.
> Style: would probably be clearer to write:
>
> while (~(name = *path++)) {
> dirent = repo_dirent_by_name(dir, name);
> if (!dirent || !repo_dirent_is_dir(dirent))
> break;
> dir = repo_dir_from_dirent(dirent);
> }
>
> i.e., fewer unnecessary braces, and dealing with the exceptional cases
> separately from the normal case.
This was (probably unintentionally) re-factored by David when merging
in his `dirents` branch.
> As before, I wonder about the error cases. Might it make sense to
> report the error if someone tries to copy a nonexistent directory
> from a previous revision?
> Function is too long for my taste (I realize this is a matter of
> taste). The innermost blocks would make sense as functions in their
> own right.
This came up in your previous review- I tried to split it up into more
functions, but due to the number of local variables, it turned out to
be a mess and I had to revert. Would you like to try re-factoring it?
> My 80-column terminal is suffering. Why not use the common
> pattern?
Re-factored (again, probably unintentionally) by David during the merge.
> These limits are not checked; is the caller supposed to check them
> itself? Does svn obey them?
I asked David too, and as far as we know, these limits are pretty
arbitrary. They're no enforced by SVN or any specific filesystem. We
can discuss about having less arbitrary limits and checking it in
svndump.c (while parsing the dump).
-- Ram
next prev parent reply other threads:[~2010-06-07 12:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-04 13:41 [PATCH 0/6] Merge David's SVN exporter Ramkumar Ramachandra
2010-06-04 13:41 ` [PATCH 1/6] Add memory pool library Ramkumar Ramachandra
2010-06-04 18:29 ` Jonathan Nieder
2010-06-07 13:28 ` Ramkumar Ramachandra
2010-06-07 14:00 ` Erik Faye-Lund
2010-06-07 14:35 ` Ramkumar Ramachandra
2010-06-04 13:41 ` [PATCH 2/6] Add cpp macro implementation of treaps Ramkumar Ramachandra
2010-06-04 13:41 ` [PATCH 3/6] Add library for string-specific memory pool Ramkumar Ramachandra
2010-06-04 13:41 ` [PATCH 4/6] Add stream helper library Ramkumar Ramachandra
2010-06-04 18:35 ` Jonathan Nieder
2010-06-04 13:41 ` [PATCH 5/6] Add infrastructure to write revisions in fast-export format Ramkumar Ramachandra
2010-06-04 19:02 ` Jonathan Nieder
2010-06-07 12:35 ` Ramkumar Ramachandra [this message]
2010-06-07 13:36 ` David Michael Barr
2010-06-04 13:41 ` [PATCH 6/6] Add SVN dump parser Ramkumar Ramachandra
-- strict thread matches above, loose matches on Subject: below --
2010-06-10 13:09 [PATCH 0/6] Another attempt to get the SVN exporter merged Ramkumar Ramachandra
2010-06-10 13:09 ` [PATCH 5/6] Add infrastructure to write revisions in fast-export format Ramkumar Ramachandra
2010-06-04 13:26 [PATCH 0/6] Merge David's SVN exporter into git.git Ramkumar Ramachandra
2010-06-04 13:26 ` [PATCH 5/6] Add infrastructure to write revisions in fast-export format Ramkumar Ramachandra
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=AANLkTilqFNqGj8rq3fHZld6ddkHLp_usQSQKgQqeAt0X@mail.gmail.com \
--to=artagnon@gmail.com \
--cc=david.barr@cordelta.com \
--cc=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=srabbelier@gmail.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).