On Fri, Feb 20, 2009 at 11:21:38AM +0100, Michael Haggerty wrote: > > I do wonder, though, whether it would be simpler to make a "cvs import > > test suite" that could pluggably test cvs2svn, git-cvsimport, or other > > converters. Then you could test each on the exact same set of test > > repos. And abstracting "OK, now make a repository from this cvsroot" > > wouldn't be that hard for each command (I wouldn't think, but obviously > > I haven't tried it :) ). > [...] > But other tests would be harder to write in a neutral fashion. For > example, the cvs2svn test suite has tests of log messages, character-set > conversions of metadata, correct commit ordering, branching topology, etc. OK. I haven't looked at it and you have, so I will accept your judgement. > > The code in t9600 (which gets moved to lib-cvs in your patch 1) sets > > HOME explicitly. So is this really a problem? > > That's a good question. I just checked, and empirically cvs uses .cvsrc > from my true home directory even if HOME is set differently. So I think > that the -f option is indeed necessary. Yuck. But if that's the way it works, then I think your patch is the only way. > > Cool. Are you volunteering to fix git-cvsimport, too? :) > Not unless you call cvs2git the fixed version :-) Heh. > design limits). But I hope to raise awareness that cvsps-based tools > are not the best choice for "one-shot" conversions, and maybe work > against people's tendency to use the "default" tool unless it obviously > blows up. Agreed. I have seen that advice given on the list several times, and it seems to be working for people. So it really is about the right tool for the job, IMHO. -Peff -- 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
