On Apr 22, 2016, at 5:07 PM, Richard Hipp <d...@sqlite.org> wrote: > 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!) >
Right well I’m just trying to figure out a way to automate thing so the dev never has to worry about copy and pasting any kind of ticket or checkin numbers from one place to another. I want it to just happen automatically through wrapper scripts and workflow control. This is also a bit confusing to me about the implication of many commits corresponding to a single ticket. I will play around with it some more until I grok it a little more. Perhaps I just need to learn which is the right web screen to look at… Ideally, as a gatekeeper, having to look through a list of commits when reviewing the changes for a ticket…its difficult. What’s better is to see a list of files being effected in the ticket (across all the commits it has) and the macro diff for each of those files..for the whole ticket..not just one commit at a time. So that is easy in the git world if the dev is told to squash their commits before a pull request. In Fossil we can’t squash, but we need to make it easy for the gatekeeper to see a squashed view of the requested changes for the ticket across multiple commits. Also in the future it would be good to tag the final commit of the ticket…so that anyone trying to look at stuff later will be able to see the interim commits are half-fixes for the ticket. The full ticket is only represented by the range of version nodes..with the last one being the one that matters the most.. > > 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. > In the past on other systems I’ve used like clear case, we always did work on another branch and the merge did squash the commits arriving on the dest branch in the process. Im not sure if you’re saying a merge here would merge multiple commits from one branch into a single commit on the dest branch? You said it preserves the history, but that would infer that the merge would not squash the commits in the process. > 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. > Ah…I will try this out.. I didn’t know you could click between two nodes and see the diff. I will try that…that might provide enough. Even more ideally I’d like to write a wrapper script that will figure out the diff and present diff or gdiff to the gatekeeper. Gatekeeper would see a list of files changing between the two more extreme nodes of the ticket…show the list of files and one at a time the diff. I guess this is doable with scripting... >> >> 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. > — I hear you. Just for the record I’m not a fan of git. I only mentioned it earlier for context. Most of my experience in the past has been as a dev using clear case, and highly scripted work flow to enforce things so that mistakes like that simply would not happen. for me that is preferable. The totally open ended approach of git (and perhaps fossil?) to allow people to just push and pull code all over everywhere and use their best judgement on merging stuff…there is some usefulness for that in the open source world of throwing code around a lot and trying lots of stuff, etc. But I also see that as branch merging kaos I would rather avoid. It has proven to be very popular our open source world with people able to toss code around in many different versions very easily..and perhaps so. In a situation where you want a little tighter control over the mainline..then I prefer a more rigid process that prevents that from happening to begin with. So if I were going to do anything with git, I would be trying to think of wrapper scripts and such to enforce similar constraints as to what we used to do back in the clear case days. Having the ability to squash commits or not…I hear you about wanting all the history always, that’s all fine and good, so long as tags or something similar is used to mark the important version nodes, so interim commits can be basically ignored later on. I think it should be attainable with fossil as well, its just a matter of using the write branching/tagging strategy and some clever scripts. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
