[darcs-users] proposal for 2.8 : fastconvert (and remark on the process)

Guillaume Hoffmann guillaumh at gmail.com
Sun Dec 5 18:04:23 UTC 2010

It is now clear that darcs-fastconvert shall be taken under the darcs
umbrella and enjoy the project's infrastructures. Max and Florent,
suggested that we provide binaries for darcs-fastconvert along with
darcs. As Eric said, it's up to the release managers and packagers to
decide that and see how they want to package the bundle.

Now, Petr's suggestion is to separate darcs-cmdline from libdarcs, and
make darcs-fastconvert provide a libdarcsfastconvert API. Then
darcs-cmdline will be able to depend easily on libdarcsfastconvert.
This is very seducing but the big question is: how much work is needed
to separate darcs-cmdline from libdarcs? Should we commit to that goal
as soon as possible? After the codebase has read-only OF support?

We don't agree about what to do with FC, but it's fine since it's not
the right moment to include it in darcs anyway, if we want to avoid
codebase growth before engaging major refactoring. So what about this

1. separate darcs-cmdline from libdarcs
2. in parallel, Petr provides libdarcsfastconvert
3. when both are done, we put the topic back on the table: shall the
darcs commandline UI come by default with its subcommand
``fastconvert`` ?

Is it time for a thread on darcs-cmdline/libdarcs separation?


ps: FC could indeed be a plugin, but because of the reasons I said, it
is much more important than, say, a Musdex plugin. Max, maybe you want
to start a thread on plugins? (possibly with a wiki page to detail a
proposal?) (I'm certainly not against seeing a Musdex plugin

ps2: Florent said that FC should not be a ``convert`` sub-subcommand.
Fair enough, we could use ``darcs fastconvert``, just as all the
``git-subcommand`` executables became ``git subcommand``.

More information about the darcs-users mailing list