I'm starting a company with some folks.  Their notion of the default choice
for SCM is git + JIRA for bug tracking + some other tool we'd pick for code
review.  This is probably quite common.  Since the answers to my questions
will probably be interesting to a relatively wide audience, I hope the
forum will forgive the length of my post.

By 'code review' here I mean a web-based tool that has a formalized state
machine for (a) uploading code deltas (b) filing and fixing defects against
the uploaded code and (c) having the right set of people sign off.  Like
Code Collaborator.  I guess JIRA has an integrated tool that is free for
small teams too.  Whatever.  It just needs to eventually support reviewing
every line of code that gets written, in case we decide to go in that
direction.

I'm trying to convince my co-founders to use fossil.  I won't address all
of fossil's strengths, since you will all agree with me.  I want you to
give me some ammunition on the weaker points:

 * Export of tickets.

If we want to move away from fossil to a git-based thing in the future, we
can export the source version history, though that is not as trivial as the
Fossil page on the matter makes it seem (see below).

Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs
right from the SQLite database, massage them, and import them into JIRA (or
whatever tool).  (In reality, it looks like JIRA supports JSON import, so
I'd probably wind up writing code to read the SQLite database and emit JSON
instead of CSV -- but whatever, similar idea.)  I'm guessing this would be
like a 1-day project for a relatively large set of tickets.

Furthermore, I'd need to massage all of the check-in comments themselves in
order to reference the new JIRA IDs for tickets rather than the Fossil
IDs.  Is there a better story than this?

 * Code review!

DRH has said on this forum (and I'm paraphrasing here) that he prefers to
review humans more than code.  If he decides he trusts the human, then he
mostly trusts the human's output.  So he didn't really care to write a
native tool for code review for Fossil.

This is what I think I need the most help with.  While I feel mostly the
same as DRH on the matter, I also would like to have a story in case one
day the team decides they want to have every line go through a review
process.  If I don't have a story up front for that then it will be a
biasing factor against Fossil, since it will be more likely we'd need to go
through a transition (one they would worry is onerous or error-prone) to
some other SCM in the future.

I've come up with some work-flows that sort of simulate code reviews right
from within fossil.  For example, you might make each of your check-ins on
its own branch, and when that check-in is accepted it gets merged into the
feature branch.  The existence of a pending review is signaled by a naming
convention on the branches; devs are trained to do an 'lsbranch | grep
<conventional name>' every X days or whatever.  Defects are filed by
writing comments right into the code under a certain convention and
checking in the commented code against the review branch.  This still
leaves a lot to be desired (e.g. it's very awkward at best for reviewers to
write defects, assign severities to the defects and so on).

My major questions here are:

 (1) I know the fossil devs had considered writing a native proper code
review feature.  Is that anywhere on the near-term road map?

 (2) Are there 3rd-party code review tools that (a) are good and (b)
support fossil?

 (3) Are there clever work-flows using native fossil features that more
closely resemble proper code review tools than the sort of bad one that I
sketched above?

Thanks!
Eric
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to