On 4/22/16, Steve Schow <st...@bstage.com> wrote: > > 1 - I notice tickets numbers are not automatically cross linked with > commits.
Links are automatic if you include the ticket number [nnnnnn] somewhere in the check-in comment. See the check-in at https://www.sqlite.org/src/timeline?c=ab9d279f40f81e5a for a recent example. Notice how that check-in includes the ticket number in the check-in comment, and the ticket number gets crossed out automatically when the ticket is closed. If you click on the link to the ticket number, it takes you straight to the ticket. Then on the ticket page, you can click on "Timeline" in the submenu bar to see https://www.sqlite.org/src/tkttimeline/7d7525cb01b68 all check-ins associated with that ticket. I suppose the ticket timeline could be cleaned up a little to give it all the same features as the regular timeline. I just seldom use the ticket timeline so it hasn't gotten as much attention. (An opportunity for you to contribute!) > > 2 - I notice fossil doesn’t endorse or seem to directly support the > squashing of commits. Right. The Fossil philosophy is different from Git. In Fossil, we work hard to preserve *all* history. You can correct thing (change the date or user or comment of a check-in or more a check-in to a different branch) but as in accounting, the original information is preserved as an audit trail. One pithy way of saying this is that Git tries to show what you should have done while Fossil tries to show what you actually did. The equivalent to squashing commits is to do the work on a branch, then merge the branch when it is done. The merge take the place of the squash, but preserves the history. If you want see a sequence of changes as a single diff, bring up a timeline that shows all the changes, click on the "node" of the origin, then click on the last check-in, then it will show you a diff between those two nodes. > > 3 - whether to use auto-sync or not. I would like to enforce a work flow > where devs are not able to move any changes back to the mainline until it > passes code review. The Fossil idea is that it provides mechanism, not policy. Policy issues such as "do not merge to trunk until approved" are enforced administratively. If is an accidental commit to trunk occurs, that commit can be moved back out into another branch when the mistake is discovered. If other commits have occurred on top of it, use the --backout option to back out the changes with yet another commit. https://www.sqlite.org/src/timeline?c=f632bba0 is an example of doing a commit incorrectly, then moving it off into a separate branch after the mistake is discovered. I originally (mistakenly) did the check-in on trunk. Then as a separate step I moved it into a branch, continued working on the feature, then eventually merged it back to trunk when it was ready. As project coordinator, I have been known to move other peoples branches off of trunk, when they check in things that I do not approve of. I try to keep that to a minimum, but the capability is there when you need it. https://www.sqlite.org/src/timeline?c=8f1f300c is an example of a check-in that was done against the wrong baseline, so it was moved into a new branch called "mistake". The corrected check-in ended up at https://www.sqlite.org/src/timeline?c=ea4de04d The point is that Fossil preserves *all* the history, even the mistakes. That is different from Git, which only tries to keep the important stuff. Which approach is better depends on what you are trying to do. Again: Git tries to show what you should have done, while Fossil tries to show what you actually did. -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
