Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 8/6/2014 21:00, Andy Bradford wrote: Thus said B Harder on Wed, 06 Aug 2014 10:41:47 -0700: Do we have fine-grained control over pulling only specifically rooted branches? No, but you can certainly clone the developers clone and inspect his changes before pulling into your clone (or pushing directly to main repository). This is beginning to sound like my outside contributions feature request, a.k.a. uber-patch: http://goo.gl/4lLAuY My idea was to allow untrusted outsiders to be able to send a richer patch file than patch(1) allows, but it could also be used for this use case where we want semi-trusted developers to make commits to the repository which are later merged in. I still think drawing that line inside the development team is a bad idea for development cycle time reasons, though. Trust, but verify. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Thus said Warren Young on Thu, 07 Aug 2014 13:50:18 -0600: This is beginning to sound like my outside contributions feature request, a.k.a. uber-patch: http://goo.gl/4lLAuY Yes, it is, and I had that same thought as I typed it, but, it can already be accomplished with Fossil clone to some extent. :-) Of course for a big repository this won't work very well (unless one doesn't discard the developers clone and just does a pull when needed). But clearly not meant to replace your ``uber-patch'' idea (which just needs someone to find some time to make it). Thanks, Andy -- TAI64 timestamp: 400053e3f79f ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Thu, Aug 7, 2014 at 3:50 PM, Warren Young war...@etr-usa.com wrote: This is beginning to sound like my outside contributions feature request, a.k.a. uber-patch: http://goo.gl/4lLAuY My idea was to allow untrusted outsiders to be able to send a richer patch file than patch(1) allows, but it could also be used for this use case where we want semi-trusted developers to make commits to the repository which are later merged in. I still think drawing that line inside the development team is a bad idea for development cycle time reasons, though. Trust, but verify. Many corporate software teams use high ceremony VCSs like Synergy CM and Perforce because such systems can impose role based limitations. While this is usually driven by management, software developers who have worked with such systems often end up preferring having those limitations imposed by the VCS. My team does not. Sometimes we do forget to create a fix/feature branch, but commits can be moved after-the-fact. Most times we catch this immediately. Very, very rarely more than a day. And certainly well before a release. While I can think of an enhancement to the private branch handling that help prevent accidental pushes to trunk, or other designated branches, I don't see the benefit outweighing the costs. An Enterprise Fossil could be created either as a wrapping around Fossil or as a libfossil based application. My team doesn't need that, so I don't expect I would do that, but I am willing to share my thoughts with anyone who might want to implement that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 5-8-2014 23:16, Warren Young wrote: On 7/26/2014 08:53, Eric Rubin-Smith wrote: * Code review! Fossil already provides all the code review I think any nimble team should need: RSS. 1. Set Fossil up as a server. [1] It's not even necessary to set Fossil up as a server; you can also run `fossil rss` (with relevant options) as a cron job (or a Scheduled Task :-P) and redirect the output to a file, or FTP it to some server. Your RSS reader can then read that file. [2] A quick glance at src/rss.c in the Fossil sources says this is a one-off oddball feature. It doesn't look like there are any other Fossil UI pages you can monitor via RSS. It would be handy to monitor wiki pages and tickets via RSS, for example. Tickets and wiki are supported, but via the same rss page, not by adding .rss to their respective pages: timeline.rss?y=ttkt=tkt_uuid timeline.rss?y=wwiki=name AFAIK, the page's parameters are identical to the CLI command's options: http://fossil-scm.org/fossil/help/rss HTH, -- Martijn Coppoolse ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Tue, Aug 5, 2014 at 11:16 PM, Warren Young war...@etr-usa.com wrote: I'm not aware of any evidence that an approve-up-front development process gives better end results than a fix-in-place process. Just to play Devil's Advocate (and not intended to diminish your thoughtful and detailed post): i'm fairly certain that space-going software pretty much has to be developed via up-front approval processes, as reactive methodologies are too late when you've got an 8-minute speed-of-light delay and you need to fix a Metric/English conversion bug which is about to cause your Mars Lander to smack into the planet's surface. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Wed, Aug 6, 2014 at 6:36 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Aug 5, 2014 at 11:16 PM, Warren Young war...@etr-usa.com wrote: I'm not aware of any evidence that an approve-up-front development process gives better end results than a fix-in-place process. Just to play Devil's Advocate (and not intended to diminish your thoughtful and detailed post): i'm fairly certain that space-going software pretty much has to be developed via up-front approval processes, as reactive methodologies are too late when you've got an 8-minute speed-of-light delay and you need to fix a Metric/English conversion bug which is about to cause your Mars Lander to smack into the planet's surface. That's really an approve-before-deploy situation. While it can be (and has been) useful to include a software debugged in the spacecraft's computers, you still need ground-based duplicates for testing and debugging before you upload the code. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Tue, Aug 5, 2014 at 5:16 PM, Warren Young war...@etr-usa.com wrote: On 7/26/2014 08:53, Eric Rubin-Smith wrote: * Code review! Your talk of state machines suggests that you're instead envisioning a system where you can't get a checkin into the trunk -- maybe not even into a development branch -- without someone else signing off on it. If so, this is a terrible idea. It is possible, with no new features in Fossil, to prevent accidental commits to trunk. Since each developer will be working with a clone of the main repository, you simply do not give your developers commit permission to the main repository. When a developer has a change ready for review, she/he sends a review request with the name of the branch (on his repo). the the integrator (or an automated process) would then pull that branch so the reviewers can review if. Once approved, the integrator (possibly one of the reviewers) would merge the branch in to the trunk. FWIW, I think, behinds the scenes, you would find that VCSs that support approve-before-commit actually accept the (proposed) commit into an automatically created private branch, then move the commit to the target branch (or trunk) upon approval. While this could be implemented either in Fossil or in a wrapper for Fossil, the convenience it might provide really only manifests with very simple changes/fixes. But, when you need to iterate the process, you either end up with a new, single commit branch for each iteration, or you have to pull aside the curtain to find the branch's id and make further commits to that branch. Also, even if most of your changes/fixes are simple enough for a single commit each, having a real branch to work with makes it easier to manage integration because you can resolve most, if not all, of the integration issues in the branch before merging it into the target branch (or trunk). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 8/6/2014 01:49, Martijn Coppoolse wrote: On 5-8-2014 23:16, Warren Young wrote: 1. Set Fossil up as a server. [1] It's not even necessary to set Fossil up as a server; you can also run `fossil rss` Nice. Thanks for the tip. [2] A quick glance at src/rss.c in the Fossil sources says this is a one-off oddball feature. Tickets and wiki are supported, but via the same rss page, not by adding .rss to their respective pages: timeline.rss?y=ttkt=tkt_uuid timeline.rss?y=wwiki=name Good to know. It looks like we can monitor all checkins with a particular tag via RSS, too, which effectively gives the ability to watch a branch: timeline.rss?type=citag=v2 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 8/6/14, Ron W ronw.m...@gmail.com wrote: On Tue, Aug 5, 2014 at 5:16 PM, Warren Young war...@etr-usa.com wrote: On 7/26/2014 08:53, Eric Rubin-Smith wrote: * Code review! Your talk of state machines suggests that you're instead envisioning a system where you can't get a checkin into the trunk -- maybe not even into a development branch -- without someone else signing off on it. If so, this is a terrible idea. It is possible, with no new features in Fossil, to prevent accidental commits to trunk. Since each developer will be working with a clone of the main repository, you simply do not give your developers commit permission to the main repository. When a developer has a change ready for review, she/he sends a review request with the name of the branch (on his repo). the the integrator (or an automated process) would then pull that branch so the reviewers can review if. Do we have fine-grained control over pulling only specifically rooted branches ? Once approved, the integrator (possibly one of the reviewers) would merge the branch in to the trunk. FWIW, I think, behinds the scenes, you would find that VCSs that support approve-before-commit actually accept the (proposed) commit into an automatically created private branch, then move the commit to the target branch (or trunk) upon approval. While this could be implemented either in Fossil or in a wrapper for Fossil, the convenience it might provide really only manifests with very simple changes/fixes. But, when you need to iterate the process, you either end up with a new, single commit branch for each iteration, or you have to pull aside the curtain to find the branch's id and make further commits to that branch. Also, even if most of your changes/fixes are simple enough for a single commit each, having a real branch to work with makes it easier to manage integration because you can resolve most, if not all, of the integration issues in the branch before merging it into the target branch (or trunk). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Thus said Ron W on Wed, 06 Aug 2014 13:14:13 -0400: When a developer has a change ready for review, she/he sends a review request with the name of the branch (on his repo). the the integrator (or an automated process) would then pull that branch so the reviewers can review if. Do you mean that the reviewer would clone the developers clone and review the changes there and then push to his own local clone or push directly to the main repo? Thanks, Andy -- TAI64 timestamp: 400053e29b76 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Thus said Warren Young on Wed, 06 Aug 2014 12:22:45 -0600: Out here in the normal software world, I think we are being presumptuous to use the word engineering. We usually cannot write an equation to prove our software correct. The earth trembles as Dijkstra rolls in his grave: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1209.html But your story about various features is certainly apropos. :-) Andy -- TAI64 timestamp: 400053e29dcf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 8/6/2014 15:27, Andy Bradford wrote: Thus said Warren Young on Wed, 06 Aug 2014 12:22:45 -0600: Out here in the normal software world, I think we are being presumptuous to use the word engineering. We usually cannot write an equation to prove our software correct. The earth trembles as Dijkstra rolls in his grave: Show me a mathematically-rigorous method for proving the correctness of any program involving indeterminacy, and we'll talk. That's pretty much every program of consequence. Any program that opens a TCP socket, shares a SQLite DB with another program, presents a GUI, or uses threads is probably undecidable in an a priori fashion, because you cannot usefully describe all of the input states. http://www.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1209.html I like my academic publication link better: http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf I don't recall if I found that one on my own or through the SQLite FAQ: https://www.sqlite.org/faq.html#q6 There have been heroic efforts to wall off indeterminacy, the most famous of which is probably Haskell and its I/O monad, but that only gets you so far. I read an article in CACM a month or so ago, where the guy was basically blasting all of the impure FP languages that are becoming popular, drawing attention away from the likes of Haskell. (F#/OCaml, Clojure, Scala, etc.) The author didn't name names, but you could feel his vibrating agitation as he described all the problems that crop up when you get away from mathematical purity. True enough. We agree on the scope of the problem; it's huge. The solution, however, is not to cut off all the impurity. That turns computers into glorified calculators, REPLs that can't communicate with the outside world except via the terminal interface. Such systems *can* be proven mathematically correct. The thing is, they're never going to push aside all of the impure things we actually do with computers. Another non-starter is to return computers to batch processing. My Pascal prof tried to teach us that all software could be described as input-process-output. If the input is a stack of cards in a known format, we can formally test whether the output is appropriate for the input. If we feed the same input back in again, we should get the same output. We see this testing methodology today as unit testing, where we try to turn each tiny piece of a large program into an i-p-o pipeline. But, a pile of formally correct i-p-o pipelines doesn't magically assemble into a formally correct aggregate program. And, not everything is testable in that way in the first place. Witness all the marginally useful GUI testing systems, for just one example. For another, network protocol fuzzers. I'll finish with my original premise: except in areas where software development is just a way of doing physics or pure mathematics of one sort or another, you probably are not doing engineering from the start. This is why I prefer the term software development. We may not know exactly where we are going or how to get there, but somehow we always recognize it when we arrive. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Thus said B Harder on Wed, 06 Aug 2014 10:41:47 -0700: Do we have fine-grained control over pulling only specifically rooted branches? No, but you can certainly clone the developers clone and inspect his changes before pulling into your clone (or pushing directly to main repository). Andy -- TAI64 timestamp: 400053e2ebf6 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Wed, Aug 6, 2014 at 7:42 PM, Warren Young war...@etr-usa.com wrote: I'll finish with my original premise: except in areas where software development is just a way of doing physics or pure mathematics of one sort or another, you probably are not doing engineering from the start. This is why I prefer the term software development. We may not know exactly where we are going or how to get there, but somehow we always recognize it when we arrive. Excellent points. I've been known to tell people I'm either a software engineer (and software developer isn't a bad substitute) or computer programmer depending on how important I want to seem at a particular point in time. :) That being said, I see the two differently. Perhaps software engineer is somewhat of a misnomer compared to more traditional engineering fields, but one could argue software architect is too. A computer programmer to me is someone who knows how to use particular tools / frameworks / libraries / etc to build a particular class of software. A software engineer is one who can successfully design data structures and algorithms to solve problems with whatever tools are available or necessary to complete the task. At my previous job I was the software development manager. I needed software developers to think through problems and solve them. Too many applicants were of the computer programmer variety (and subpar at that): great for when you needed someone to cobble together a web app using C# and ASP.NET. If you needed them to build anything outside that one zone, they were lost. The number of applicants that couldn't write a string reverse algorithm in pseudo code boggled my mind. The reason was clear: We were a startup company, and the founders weren't willing to pay for what they really needed, relying on luck to find good people willing to work for sub-market wages. We found some, but it was an exhausting process. -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 7/26/2014 08:53, Eric Rubin-Smith wrote: * Code review! Fossil already provides all the code review I think any nimble team should need: RSS. 1. Set Fossil up as a server. [1] 2. Go to the Timeline page, and add .rss to the end of the URL. [2] 3. Subscribe to that URL in your feed reader. 4. Whenever someone makes a change to that repo, your feed reader will take you to that checkin's entry in the UI [3] where you can find out more about it. If you're not already using an RSS reader for another purpose, this is a good reason to start. Make it part of your daily routine: walk in, touch base with colleagues, check email, look at the feeds, then get to work. [1] http://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki [2] A quick glance at src/rss.c in the Fossil sources says this is a one-off oddball feature. It doesn't look like there are any other Fossil UI pages you can monitor via RSS. It would be handy to monitor wiki pages and tickets via RSS, for example. [3] http://www.fossil-scm.org/index.html/doc/trunk/www/webui.wiki I also would like to have a story in case one day the team decides they want to have every line go through a review process. If you're talking about /post facto/ review, the above process suffices. You simply have to trust that someone, somewhere, looks through every checkin. This is the natural function of a lead developer, a project manager, a BDFL, or whatever you call it. All the other team members should also be looking at this RSS feed, if only to keep up on what's going on elsewhere in the code base. If you cannot trust the project's oversight role holder or your colleagues to do this, your team is in trouble from the start. Your talk of state machines suggests that you're instead envisioning a system where you can't get a checkin into the trunk -- maybe not even into a development branch -- without someone else signing off on it. If so, this is a terrible idea. The US military developed the concept of an OODA loop [4], a useful concept in any organization that must keep moving forward toward a goal. A lock-step checkin process adds delay between the trailing A of one OODA cycle and the O starting the next, slowing the whole process down. Studies show that breaking a person out of flow costs you about 20 minutes. [5] That means you're adding no less than 20 minutes to each OODA cycle if your team is moving smoothly toward its goal, and that's only if one person waits. (If your team is constantly interrupted and so never gets into a flow state, so that frequent checkin approvals are not a problem, your team is already hobbled. OODA loop optimization is the least effective thing you can do at that point. You need to get the hobbles off before you can hope to run.) Lock-step checkin and review processes go against the whole idea of a modern VCS. A VCS lets you test risky ideas on branches, [6] to roll back when experiments fail, [7] and to quickly locate the source of a problem when a bad checkin does go unnoticed for some time. [8] A fix in place development process allows faster OODA loops. Fossil's RSS timeline, wiki, and ticket systems helps avoid errors by improving communication among team members. Good communication and tracking are more worthwhile than any benefit you can get from BD development practices. No amount of individual skill and brilliance can remove a delay purposely added between the OODA cycles. Hire the very best people you can get then stick delays into their OODA cycles, and you've wasted your investment. Delay added after the A is just *added delay*. It's like running an airline by making each plane land in every state it flies over. [9] I'm not aware of any evidence that an approve-up-front development process gives better end results than a fix-in-place process. [4] https://en.wikipedia.org/wiki/OODA_loop [5] http://www.amazon.com/dp/0321934113/ [6] http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki [7] http://www.fossil-scm.org/index.html/help?cmd=update [8] http://www.fossil-scm.org/index.html/help?cmd=bisect [9] There are about 10 US states along the great circle route between San Francisco and New York. Consider an F-16 flying that route, stopping in each state it crosses, taking just 6 minutes to land, refuel, taxi back to the runway, and get going again. An F-16 can break Mach 2 at altitude, but let us say that the pilot elects to go no more than twice as fast as a passenger airliner (about Mach 1.5) and that the slower flight during takeoff and landing reduce the average speed to just Mach 1.0. Which is faster, the F-16 or a Boeing 757 doing a boring nonstop flight along the same route? Answer: They take about the same time, but the 757 flight costs a lot less and carries a lot more cargo and passengers. (Yes, I did the arithmetic.) The application of this parable to the question of lock-step approval vs
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Sat, Jul 26, 2014 at 10:04 PM, Eric Rubin-Smith eas@gmail.com wrote: Richard Hipp wrote: Fossil can give you the ticket data as SQL. I think that is probably about as portable as ticket data is going to get. +1 ... says the top SQL expert between here and the Romulan Neutral Zone. :-) But it's true though. Sure, a JSON representation of the same data would be more portable in some sense, but either way you have a standard representation of complex data with a plethora of tools to manage it. SQL is quite powerful; if the schema transformation required is very complex then SQL is the right tool for the task! Fossil *could* support export to JIRA+git in particular, for example, by providing a tool that (a) exports to JIRA's supported JSON import format, (b) collects the mapping from the fossil ticket IDs to the JIRA ticket IDs, then (c) does a git export but massages the check-in comments according to the data collected in (b). My approach to this sort of task is to write a small Python program to extract SQL data in a dead-trivial JSON encoding (an array for every row, with each column mapped to an element of that array), ETL (extract-transform-load) either the SQL data (i.e., with complex queries), the JSON output (with jq), or a combination, to match the desired schema. Typically I do JOINs and such in SQL as that will run much faster in the RDBMS (since it has an optimize) than I could code it myself. My favorite tool for ETL (extract-transform-load) at the JSON level is jq (https://stedolan.github.io/jq). Full disclosure: I maintain jq, so this is shameless self-promotion on my part. SQL is declarative, jq is functional. There's a pattern there :) Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Mon, Jul 28, 2014 at 8:13 PM, Nico Williams n...@cryptonector.com
wrote:
Sure, a JSON representation of the same data would be more portable in
some sense, but either way you have a standard representation of
ahem...
[stephan@host:~/cvs/fossil/cwal/s2]$ f json timeline checkin -n 1 -I 2
{
fossil:d7d265502a660e1dc5ef41fbe6978f32f507a00e,
timestamp:1406571857,
command:timeline/checkin,
procTimeUs:5331,
procTimeMs:5,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:df7edd343223bfc799a2d84b3029aea6a3cf2e3f,
isLeaf:true,
timestamp:1406562830,
user:stephan,
comment:s2sh now prefers getenv(\S2SH_INIT_SCRIPT\) over
$0.s2, but will use the latter if the former is not set.,
parents:[d650f43d56510f086ff2e7159b6b3450e9c0df6f],
tags:[trunk]
}]
}
}
resp.
/json/timeline/checkin?limit=1indent=2
with the libfossil script bindings, you've got complete db access and
conversion from that to JSON is built in to the language:
[stephan@host:~/cvs/fossil/libfossil/s2]$ ./s2sh -v
verbose: Auto-loading script [./s2sh.s2].
s2 interactive shell.
...
s2 var f =Fossil.Context.new();
result: Context@0x904a50[scope=#1@0x7fff77f593c8 ref#=1] ==
Context@0x904a50
s2 f.openCheckout()
result: Context@0x904a50[scope=#1@0x7fff77f593c8 ref#=1] ==
Context@0x904a50
s2 f.db.selectObject(select * from event order by mtime DESC limit 1)
result: object@0x937d50[scope=#1@0x7fff77f593c8 ref#=0] == {
omtime: 2456867.202998,
brief: null,
comment: s2: minor tweaks to the CGI bits, added
Fossil.file.pushd/popd() to s2sh.s2. Fixed (with valgrinds help) stale
native pointers to fsl_db instances left around by a missing piece in the
Fossil.Context cleanup.,
ecomment: null,
user: stephan,
euser: null,
bgcolor: null,
uid: null,
tagid: null,
objid: 5919,
mtime: 2456867.202998,
type: ci
}
(lol... that particular commit fixed a nasty bug in that very db binding.)
SQL is declarative, jq is functional. There's a pattern there :)
s2 f.db.each({sql:'select uid, login from user',
callback:proc(){1===rowNumber print(columnNames); print(this)}})
[uid, login]
[2, anonymous]
[9, apotheon]
[7, bch]
[4, developer]
[6, drh]
[8, jan.nijtmans]
[3, nobody]
[5, reader]
[1, stephan]
result: Db@0x9273a0[scope=#1@0x7fff77f593c8 ref#=1] == Db@0x9273a0
:)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On 27 July 2014 11:04, Eric Rubin-Smith eas@gmail.com wrote: Fossil *could* support export to JIRA+git in particular, for example, by providing a tool that (a) exports to JIRA's supported JSON import format, (b) collects the mapping from the fossil ticket IDs to the JIRA ticket IDs, then (c) does a git export but massages the check-in comments according to the data collected in (b). I'd find a tool like that really useful. I'd find the reverse even more useful. I look forward to your F/OSSed implementation! More seriously, you're comparing a small project like Fossil's with the capabilities of behemoths like Microsoft. Microsoft can throw as many code monkeys at something as they'd like, hence the wide variety of exporting formats (of wildly varying stability and utility) in Microsoft Office, et al. In a small F/OSS project it's going to be more tools created by people who scratched an itch and shared their ointment. (OK, maybe I stretched that analogy a bit far.) I don't think you're going to find the tool you're looking for. What you might find useful, however, is Marc Simpson's fsl wrapper which will allow you to almost seamlessly integrate whatever tools you do come up with into Fossil's command line and workflow: http://fossil.0branch.com/fsl. Be sure to check out the cookbook for ideas of how to accomplish things as well: http://fossil.0branch.com/fsl/wiki?name=Cookbook. -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
More seriously, you're comparing a small project like Fossil's with the capabilities of behemoths like Microsoft. No, I'm really not. drh was making a claim that users will ALWAYS have to convert between two database schemas when exporting tickets from one system to another. He was making a technical claim, and I was disagreeing with it by analogizing the situation to other situations in which export is useful and in which a product knows about the accepted import formats of other products. I could just as easily have said that there is this cool little gem of a DVCS called fossil. The devs know about Git of course so they wrote a Git-specific export tool. I don't need to know what fossil's schema is, nor the import format of git, to use the tool. I don't think you're going to find the tool you're looking for. Okay, thanks. Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Sat, Jul 26, 2014 at 10:53 AM, Eric Rubin-Smith eas@gmail.com wrote: By 'code review' here I mean a web-based tool that has a formalized state machine for (a) uploading code deltas (b) filing and fixing defects against the uploaded code and (c) having the right set of people sign off. Like Code Collaborator. I guess JIRA has an integrated tool that is free for small teams too. Whatever. It just needs to eventually support reviewing every line of code that gets written, in case we decide to go in that direction. I am familiar with with 2 code review tools that are web based. Reviewboard is pretty much exactly what you describe. It is written in Python and comes with a set of scripts for importing diffs from various VCSs. One of those scripts would need to be copied and modified to support Fossil. The other is Kiln (from Fog Creek). It is actually a front-end for Hg. I mention it because Fossil already provides some of the functionality Kiln adds to Hg. Kiln's code review capability requires that change sets be committed to branches. It displays diffs and accepts comments from reviewers. Fossil already can display diffs in a suitable form via its web UI. Review comments could be supported with Fossil tickets, using some combination of custom fields, TH1 and JavaScript. My team does use Fossil tickets for code reviews. We have not done what I just described above. We just append any review comments to the ticket requesting the review. This works for us. * Export of tickets. The only ticket export format my team uses, well, the Project Manager uses, is CSV to put the tickets into spreadsheets, since (a) that is what higher level managers want reports in. And (b) the PM finds it easier to use spreadsheets during meetings. * Code review! (3) Are there clever work-flows using native fossil features that more closely resemble proper code review tools than the sort of bad one that I sketched above? I don't know if what I described that my team does for code reviews meets your needs, but it works for us. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil vs git-based arrangements. code review and ticket export
I'm starting a company with some folks. Their notion of the default choice for SCM is git + JIRA for bug tracking + some other tool we'd pick for code review. This is probably quite common. Since the answers to my questions will probably be interesting to a relatively wide audience, I hope the forum will forgive the length of my post. By 'code review' here I mean a web-based tool that has a formalized state machine for (a) uploading code deltas (b) filing and fixing defects against the uploaded code and (c) having the right set of people sign off. Like Code Collaborator. I guess JIRA has an integrated tool that is free for small teams too. Whatever. It just needs to eventually support reviewing every line of code that gets written, in case we decide to go in that direction. I'm trying to convince my co-founders to use fossil. I won't address all of fossil's strengths, since you will all agree with me. I want you to give me some ammunition on the weaker points: * Export of tickets. If we want to move away from fossil to a git-based thing in the future, we can export the source version history, though that is not as trivial as the Fossil page on the matter makes it seem (see below). Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs right from the SQLite database, massage them, and import them into JIRA (or whatever tool). (In reality, it looks like JIRA supports JSON import, so I'd probably wind up writing code to read the SQLite database and emit JSON instead of CSV -- but whatever, similar idea.) I'm guessing this would be like a 1-day project for a relatively large set of tickets. Furthermore, I'd need to massage all of the check-in comments themselves in order to reference the new JIRA IDs for tickets rather than the Fossil IDs. Is there a better story than this? * Code review! DRH has said on this forum (and I'm paraphrasing here) that he prefers to review humans more than code. If he decides he trusts the human, then he mostly trusts the human's output. So he didn't really care to write a native tool for code review for Fossil. This is what I think I need the most help with. While I feel mostly the same as DRH on the matter, I also would like to have a story in case one day the team decides they want to have every line go through a review process. If I don't have a story up front for that then it will be a biasing factor against Fossil, since it will be more likely we'd need to go through a transition (one they would worry is onerous or error-prone) to some other SCM in the future. I've come up with some work-flows that sort of simulate code reviews right from within fossil. For example, you might make each of your check-ins on its own branch, and when that check-in is accepted it gets merged into the feature branch. The existence of a pending review is signaled by a naming convention on the branches; devs are trained to do an 'lsbranch | grep conventional name' every X days or whatever. Defects are filed by writing comments right into the code under a certain convention and checking in the commented code against the review branch. This still leaves a lot to be desired (e.g. it's very awkward at best for reviewers to write defects, assign severities to the defects and so on). My major questions here are: (1) I know the fossil devs had considered writing a native proper code review feature. Is that anywhere on the near-term road map? (2) Are there 3rd-party code review tools that (a) are good and (b) support fossil? (3) Are there clever work-flows using native fossil features that more closely resemble proper code review tools than the sort of bad one that I sketched above? Thanks! Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
On Sat, Jul 26, 2014 at 10:53 AM, Eric Rubin-Smith eas@gmail.com wrote: * Export of tickets. If we want to move away from fossil to a git-based thing in the future, we can export the source version history, though that is not as trivial as the Fossil page on the matter makes it seem (see below). Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs right from the SQLite database, massage them, and import them into JIRA (or whatever tool). (In reality, it looks like JIRA supports JSON import, so I'd probably wind up writing code to read the SQLite database and emit JSON instead of CSV -- but whatever, similar idea.) I'm guessing this would be like a 1-day project for a relatively large set of tickets. Furthermore, I'd need to massage all of the check-in comments themselves in order to reference the new JIRA IDs for tickets rather than the Fossil IDs. Is there a better story than this? Is there a better story for moving between any two bug tracking systems? Do there exist any two bug tracking systems in the world were you can move from one to the other without having to write some scripts to transform the data? Fossil can give you the ticket data as SQL. I think that is probably about as portable as ticket data is going to get. You can use the fossil sql command to run .dump to get the ticket content and then load that content into *any* SQL database (MySQL, PostgreSQL, Oracle, SQL Server - name your poison) You will then have to transform the schema into whatever your target system expects. But I think that is always going to be the case, no? * Code review! My major questions here are: (1) I know the fossil devs had considered writing a native proper code review feature. Is that anywhere on the near-term road map? We do low-ceremony code review on SQLite. Questionable changes go into a branch and then everybody beats on that branch to try to break it and/or find dodgy coding practices, until at some point (perhaps) we think it is ready to go on trunk, at which point it gets merged. There are no review forms to fill out and no records are kept, other than the merge history. For quicker changes, we run fossil diff --tk then use the SaveAs button on the GUI display to create a graphical diff file. We then send that graphical diff file to everybody on our private chatroom. Our homemade chat client recognizes the graphical diff files when they appear as an attachment in the dialog and gives us a button to click to bring up the GUI display. This make it easy for everybody to look over the diff and voice their opinions. Again, there are no forms to fill out and no records are kept, other than the chat logs. If you want more ceremony, you can certainly set up a system in Fossil where changes have to be tagged by the code reviewers, using a PGP-signed tag. That was my original concept for reviews, but not having a need for them, I never actually implemented it. We use more ceremony for testing. We have a (continuously evolving) checklist of tests that we have to work through for each release. See http://www.sqlite.org/checklists/ for a list of recent checklists. If you are a developer (and know the right passwords) you can click on these checklists to make changes, such as to record that a retest is running or to report that a test passed or failed. The checklist management software keeps track of all changes by timestamp, username, and IP address, and we save all that as part of the permanent record. It has been suggested that some kind of checklist facility like this be added to Fossil, but so far the checklist manager is a completely separate program. I find that using a checklist is better than completely automating the tests using something like Jenkins. It is good to keep a human in the loop. Often a test will pass but upon glancing at the output we realize something is wrong and needs to be fixed. Or maybe the test is just taking too long, suggesting a performance regression. Test automation is good. Many of the SQLite testing checklist items are highly automated tests that run literally for hours and perform tens of millions of individual test cases. But even with all this automation, it seems good to have actual humans monitoring the tests for unexpected behavior, and intervening as necessary, and the checklist facilitates that. The checklists also gives us an historical record of the testing, which becomes part of our process documentation. (2) Are there 3rd-party code review tools that (a) are good and (b) support fossil? (3) Are there clever work-flows using native fossil features that more closely resemble proper code review tools than the sort of bad one that I sketched above? Thanks! Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
I'm on mobile device - please excuse typos/brevity. I managed a team of about 10 local committers (in my office) and about 10 more remote (across the country). I had a FreeBSD production environment. I setup a FreeBSD dev/testing environment where everybody was isolated by jails, and had their own personal full stack to work with. I encouraged (demanded) frequent commits and good commit messages. Many, many commits per day from each developer as they worked through their code. Each developer has their own named branch (typically their username/personal name) that they owned and they were responsible for. Developers were encouraged to talk amongst themselves and merge each others code where they were working on systems that touched each other. Devs used tags to mark their code as good when appropriate. To maintain the stability of their own branches, they were encouraged to use excursion branches where appropriate to isolate tricky work-in-progress. I maintained trunk. I merged individual tagged dev branches at least once a day, and worked out conflicts and stability with responsible devs when necessary. On successful integration, passing tests, I would tag the trunk commit and cut a release. By *far* the biggest issue was where developers did not commit small enough code changes, or merge other appropriate work frequently enough to keep from diverging. Without fail, too long of a period between merging appropriate code *into* their code, or tagging their code for merging into trunk meant headaches. Ironically, the single biggest disaster came from a collection of developers who worked for the company financing the project. Despite daily protests to tag their code for integration, for weeks they refused. Their work was ultimately pretty much unintegratable, prompting the company to send out one of their PMs across the country to fix our code. It was a joke, but I digress. Commit early. Commit often. Use branches and tags. Empower developers. Recipe for success. On Jul 26, 2014 7:53 AM, Eric Rubin-Smith eas@gmail.com wrote: I'm starting a company with some folks. Their notion of the default choice for SCM is git + JIRA for bug tracking + some other tool we'd pick for code review. This is probably quite common. Since the answers to my questions will probably be interesting to a relatively wide audience, I hope the forum will forgive the length of my post. By 'code review' here I mean a web-based tool that has a formalized state machine for (a) uploading code deltas (b) filing and fixing defects against the uploaded code and (c) having the right set of people sign off. Like Code Collaborator. I guess JIRA has an integrated tool that is free for small teams too. Whatever. It just needs to eventually support reviewing every line of code that gets written, in case we decide to go in that direction. I'm trying to convince my co-founders to use fossil. I won't address all of fossil's strengths, since you will all agree with me. I want you to give me some ammunition on the weaker points: * Export of tickets. If we want to move away from fossil to a git-based thing in the future, we can export the source version history, though that is not as trivial as the Fossil page on the matter makes it seem (see below). Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs right from the SQLite database, massage them, and import them into JIRA (or whatever tool). (In reality, it looks like JIRA supports JSON import, so I'd probably wind up writing code to read the SQLite database and emit JSON instead of CSV -- but whatever, similar idea.) I'm guessing this would be like a 1-day project for a relatively large set of tickets. Furthermore, I'd need to massage all of the check-in comments themselves in order to reference the new JIRA IDs for tickets rather than the Fossil IDs. Is there a better story than this? * Code review! DRH has said on this forum (and I'm paraphrasing here) that he prefers to review humans more than code. If he decides he trusts the human, then he mostly trusts the human's output. So he didn't really care to write a native tool for code review for Fossil. This is what I think I need the most help with. While I feel mostly the same as DRH on the matter, I also would like to have a story in case one day the team decides they want to have every line go through a review process. If I don't have a story up front for that then it will be a biasing factor against Fossil, since it will be more likely we'd need to go through a transition (one they would worry is onerous or error-prone) to some other SCM in the future. I've come up with some work-flows that sort of simulate code reviews right from within fossil. For example, you might make each of your check-ins on its own branch, and when that check-in is accepted it gets merged into the feature branch. The existence of a pending review is signaled by a naming
Re: [fossil-users] fossil vs git-based arrangements. code review and ticket export
Richard Hipp wrote:
Is there a better story for moving between any two bug tracking
systems? Do there exist any two bug tracking systems in the world were
you can move from one to the other without having to write some scripts to
transform the data?
I can't tell whether you're asking rhetorically or in earnest. I
think rhetorically.
To which I reply that I make no claim that I am being fair. :-)
I just want to use fossil, and am looking for talking points to
convince others that the two points I initially enumerated are not
going to bite us.
Fossil can give you the ticket data as SQL. I think that is probably
about as portable as ticket data is going to get.
... says the top SQL expert between here and the Romulan Neutral Zone. :-)
From an information theoretic perspective, yes, all the data is
available. But that doesn't necessarily mean that it's easy for a poor
user, unfamiliar with both the Fossil database schema and the import
requirements of the target tool, to move the data between them.
You can use the fossil sql command to run .dump to get the ticket
content and then load that content into *any* SQL database (MySQL,
PostgreSQL, Oracle, SQL Server - name your poison) You will then have
to transform the schema into whatever your target system expects. But I
think that is always going to be the case, no?
I hope not. Microsoft Office products can import/export to/from
different formats. Lots of products know about the particular file
formats required by other specific products for the purposes of export.
Fossil *could* support export to JIRA+git in particular, for example, by
providing a tool that (a) exports to JIRA's supported JSON import format,
(b) collects the mapping from the fossil ticket IDs to the JIRA ticket
IDs, then (c) does a git export but massages the check-in comments
according to the data collected in (b).
Such a tool that is written and tested by the fossil devs would
obviously be preferable to whatever my sad little user-brain could
generate.
I make no claim that writing such a thing would be the best use of the
fossil devs' time -- again, just wondering what is out there.
We do low-ceremony code review on SQLite.
{snip}
We use more ceremony for testing.
{snip}
Thanks for sharing that, Richard.
--
Eric A. Rubin-Smith
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
