On Tue, May 28, 2013 at 12:10 PM, Laurens Van Houtven <_...@lvh.io> wrote:
> It is my understanding that Fossil doesn't come with such a tool for code > reviews. > Correct. > Additionally, the entire point of autosync by default is to prevent having > to branch and merge all the time. > Not entirely. It's mainly (or largely) to avoid accidental forks. Early on in the project we had accidental forks relatively often (fossil used to fork automatically, but no longer does). Turning on autosync removes 90%+ of those cases. So, I'm wondering, do you: > > 1. not do code review at all > In some cases we look look over the diffs as they come in or before an official release, but we have no standard practice/process for it. > 2. only do code review on major things that get their own branch, not > reviewing small changes to trunk > Richard's Golden Rule to the developers is, "don't break the trunk," and so far we've been relatively good about keeping the trunk working :). Small changes tend to happen directly in trunk, but people sometimes stuff them into a branch and ask for another set of eyes before they merge (kind of a "code review honor system"). Yes, it "would be cool" to have some sort of code review feature built in (i like Atlassian Fisheye, myself), but no, we neither have one nor do we have a process which could be used as the basis for one developing. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
