[RFC/bzr-cvsps-import] Support for "bzr cvsps-import --fuzz=SECONDS"

[Harald Meland]

On 22/10/2007, John Arbash Meinel <john at arbash-meinel.com> wrote:
> I'm not sure about this part:
> - -        cmd = ['cvsps', '--cvs-direct', '-A', '-u', '-q',
> - -               '--root', self.cvs_root,
> - -               module,
> - -              ]
> +        cvsps_args = ['--cvs-direct', '-A', '-u', '-q',
> +                      '--root', self.cvs_root,
> +                      ]
> +        if fuzz is not None:
> +            cvsps_args.extend(['-z', str(fuzz)])
> +        cmd = ['cvsps'] + cvsps_args + [module]
>
> I personally would prefer:
>        cmd = ['cvsps', '--cvs-direct', '-A', '-u', '-q',
>               '--root', self.cvs_root,
>              ]
>        if fuzz is not None:
>            cmd.extend(['-z', str(fuzz)])
>        cmd.append(module)
>
> Do you have a reason for preferring the other way?

I thought it slightly better to not mix the command line options with
neither the command itself nor its non-optional arguments until we'd
finished reorganizing the list of options.  I guess this might be more
of an issue if we tried to expose more of cvsps's options, e.g. "-x"
versus "-u"; is things stand now I'm happy to go with your suggestion.

> We *could* always nuke the files in ~/.cvsps, but then you lose any caching
> that cvsps does.

Exactly, hence my comment that it would be nice if cvsps itself caught
onto the fact that its cache was out-of-date.

> I suppose you could store some settings in the conversion
> files, and then see if things have changed. But that doesn't help if you try to
> start the conversion 2 completely separate times.

Yup, my initial attempt at re-importing consisted of "delete old
'cvsps-import'-generated tree, and restart the command with a
non-default --fuzz", so any "should I reuse the cache or not" data
that cvsps-import might keep around would have had to live outside the
tree it generated to be effective.  I guess one could stuff something
into ~/.bazaar/, but I'd much prefer to fix this in cvsps (e.g. by
having it store which options were used in the generated dump file).

> Anyway, I'm happy to merge a patch like this if people find it useful.

It's already proven useful to me, at least. :-)

> Also, make sure you've updated to the tip of my trunk branch. I recently pushed
> up some changes which should make it work with bzr.dev. I also pushed up some
> older code I had which improved the parsing speed and memory consumption, as
> well as making sure that file ids are static across branches.

The API change that my bzr.dev attempt was having trouble with was the
missing ``content_summary'' argument in importer.py's call to
builder.record_entry_contents(); I don't think that's fixed yet in
trunk.
-- 
Harald