Hi everyone, in August, Petr proposed a patch to have the commands ``convert --import`` and ``convert --export``:
http://lists.osuosl.org/pipermail/darcs-users/2010-August/024754.html The answers to this were that it was better to keep this feature as a separate tool. In particular (as Ganesh said), if people start relying on this feature on a regular basis to keep darcs-git mirrors, we should guarantee them some stability. Eric concluded: "Or maybe to develop a style of working on new features where we let them stand alone for a little while (incubation phase) and then fold them into Darcs as it becomes clear how important they are and how to fit them in." So Petr wrote darcs-fastconvert and released it on Hackage: http://lists.osuosl.org/pipermail/darcs-users/2010-August/024987.html Which is now a usable tool that has already helped a few people convert and maintain mirrors of darcs repositories: * http://www.serpentine.com/blog/2010/10/21/how-to-migrate-from-darcs-to-mercurial-or-git/ * http://tab.snarc.org/blog/post/2010/11/17/darcs_mirrors_to_git/ * http://webcache.googleusercontent.com/search?q=cache:oFiMzMUCCC8J:sgenomics.org/~jtang/blog/ I think now there has been enough incubation and testing for this feature, and it should be included in 2.8 as subcommands of ``convert``. Why have it inside of Darcs? Well I have recently read the manual of another SCM called Fossil ( http://www.fossil-scm.org ) and it does have an integrated ``convert`` subcommand. And it makes sense: like Darcs, Fossil has few users and has to live in a world where Git and Github are very common. Switching to Darcs or Fossil has to be as easy as possible for users, hence the integrated fastconvert feature makes sense. Not everyone can afford to install the Haskell Platform and build darcs-fastconvert themselves. If we agree on having this in 2.8, there is no hurry to do it now. Maybe we can plan to have it in Darcs once the changes to drop writing support for OF repositories are done. (By "we", I'm mostly involving Petr because it would be easier for him to do the inclusion, and probably not harder than maintaining fastconvert itself). What do you think? Now about the process: The fact that darcs-fastconvert was released as a separate package has enabled users to try it outside of the Darcs release schedule. I'm glad the feature took that path in the first place: it wouldn't have been included in 2.5 anyway because of the freeze. It has worked great. Also it made Petr use libdarcs, so we have another proof that it's possible to write something on top of libdarcs :-) The only bad thing is that we had no planned reevaluation of the situation. This may be a little discouraging for the submitter. We can easily improve this aspect the next time such a situation occurs, and use the page http://wiki.darcs.net/Roadmap as a reminder to put the topic back on the table at the right moment. For the features that can be externalized, this seems to be an adequate procedure. Guillaume _______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
