Re: RFCs on new cvs2* features

On 01/08/2013 12:46 PM, Eric S. Raymond wrote:
> Three proposals for discussion:
> 
> 1. cvs2* is still too noisy in an un-useful way.
> 
> 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.

cvs2svn *does* typically require a while to run.  And I remember that
when I used cvs2svn, I appreciated seeing what it was up to and seeing
the statistics at the end of the run.  So I personally think the
verbosity level is OK the way it is.

Other developers/users are of course free to chime in; I would have no
problem with being outvoted.

> 2. cvs2* should have a twirling-baton progress meter
> 
> 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.
> Ideally we want a progress meter that is relatively fine-grained but
> doesn't hog a lot of vertical screen space, so you don't visually lose your
> shell-session context when you run the tool.
> 
> The design trope I have found to be most effective in this situation
> is a twirling-baton prompt.  To see how this works, ask reposurgeon
> to do a read on a largish repository.  What it does is repeatedly use the
> sequence ^H|^H/^H-^H\ to animate a twirling baton; each quarter-spin
> is triggered by baton.twirl() calls at relatively frequent intervals
> like "we just processed a commit".  Of course --quiet should suppress this.

This seems to somewhat contradict the preference for silence that you
expressed in point 1.  I prefer the current output, which gives a hint
of what *fraction* of the conversion is done, rather than a baton, which
only tells you that the program hasn't died.  But again, I am open to
being outvoted.

> 3. Access to remote repositories
> 
> I've been doing a lot of work lately on another CVS lifter called
> cvsps.  It's written in C, and its topo-analysis code is not all that
> good.  But it does have another potentially very valuable module in it. 
> cvsclient.c opens a socket connection to a designated remote CVS
> server and can fetch all the RCS files in the repository from same.

This would be useful if it could be made to work reliably.

I've never looked at the CVS protocol in detail.  (Where is it best
documented?)  Is it possible to retrieve the RCS files in their original
form over the protocol?  Or do the files have to be reconstructed based
on information that is available in other forms via the protocol?  Does
the protocol send file deltas or always the fulltext?

I ask because we use some information from the RCS files that might not
be preserved by a piecemeal retrieval.  For example, we use the order
that symbols are listed as an indication of the (reverse) order that
they were probably created.

Currently we suggest the possibility of using an external tool to
retrieve a copy of a remote CVS repository [1], but that usage is not
really tested or supported.

> This code could be translated to a Python class with little 
> difficulty. (In fact I wrote a mechanical C-to-Python translator 
> some years back that would do most of the work.)  I could deliver that
> with a test main that would prove its performance.
> 
> The part I don't want to do is mating the client class to the analysis 
> stage in cvs2*. Is somebody else interested enough in remote
> repository access to do that?

The easiest way to interface this functionality to cvs2svn would be to
have the protocol client write rcsfiles to local disk (i.e., retrieve a
mirror of the CVS repository) and convert from the on-disk copy.  There
are configurations for which cvs2git reads RCS files more than once, so
at least some local caching of the information retrieved from the remote
repo would be advantageous.  Allowing cvs2xxx to be fed with data in a
different format would of course also be possible but would require much
more work.

Michael

[1] http://cvs2svn.tigris.org/faq.html#repoaccess

-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1667&dsMessageId=3043077

To unsubscribe from this discussion, e-mail: [[email protected]].