Advice/help wanted on bzr fast-export-from-cvs

[Michael Haggerty]

Ian Clatworthy wrote:
> I've started digging into this in some more depth now. I'd like to
> request two small tweaks to make cvs2git more bzr friendly:
> 
> 1. Can we remove the restriction that the --options file is
>    incompatible with most other options? I'd prefer to see other options
>    override settings in there. See below.

For some options, it would be easy to remove this restriction.  For
others, it would be rather awkward, because the options file is generic
Python code; it doesn't just write information to some "options"
dictionary, but actually does nontrivial configuration of things that
are sometimes order-dependent.

So I suggest that you give me a list of the options that you would like
to use in conjunction with an options file, and I'll check them out on a
case-by-case basis.  Would that be doable?

> 2. This one is more a nice to have: if --blob-file and --dump-file
>    have the same value, then the dump information should be appended
>    to the blob information.

This would be easy to implement, with the caveat that OutputPass can
never be restarted.  Well, I guess one could remember the previous
length of the file and truncate it if necessary at the beginning of
OutputPass.

> I think the first change is really important because it means we can
> provide a cvs2bzr-example.options file and use it by default in a
> wrapper script. That wrapper script would only have one or two options
> say, e.g. path-to-sort-program so that Windows users could specify that
> *without* needing to grok the options file. The help for the wrapper
> script would say something like "if finer control is needed, use svn2git
> directly together with a custom options file based on
> cvs2bzr-examples.options". Make sense?

I don't quite understand.  Which of these components (options files,
wrapper scripts) do you intend to become part of the cvs2svn project,
and which would be part of the bazaar convert tool?

Before you answer :-) , please note that we currently DO NOT guarantee
portability of options files across versions of cvs2svn.  If you want to
keep an options file outside of the cvs2svn project (let alone generate
one automatically), you will have to require a specific version of
cvs2svn or track cvs2svn versions somehow.  The command-line options, on
the other hand, are much more stable; I don't think we have had any
backwards-incompatible command-line option changes since I've been in
the project.

Currently, we have roughly the policy you describe WRT cvs2svn and
cvs2git; namely, that there are top-level scripts that can set most
options (but these scripts are NOT dependent on the options files) OR
the example options files can be used in combination with a few
"options-compatible" command-line options.  We keep the example options
files in approximate sync with the corresponding command-line defaults
to try to allow users an easy transition from one method to the other.

So why don't we add a top-level cvs2bzr script and a
cvs2bzr-example.options file within the cvs2svn project?  (Most of the
code can be shared with cvs2git and maybe the upcoming cvs2hg.)  With
luck we can select a few more command-line options to be made compatible
with --options and cover your needs that way.

Michael