[RFC/bzr-cvsps-import] Support for "bzr cvsps-import --fuzz=SECONDS"
Harald Meland
haraldme at gmail.com
Mon Oct 22 20:49:56 BST 2007
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
More information about the bazaar
mailing list