On Sat, Mar 14, 2015 at 12:33 PM, David Mason <[email protected]> wrote:
> 1) Fossil's ticket handling is not best-in-class. What are the key > features that would make it at least competitive? What features does > it have that are already better than most? (I've never used tickets, > although the integrated ticket system was one of my reasons for moving > from Hg to Fossil.) > I will point out that Fossil's ticket subsystem is very customizable. Granted, that requires messing with TH1 code and HTML, but I don't know how much harder that is then customizing Trac or Redmine ticket subsystems. 3 or 4 years ago I posted what I did, but we no longer use that and my copy is is on an USB stick in a box that's hard to get to. But, I was able to implement our issue process flow in TH1. > 2) The wiki is not best-in-class. What are the key features it needs? > (Merging of changes is certainly one that I see. If multiple people > are working on the train to/from work, you don't want "last committer > wins" in your wiki. This is the point of DVCSs.) > Yes, that and making sure the P card in wiki artifacts has the correct parent in it. (Last time I checked, the Edit Wiki Page page did not have a (hidden) field to identify the parent artifact.)
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
