On 04/08/16 20:44, Warren Young wrote: >> 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.
Sure, and it's appreciated. We've been using it for well over half a year, and have formed some build systems around how the feature works. And it would be naive to say I don't suffer from some tunnel-vision. That said, I explicitly didn't want to invent a complete new big system. I wanted to simply expose data which is already there in a simple-to-access manner and - importantly - allow the information to be accessed in tarballs and zipfiles. There's a lot more one could do if one were willing to do more plumbing, so to speak. [---] > Given the behavior you show, I wonder if your feature should create > manifest.branches, not manifest.tags. The way I view it is that it's used more like a label than anything, and in that sense "manifest.tags" is more fitting. On a more technical note: I use a query from "tags list" source to generate 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. No; some components have nightly builds, but there's still too much manual intervention required for some of the near-leaf-node builds. I have worked in places which use CruiseControl and Jenkins; and there's a long-term goal to use a CI-system here as well, but .. so many other things on the todo-list.. -- Kind Regards, Jan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
