[I'm sorry; I see that I directed this email to the Subversion mailing
list instead of the cvs2svn mailing list. Please direct followups to
users@cvs2svn.tigris.org.]
Robin H. Johnson wrote:
> On Thu, Nov 29, 2007 at 04:25:46PM +0100, Michael Haggerty wrote:
>>> XFAIL: run-tests.py 80: reveal a second bug that created a branch twice
>> It is a bit confusing, but "XFAIL" means that the test is known to fail.
>> The only tests that are currently "XFAIL" are minor issues and/or
>> planned enhancements that that are not yet implemented. AFAIK, the
>> current trunk version is even more stable than the last official
>> release. If you see any tests that "FAIL", *then* you should worry.
> How about supressing the expected traceback then, like other
> dejagnu-powered testsuites do? This would make it much easier to read
> and realize that nothing is wrong.
Our test suite is not dejagnu-powered. It is borrowed from the
Subversion project, which AFAIK developed it.
Somebody turned the traceback on recently. I agree that it would be
preferable to suppress the traceback for XFAIL tests.
>> Of course there might still be bugs, especially the git part, which is
>> still quite new. So we'd be very happy to get feedback about how it
>> works for you, and especially comparisons (ease of use, quality of
>> conversion) with any other CVS -> git tools that you may have tried.
> I was batch converting a lot (50+) of my old personal repos, and a
> couple of things that would be nice (some of them are doable in Git
> already, but they would be handy for SVN as well):
> - author rewriting: both a simple foo->bar, as well as a the 'authors'
> style of git-svn (and possible to apply both).
Yup, this would be good. Would you mind filing an enhancement request
for this in the cvs2svn bug tracker so that the wish isn't forgotten?
> - Time rewriting for timezone tweaking (say the original CVS repo was in
> EST, but you want to convert to UTC now).
But CVS always stores timestamps in UTC, and I thought that git does the
same. Thus this feature should not be needed. Have you seen a case
where such translation is necessary?
> - cvs-import takes the initial source, and the vendor and release tags -
> it would be nice to be able to suppress the useless vendor branch.
> Easily identifiable by it's RCS revision of 1.1.1. Maybe something in
> the strategies to exclude by the value of the symbol, rather than the
> name of the symbol.
This feature is in the works. Please note that the vendor branch is not
always useless, so this would have to be optional. And often other
branches or tags appear to sprout from the vendor branch (even if they
were really added on trunk); these have to be grafted onto trunk.
There's some code in cvs2svn to do this, but some more work is still needed.
> - Using options to load defaults, but still allowing more configuration
> variables on the commandline: I wanted an options file that got the
> CVS repo path from the commandline, and used it to produce the
> destination location. I did a hack making a git.options.in file, that
> I used sed to insert a single value, generating a git.options file for
> each repo. Maybe making the cvs repo an option instead of an argument
> would make this easiest.
Hmm, sounds a little bit specialized and workarounds are available. And
often people will want to process multiple CVS projects at once.
I suppose one could add something like an --optargs=value option which
somehow makes the "values" available to the options file. It would be
free to use the options however it liked.
Patches are welcome :-)
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 30 15:20:52 2007