On Aug 3, 2016, at 7:48 PM, Jan Danielsson <jan.m.daniels...@gmail.com> wrote: > > And it gets really fun when people try > to be clever and have "funny" schemes like "the version converges > towards pi.”
It’s funny that you should mention that. On reading the announcement of the upcoming “pi” release of SQLite, I began having this amusing fantasy that someone would step up and begin offering a “no new features” version of SQLite, being 3.14 plus backported bug fixes only, asymptotically approaching the perfect SQLite. :) (Not that I’m against features, but I’m certain that there’s a nontrivial segment of the user base that would adopt such a fork.) > I can't answer your question without dedicating some time to it, and > I can't say that I would come up with an good manifest.tags-solution for > your specific case. Understand, I’m not asking you to do that so that you do my work for me. I don’t have much incentive to replace my existing working system this late in the game. I offered it as a useful exercise which might help you to knock some sharp corners off of your current design. I’ve observed that the first release of a feature is usually good for only one use case. It isn’t until you’ve tried to reuse that code in three completely unrelated contexts that the feature becomes sufficiently generalized that you can expect it to drop into more new situations without needing further changes. > That's one of the things I realized after a few > failures -- whatever scheme you come up with, it has its limitations. That’s part of what I mean, but I’m not just talking about simple limitations. The second and third applications of the code in new contexts often stretch the original design in ways you had no reason to even consider when initially designing the feature. This is why too much up-front design is a problem. It isn’t until you begin trying to apply the design to the real world that you can see all of your initial design’s weaknesses. > What we > found though was that everyone gets it 100% correct the first few times, > but after a while people tend to get into the "This part is easy, I know > this by heart"-mindset, and they check the "I did stage x, y, z" boxes > without actually doing all the verifications. > > So there are different ways to tackle such problems. Management say > it's done by adjusting processes and procedures. I'm tend to take a > "develop better tools" approach. I agree. If it is at all possible to make the tooling smart enough to understand the rules, do it that way. But equally, if it’s just as difficult to give the tools enough info that they can work out the correct answer as to do the manual process, you might as well continue to do it manually. This is why it is valuable to have version numbers in as few places as possible and to create tools (or use existing ones) that can transfer that version into all the other places it needs to appear. It creates fewer things for the human to worry about, and the process for scattering that version around is the same, every time. > People may think I'm being oddly picky about version numbers, but > there's context to it. Some of these systems are developed under > contracts which state that "if there's a flaw in the traceability chain, > we can demand money back”. Never mind drastic scenarios like that. Sloppy version numbering can cost an hour or so per incident in downstream costs. If your process takes only a few hours to set up and hardly any maintenance beyond that, as ours does, it’s probably paying for itself just in decreased debugging time. >>> The build system iterates through each line of manifest.tags >> >> I don’t see what your build system is getting from manifest.tags that it >> couldn’t already get from the T card in the current manifest file. > > Hmm.. > > $ fossil status > repository: /Volumes/ramdisk/mytest/../mytest.fossil > local-root: /Volumes/ramdisk/mytest/ > config-db: /Users/jan/.fossil > checkout: 504d0bfcda9be2e7b365be2331468b1363a3f719 2016-08-03 > 14:21:07 UTC > parent: 569e2a7bb99c919dad0bbb9d6158a2b31aaf4850 2016-08-03 > 14:17:57 UTC > tags: trunk, mytest-0.0.1 > comment: Added test.c (user: jan) > > $ grep ^T manifest > $ grep mytest manifest > $ cat manifest.tags > branch=trunk > trunk > mytest-0.0.1 > > Is there supposed to be a T-entry in the manifest file? *confused* T is for tags, not branches. Or, to be more precise here, since it matters, T is for non-propagating tags, rather than propagating tags. Thus if you say “f up mytest-0.0.1”, a T card should appear in the regular manifest file, while it won’t if you’re on the mytest-0.0.1 branch but a few checkins down from the tagged checkin. I think Fossil’s existing behavior is more useful, since the checkin immediately following the one tagged mytest-0.0.1 begins a new version, so you are no longer on version 0.0.1. Given the behavior you show, I wonder if your feature should create manifest.branches, not manifest.tags. >> Does your build system use this project name to detect which binary >> package(s) to build? > > Sorry, I don't understand the question; interpreting from context > I'm going to take a stab at answering. I apologize if I completely > misunderstood (it's well past bed-time here..). > > The build server gets a request to build a specific version. I was operating under the assumption that you had some kind of Continuous Integration system going, so that every checkin could trigger a build, so the CI system would need a way to figure out which binary packages to build: release client, release server, experimental development builds of both, etc. That is, if the tip of the repo is tagged svr-1.2.3, a CI system could be taught that it needs to build the server package only. The mere act of tagging a checkin kicks off the binary release package creation. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
