From: Eric Wong <normalperson@yhbt.net>
To: Bill Priest <priestwilliaml@yahoo.com>
Cc: git@vger.kernel.org
Subject: Re: git svn dcommit -n rebuilds revmap w/ 1.5.4.rc0.1187.gc1e8d
Date: Wed, 19 Dec 2007 22:55:13 -0800 [thread overview]
Message-ID: <20071220065513.GC17787@muzzle> (raw)
In-Reply-To: <784879.48443.qm@web55007.mail.re4.yahoo.com>
Bill Priest <priestwilliaml@yahoo.com> wrote:
> All,
> I had been experiencing commit slow downs (> 15
> seconds) so I decided to test it out on 1.5.4.rc0. I
> use committed a file and it too ~5 seconds which is
> slower than it used to be but much better (I'll need
> to do an apples to apples test to quantify it better;
> e.g. check in the same file w/ a repository in the
> same state). In the course of using 1.5.4.rc0 I did a
> git svn dcommit -n and observed the following:
Are these slowdowns for commits using git-commit? or for using git-svn
dcommit?
The new rev_map format is very space-efficient, but I haven't optimized
for performance, yet. It seems to do well enough on Linux that I
don't notice any performance penalty/improvement. I'm also network
I/O bound for real-world SVN usage, too.
I haven't benchmarked .rev_map much, but the binary search could
certainly be optimized to avoid extra seeks if needed.
> > git svn dcommit -n
> Rebuilding
> .git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
> ...
> r2918 = 992aa04a75fffdbdb65bae815905f96d5e3ef6bd
> r2920 = e68e7f5aead05fc9e7a151e95f43b8283b0ed670
> Done rebuilding
> .git/svn/mss_release_2.1B3/.rev_map.59aec714-b326-0410-a24e-830352df6fdd
> Committing to
> svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
> ...
> diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
> b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
> diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
> 0bbb656391f5a888d07c98ccce01a4c753ef4997
> > git svn dcommit -n
> Committing to
> svn://lucille/var/lib/svnrepos/svnMSS/branches/mss_release_2.1B3
> ...
> diff-tree b7cc4c3d32478277c1cdf13e3abdc9dd4a225826~1
> b7cc4c3d32478277c1cdf13e3abdc9dd4a225826
> diff-tree 0bbb656391f5a888d07c98ccce01a4c753ef4997~1
> 0bbb656391f5a888d07c98ccce01a4c753ef4997
> > git --version
> git version 1.5.4.rc0.1187.gc1e8d
>
> Notice the Rebuilding doesn't seem to be honoring the
> -n "dry run" switch.
>
> I'm not sure of the implications. Is this something
> that I should worry about the .revmap being out of
> sync w/ what has actually been dcommit'ed?
--dry-run only means that it won't write to the SVN repository.
There's no need to worry about stuff that's out of sync, .rev_map only
stores information about commits already made to SVN, and is more of an
internal cache for most repositories.
All .rev_map and .rev_db files it replaces are safely deletable
unless you're using noMetadata or useSvmProps with git-svn.
--
Eric Wong
prev parent reply other threads:[~2007-12-20 6:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-19 19:04 git svn dcommit -n rebuilds revmap w/ 1.5.4.rc0.1187.gc1e8d Bill Priest
2007-12-20 6:55 ` Eric Wong [this message]
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=20071220065513.GC17787@muzzle \
--to=normalperson@yhbt.net \
--cc=git@vger.kernel.org \
--cc=priestwilliaml@yahoo.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).