Re: RFCs on new cvs2* features
Greg Ward <[email protected]> Tue, 5 Feb 2013 10:17:47 -0500
| Newsgroups | gmane.comp.version-control.subversion.cvs2svn.devel |
|---|---|
| Message-ID | <[email protected]> |
On 08 January 2013, Eric S. Raymond said:
> Three proposals for discussion:
Sorry to jump in so late on this, but what the heck it's a pretty
low-volume list.
> 1. cvs2* is still too noisy in an un-useful way.
Agreed, but...
>
> The stats at the end of the run are not very interesting except as
> diagnostics for developers. The present design still violates
> the Unix maxim that programs should run quietly unless (a) they
> have an exception to report, or (b) the expected runtime is so
> long that silence could be confused with "it's hung".
>
> Therefore: the end-of-run report ought to be disabled by default and
> enabled with a --stats option.
>
> 2. cvs2* should have a twirling-baton progress meter
Yeah, OK, *but but but* ...
> Because these tools do run long on large repositories, a visual progress
> indication would be a good idea in the default running mode. But pass
> messages are too heavyweight and mainly of interest to developers.
...here's where I disagree. I think knowing what pass is running is
useful when things go off the rails. Possible compromise:
Pass 1/16 [============================================]
Pass 2/16 [============================================]
Pass 3/16 [===============/
...i.e a twirling-baton for each pass as it goes.
Rationale: my main experience with cvs2* was a 12-hour conversion
using my cvs2hg fork (https://hg.gerg.ca/cvs2svn/). For reasons I was
never able to figure out, it occasionally crashed with MemoryError on
pass 14 or 15 (can't remember which). It was easy to recover by
restarting from the crashed pass, so it only wasted 30 or 40 minutes
of the 12 hours. But if I had not had that information, I would have
been *very* frustrated by having to rerun the whole damn conversion.
Sure, it's easy for cvs2* to catch exceptions and tell you exactly
where it was in case of a crash. But giving a little more context to
the user just feels safer to me. Giving up 16 lines of shell context
for a 12-hour run seems fine to me. IMHO, "Silence is golden" is less
applicable the longer a tool takes to run.
Greg
--
Greg Ward http://www.gerg.ca
<[email protected]> @gergdotca
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=3047697
To unsubscribe from this discussion, e-mail: [[email protected]].