On Wed, Dec 16, 2015 at 11:16 AM, Richard Hipp <d...@sqlite.org> wrote:
> Based on comments on HN and on this mailing list, I have attempted to > rewrite the fossil-v-git.wiki document > (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to > better summarize the differences between the two products. > > Your feedback on the rewrite, and especially suggestions for improving > it, are welcomed. > The doc says: > If you start out using one DVCS and later decide you like the other better, it is easy to change <https://www.fossil-scm.org/fossil/doc/trunk/www/inout.wiki>. DRH and crew have defined "easy to change" (meaning easy to migrate away from) in a way that is misleadingly narrow for many people. The reason is that if you are using Fossil with its ticket tracker, then there is no simple way to export those tickets to any current member of the Git ecosystem that does ticket tracking (e.g. Jira). Providing an outbound export interface to at least one such tool would further strengthen the claim that it is easy to migrate away from Fossil. Otherwise, users will be "locked in" in the sense that their tickets are stuck in Fossil, where it is hard to properly cross-reference them with the ongoing stream of check-ins after export to Git. In the past, DRH has criticized my above observations by saying that since Fossil is backed by an SQLite database which the user may query at his or her leisure, this should suffice for an export capability for tickets. This criticism does not hold much water, however, since we can observe the following: (1) The raw check-in data is *also* backed by an SQLite database. But the Fossil dev team saw fit to write an export-to-git capability on top of that. This is an internal inconsistency in DRH's argument, since ostensibly the devs don't think the git export capability was a mistake. (2) The reasons for having written an export-to-git capability are good reasons. Analogously to Word's ability to export to PDF, the application in question knows both the source and target data formats and how to do the relevant translations. Indeed, the whole purpose of export can be seen as relieving the user of the burden of understanding the source and target data formats and performing the conversions. (In a prior thread on this topic, someone criticized this point by saying that Microsoft has more developer power than does Fossil. This, while true, is irrelevant to questions about whether such an export feature would be useful.) And in particular, merely having a well-understood data format does not suffice: Word cannot claim to have the ability to export to PDF *merely* because its internal data format is public. (3) The reasons in (2) generalize to the case of tickets. DRH has made another criticism of my observations which was that no other ticket manager permits easy export of its tickets to a 3rd-party ticket manager. Whether this is true or not, it is again irrelevant to my claim that Fossil's ticket system is not, in fact, easy to migrate away from. Eric
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
