I have just discovered fossil and I am kind of blown away by all it can do! I love how simple this is to install and administrate for small projects. The other competing products like GitLab or Phabricator, etc, are orders of magnitude too complicated for small projects that just need some src control, wiki docs, issue tracking and maybe a bit of branch-management workflow adherence. Huge SQLite fan here, I’m definitely going to give this a go!
I have read the ebook and perused through the email archives a bit, I have a few questions before i go much further. 1 - I notice tickets numbers are not automatically cross linked with commits. The book mentions adding the [nnnnnnnnn] strings in both directions so that at least through the webui you can at least hyper link back and forth..presuming there is only one commit for a given ticket. if there is more then one commit, it could get complicated. This definitely needs to be automated with wrapper scripts to avoid user error. Do any of you have any wrapper script examples or work flow suggestions to make this a little more automatic and reliable? Basically I would like a workflow where developer Joe gets a ticket. He works on the ticket for a while, doing whatever commits he feels he needs to do, and finally when its done, closes the ticket with references to the commit(s) in the ticket. But in the future I want to easily be able to call up a ticket, via the web or not, and see a list of files that were changed and diffs of what was actually changed related to that ticket…ideally consolidating all the commits into one reviewable diff for the whole ticket, if that makes sense. Any workflow or scripting suggestions will be appreciated. Has anyone considered modifying the actual ticket tables to hold references to commit(s) directly rather then as text strings in the description? Something that can’t be easily changed through user error? What is the best way people are automating or streamlining this capability to make it more automatic, consistent and enforced? 2 - I notice fossil doesn’t endorse or seem to directly support the squashing of commits. In git I can work on a bunch of stuff, commit it 10 times or whatever, and then before doing a pull request to push it back to the server repo, I can consolidate those commits to a single commit so that what ends up on the server repo will be one single commit as a single ‘feature” or “idea”. That one single commit can then be referenced by a ticket if it exists (see question #1). Is there a way to squash commits with fossil or perhaps other workflows with branches or tags that can enforce this kind of end result where the server mainline trunk will have a single commit per ticket, regardless of whatever mess of multiple commits the developer did in their local repo? Or at least a way for a ticket to easily see the files changed and the diff of those changes for the ticket as a whole…even if that is over multiple commits? Prefer to see multi-commits squashed to single commits during push or merge to the server mainline. 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. they need to be able to pull from the trunk (or not) as they work to keep their workspace up to date (or not) and work on their feature, whether its a big feature or a single line bug fix, but not able to push it back to mainline until I say so via gatekeeper code review, and confirmation that they have updated their workspace with all the latest changes from mainline and built with it before being able to merge back to mainline also. So being able to both enforce this and also facilitate easy code review of the requested change…is what I would like to automate with wrapper scripts for fossil. It needs to be consistent and easy and very straightforward for code reviewing as well, if there are 10 commits they did, the code reviewer shouldn’t have to worry about any of that. Just take a ticket id, see a list of files changed and the overall diff of each file that is expected to be merged back to mainline in some fashion, and associate it all with a ticket id, and approve the ticket and the dev can finally commit it back. In the past on other systems I have used “feature-branches” where developers create a feature branch for each change or at least reuse a private branch they have..and then after they do all the work they are going to do, finally request code review and maybe their commit(s) will be merged back to the mainline. Nobody works off the mainline, they always work off a branch and after code review can merge their branch back to the mainline…or rather merge the specific commits from their branch, into the mainline… I don’t know if this is making sense, but any insights, wrapper script ideas or other ideas about how to setup fossil in terms of auto-sync or not, and branch/merge/tag methodologies to accomplish something like this would be appreciated. I prefer to gate keep changes to the mainline tightly rather then allowing devs to push back whatever they want, whenever they want..to the mainline. that includes even for only 2-3 devs. thanks in advance _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
