Deskin Miller <deskinm@xxxxxxxxx> wrote: > When initializing a git-svn repository from a Subversion repository, it > is common to be interested in a path which did not exist in the initial > commit to Subversion. In a large repository like e.g. Apache, this may > take some time while the user receives no additional feedback. Print > the highest revision number scanned thus far to let the user know > something is still happening. > > Signed-off-by: Deskin Miller <deskinm@xxxxxxxxx> > --- > This came about on account of patmaddox asking on #git why git-svn > seemed to be hung on clone. Despite the admonition that this might take > a long time, I also like to have some indication that progress is being > made. My first version of this printed using '\rChecked through > r$revision' but the subsequent output line when the path is found ends > up clobbered on the same line, and I'm not skilled enough at the > terminal or Perl to address this cleanly. If the current version is > felt to be too verbose since it is printing a new line, I'd be up for > squelching the output to e.g. every 1000 revisions or so. This is definitely useful on slow/large repositories. The current output with newlines is fine by me. > Anecdotally, it looks like Subversion looks for the path in blocks of > 100 revisions, so we get the nice whole revision number for free. I > couldn't find any documentation on the proper format of the error > message, so I just came up with the regular expressions to parse the > revision myself; if they need to be more explicit to avoid really > egregious path names, I can make an effort. > > I tested on both http:// and file:// transport, to come up with the > different error strings; since the error number for file is the same as > svn:// I'm hoping that the error string is the same too. If someone can > bounce this off a svn:// repo I'd appreciate it, otherwise I'll dig out > the documentation and set up a network-served svn repository myself > (which is really my job as the patch author anyway). Couldn't we avoid the trouble of parsing the inconsistent error messages by printing this status message after the get_log() calls in gs_fetch_loop_common() ? -- Eric Wong -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
