git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: cvsps, parsecvs, svn2git and the CVS exporter mess

From
Eric S. Raymond <esr@thyrsus.com>
Date
Jan 5, 2013, 15:11 UTC
Message-ID
<20130105151106.GA1938@thyrsus.com>
In-Reply-To
<1E7F9F86-F040-42E4-98C4-152B8CCE47CE@quendi.de>
Max Horn <postbox@quendi.de>:
Show 8 quoted lines
> Hm, you snipped this part of Michael's mail:
> 
> >> However, if that is a
> >> problem, it is possible to configure cvs2git to write the blobs inline
> >> with the rest of the dumpfile (this mode is supported because "hg
> >> fast-import" doesn't support detached blobs).
> 
> I would call "hg fast-import" a main potential customer, given that there "cvs2hg" is another part of the cvs2svn suite. So I can't quite see how you can come to your conclusion above...

Perhaps I was unclear. I consider the interface design error to be not in the fact that all the blobs are written first or detached, but rather that the implementation detail of the two separate journal files is ever exposed.

I understand why the storage of intermediate results was done this
way, in order to decrease the tool's working set during the run, but
finishing by automatically concatenating the results and streaming
them to stdout would surely have been the right thing here.
 
The downstream cost of letting the journalling implementation be
exposed, instead, can be seen in this snippet from the new git-cvsimport
I've been working on:
    def command(self):
        "Emit the command implied by all previous options."
        return "(cvs2git --username=git-cvsimport --quiet --quiet --blobfile={0} --dumpfile={1} {2} {3} && cat {0} {1} && rm {0} {1})".format(tempfile.mkstemp()[1], tempfile.mkstemp()[1], self.opts, self.modulepath)

According to the documentation, every caller of csv2git must go through analogous contortions! This is not the Unix way; if Unix design principles had been minimally applied, that second line would just read like this:

     return "cvs2git --username=git-cvsimport --quiet --quiet"

If Unix design principles had been thoroughly applied, the "--quiet --quiet" part would be unnecessary too - well-behaved Unix commands *default* to being completely quiet unless either (a) they have an exceptional condition to report, or (b) their expected running time is so long that tasteful silence would leave users in doubt that they're working.

(And yes, I do think violating these principles is a lapse of taste when git tools do it, too.)

Michael Haggerty wants me to trust that cvs2git's analysis stage has been fixed, but I must say that is a more difficult leap of faith when two of the most visible things about it are still (a) a conspicuous instance of interface misdesign, and (b) documentation that is careless and incomplete.

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Previous: Max HornNext: Jonathan Nieder
Message 7 of 11 in “cvsps, parsecvs, svn2git and the CVS exporter mess”
  1. Eric S. RaymondDec 22, 2012
  2. Heiko VoigtDec 23, 2012
  3. Eric S. RaymondDec 23, 2012
  4. Michael HaggertyJan 3, 2013
  5. Eric S. RaymondJan 3, 2013
  6. Max HornJan 5, 2013
  7. Eric S. RaymondJan 5, 2013
  8. Jonathan NiederJan 5, 2013
  9. Michael HaggertyJan 6, 2013
  10. Martin LanghoffJan 3, 2013
  11. Eric S. RaymondJan 5, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.