From devi.webmaster at gmail.com Thu Apr 3 07:40:14 2008 From: devi.webmaster at gmail.com (Daniel Brumbaugh Keeney) Date: Thu, 3 Apr 2008 06:40:14 -0500 Subject: [Ditz-talk] rubyforge synchronization Message-ID: <3bceeb2d0804030440q60c89823jc801cec28f8feb2d@mail.gmail.com> Some time ago, I started work on the GTK desktop bug tracker, tentatively name Diptera. Perhaps I'll get around to integrating the gtk interface with ditz. I stopped working on Diptera after I failed to get soap4r working with rubyforge. (saywatang (from #ruby-lang) thinks there's a bug with rubyforge's soap interface[1], but I haven't seen anything to suggest my failure was related to anything but my own ineptitude.) In my mind, synchronization with rubyforge is the killer feature for a ruby desktop issue tracker. I mention this principally as a feature request, and would be elated to see this feature implemented. Daniel Brumbaugh Keeney [1] http://rubyforge.org/soap/ From nicolas.pouillard at gmail.com Thu Apr 3 08:15:29 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 3 Apr 2008 14:15:29 +0200 Subject: [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. Message-ID: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> --- lib/operator.rb | 67 +++++++++++++++++++++++++++++++++++++----------------- 1 files changed, 46 insertions(+), 21 deletions(-) diff --git a/lib/operator.rb b/lib/operator.rb index 000b477..3cd4e42 100644 --- a/lib/operator.rb +++ b/lib/operator.rb @@ -12,18 +12,39 @@ class Operator def method_to_op meth; meth.to_s.gsub("_", "-") end def op_to_method op; op.gsub("-", "_").intern end - def operation method, desc + def operation method, desc, *args_spec @operations ||= {} - @operations[method] = desc + @operations[method] = { :desc => desc, :args_spec => args_spec } end def operations @operations.map { |k, v| [method_to_op(k), v] }.sort_by { |k, v| k } end def has_operation? op; @operations.member? op_to_method(op) end + + def check_args method, *a + op = @operations[method] + args_spec = op[:args_spec] + a.shift # shift project if any + a.shift # shift config if any + count = a.size + for arg_spec in args_spec do + case arg_spec + when :issue, :release + die "wrong number of arguments, <#{arg_spec}> expected" unless a.shift + when :maybe_release + a.shift + end + end + die "two many arguments (#{count} for #{args_spec.size})" unless a.empty? + end end - def do op, *a; send self.class.op_to_method(op), *a end + def do op, *a + meth = self.class.op_to_method(op) + self.class.check_args meth, *a + send meth, *a + end %w(operations has_operation?).each do |m| define_method(m) { |*a| self.class.send m, *a } end @@ -39,8 +60,12 @@ class Operator Registered commands: EOS ops = self.class.operations - len = ops.map { |name, desc| name.to_s.length }.max - ops.each { |name, desc| printf "%#{len}s: %s\n", name, desc } + len_name = ops.map { |name, op| name.to_s.length }.max + len_args = ops.map { |name, op| op[:args_spec].map { |a| a.to_s.length + 3 }.max || 0 }.max + ops.each do |name, op| + args = op[:args_spec].map { |x| " <#{x}>" }.join + printf "%#{len_name}s%-#{len_args}s: %s\n", name, args, op[:desc] + end puts end @@ -54,7 +79,7 @@ EOS puts "Added issue #{issue.name}." end - operation :drop, "Drop a bug/feature request" + operation :drop, "Drop a bug/feature request", :issue def drop project, config, issue_name issue = project.issue_for issue_name project.drop_issue issue @@ -77,7 +102,7 @@ EOS puts "Added component #{component.name}." end - operation :add_reference, "Add a reference to an issue" + operation :add_reference, "Add a reference to an issue", :issue def add_reference project, config, issue_name issue = project.issue_for issue_name reference = ask "Reference" @@ -118,7 +143,7 @@ EOS ret << [nil, bugs, feats] end - operation :status, "Show project status" + operation :status, "Show project status", :maybe_release def status project, config, release=nil if project.releases.empty? puts "No releases." @@ -160,12 +185,12 @@ EOS end.join end - operation :todo, "Generate todo list" + operation :todo, "Generate todo list", :maybe_release def todo project, config, release=nil actually_do_todo project, config, release, false end - operation :todo_full, "Generate full todo list, including completed items" + operation :todo_full, "Generate full todo list, including completed items", :maybe_release def todo_full project, config, release=nil actually_do_todo project, config, release, true end @@ -184,7 +209,7 @@ EOS end end - operation :show, "Describe a single issue" + operation :show, "Describe a single issue", :issue def show project, config, name issue = project.issue_for name status = case issue.status @@ -215,7 +240,7 @@ EOS end.join("\n") end - operation :start, "Start work on an issue" + operation :start, "Start work on an issue", :issue def start project, config, name issue = project.issue_for name comment = ask_multiline "Comments" @@ -223,7 +248,7 @@ EOS puts "Recorded start of work for #{issue.name}." end - operation :stop, "Stop work on an issue" + operation :stop, "Stop work on an issue", :issue def stop project, config, name issue = project.issue_for name comment = ask_multiline "Comments" @@ -231,7 +256,7 @@ EOS puts "Recorded work stop for #{issue.name}." end - operation :close, "Close an issue" + operation :close, "Close an issue", :issue def close project, config, name issue = project.issue_for name puts "Closing issue #{issue.name}: #{issue.title}." @@ -241,7 +266,7 @@ EOS puts "Closed issue #{issue.name} with disposition #{issue.disposition_string}." end - operation :assign, "Assign an issue to a release" + operation :assign, "Assign an issue to a release", :issue def assign project, config, issue_name issue = project.issue_for issue_name puts "Issue #{issue.name} currently " + if issue.release @@ -255,7 +280,7 @@ EOS puts "Assigned #{issue.name} to #{release.name}" end - operation :unassign, "Unassign an issue from any releases" + operation :unassign, "Unassign an issue from any releases", :issue def unassign project, config, issue_name issue = project.issue_for issue_name comment = ask_multiline "Comments" @@ -263,7 +288,7 @@ EOS puts "Unassigned #{issue.name}." end - operation :comment, "Comment on an issue" + operation :comment, "Comment on an issue", :issue def comment project, config, issue_name issue = project.issue_for issue_name comment = ask_multiline "Comments" @@ -279,7 +304,7 @@ EOS end end - operation :release, "Release a release" + operation :release, "Release a release", :release def release project, config, release_name release = project.release_for release_name comment = ask_multiline "Comments" @@ -287,7 +312,7 @@ EOS puts "Release #{release.name} released!" end - operation :changelog, "Generate a changelog for a release" + operation :changelog, "Generate a changelog for a release", :release def changelog project, config, relnames parse_releases_arg(project, relnames).each do |r, bugs, feats| puts "== #{r.name} / #{r.release_time.pretty_date}" if r.released? @@ -366,14 +391,14 @@ EOS ## a no-op end - operation :grep, "Show issues matching a string or regular expression" + operation :grep, "Show issues matching a string or regular expression", :issue def grep project, config, match re = /#{match}/ issues = project.issues.select { |i| i.title =~ re || i.desc =~ re } print_todo issues end - operation :edit, "Edit an issue" + operation :edit, "Edit an issue", :issue def edit project, config, issue_name issue = project.issue_for issue_name data = { :title => issue.title, :description => issue.desc, -- 1.5.3.1.109.gacd69 From why at whytheluckystiff.net Thu Apr 3 11:53:07 2008 From: why at whytheluckystiff.net (_why) Date: Thu, 3 Apr 2008 09:53:07 -0600 Subject: [Ditz-talk] something like a ticket inbox Message-ID: <20080403155306.GB2553@beekeeper.hobix.com> Hey, everybody. I am finding ditz to be quite sensational. Now, clearly, ditz is very friendly to the hackers down underground. I am trying to cook up a strategy to offer users an interface to submit tickets and comment on tickets. I know that probably doesn't fit very well into this approach, but I've been wondering. Let's say I have a web interface that has a clone of the repository that is kept fresh by cron. And largely the interface is read-only. Except users can add new tickets and new comments. I don't really want the web interface to alter the bugs.yaml, in case there is a conflict. I suppose you could look at bugs.yaml as an mbox file, monolithic and quite a spectacle. What if there was an alternate Maildir-style approach? You commit new bugs and comments in a directory and after you "read" them through ditz, it merges them into the bugs.yaml. shoes.git/ bugs.yaml bugs/ ticket-1.yaml ticket-2.yaml comment-1.yaml Perhaps using a unique ID for each ticket could prevent conflict. Or maybe a complete Maildir-style approach could be used? _why From nicolas.pouillard at gmail.com Thu Apr 3 12:42:33 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 03 Apr 2008 18:42:33 +0200 Subject: [Ditz-talk] something like a ticket inbox In-Reply-To: <20080403155306.GB2553@beekeeper.hobix.com> References: <20080403155306.GB2553@beekeeper.hobix.com> Message-ID: <1207240543-sup-7002@port-ext16.ensta.fr> Excerpts from _why's message of Thu Apr 03 17:53:07 +0200 2008: > Hey, everybody. I am finding ditz to be quite sensational. I also find it a great potential! > Now, clearly, ditz is very friendly to the hackers down underground. > I am trying to cook up a strategy to offer users an interface to > submit tickets and comment on tickets. I know that probably doesn't > fit very well into this approach, but I've been wondering. I think that a great email integration would make sense. One could have some hooks in sup to add an issue from an email directly for instance. > Let's say I have a web interface that has a clone of the repository > that is kept fresh by cron. And largely the interface is read-only. > Except users can add new tickets and new comments. I don't really > want the web interface to alter the bugs.yaml, in case there is a > conflict. I suppose you could look at bugs.yaml as an mbox file, > monolithic and quite a spectacle. > > What if there was an alternate Maildir-style approach? You commit > new bugs and comments in a directory and after you "read" them > through ditz, it merges them into the bugs.yaml. > > shoes.git/ > bugs.yaml > bugs/ > ticket-1.yaml > ticket-2.yaml > comment-1.yaml > > Perhaps using a unique ID for each ticket could prevent conflict. > Or maybe a complete Maildir-style approach could be used? I would also love a Maildir-style approach, by using unique ids as filenames in the bugs/ directory one could therefor avoid a large class of conflicts in our favorites DSCMs. However I not sure that having comments/discussion in the same structure is a good idea, perhaps real mbox/Maildir could be used to store these comments? Perhaps having some "X-Ditz-Issue-ID: ..." in email headers would keep things properly bound. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080403/0ad132e6/attachment.bin From proppy at aminche.com Fri Apr 4 21:24:27 2008 From: proppy at aminche.com (Johan Euphrosine) Date: Sat, 5 Apr 2008 03:24:27 +0200 Subject: [Ditz-talk] something like a ticket inbox Message-ID: <730b2b9d0804041824s570a9187oc29813b03fc2ae33@mail.gmail.com> > I think that a great email integration would make sense. One could have some > hooks in sup to add an issue from an email directly for instance. Do you mean by "great email integration" that new or fixed issues could be sent by mail, by git-email'ing (or hg patchbomb'ing) patches to the yaml file ? That would be super awesome usecase since one would be able to ACK a bug, just by applying the attached patch to his repo. ++Agree that having issue in separate file with unique id (as you both suggested) would avoid/reduce conflicts. (sorry if I broke the thread, just joined the list and don't have the backlog in my mbox) -- bou ^ From nicolas.pouillard at gmail.com Sat Apr 5 05:52:50 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sat, 05 Apr 2008 11:52:50 +0200 Subject: [Ditz-talk] something like a ticket inbox In-Reply-To: <730b2b9d0804041824s570a9187oc29813b03fc2ae33@mail.gmail.com> References: <730b2b9d0804041824s570a9187oc29813b03fc2ae33@mail.gmail.com> Message-ID: <1207388499-sup-8613@ausone.local> Excerpts from Johan Euphrosine's message of Sat Apr 05 03:24:27 +0200 2008: > > I think that a great email integration would make sense. One could have some > > hooks in sup to add an issue from an email directly for instance. > > Do you mean by "great email integration" that new or fixed issues > could be sent by mail, by git-email'ing (or hg patchbomb'ing) patches > to the yaml file ? This kind of email integration comes for free due DSCMs emailing feature. > That would be super awesome usecase since one would be able to ACK a > bug, just by applying the attached patch to his repo. Right, but forcing bug reporters to diving into the project and then use ditz and then send a patch seems a lot more complicated to normal users. I thought that when your receive a mail from a user about an bug/request, you could have a custom command right in your mailer that will perform a "ditz add", the title could the mail subject (default), the component could be guessed from the mail body too. Finally the the mail-id is retained, for further changes. For instance when you've fixed the bug, you could ditz could auto-email a response to the thread. And perhaps more... > ++Agree that having issue in separate file with unique id (as you both > suggested) would avoid/reduce conflicts. > > (sorry if I broke the thread, just joined the list and don't have the > backlog in my mbox) Best regards, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080405/05b6ab5c/attachment.bin From yrashk at gmail.com Sat Apr 5 14:06:03 2008 From: yrashk at gmail.com (Yurii Rashkovskii) Date: Sat, 5 Apr 2008 21:06:03 +0300 Subject: [Ditz-talk] Merging issues additions? Message-ID: <96EA2740-6C34-48F8-BDE3-256929FBBC86@gmail.com> Hello, First if all, I would like to thank you for this great tool! In StrokeDB project (http://strokedb.com) we've just started using it and it looks great! Though there seems to be few issues. One of them is addressed in this merge request: http://gitorious.org/projects/ditz/repos/mainline/merge_requests/39 Another problem is a little bit more painful. When I add an issue and another person adds an issue and then I pull his changes in, bugs.yaml can't be merged automatically ? it messes last addition (it becomes a conflict). I've tried to find some kind of solution for that, but still have no idea. Any thoughts? Yurii. From wmorgan-ditz at masanjin.net Sat Apr 5 19:18:20 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 16:18:20 -0700 Subject: [ditz-talk] hi everyone Message-ID: <1207437486-sup-979@south> Ok, apparently I wasn't actually subscribed to this list. Now I am! -- William From wmorgan-ditz at masanjin.net Sat Apr 5 19:29:34 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 16:29:34 -0700 Subject: [ditz-talk] [Ditz-talk] rubyforge synchronization In-Reply-To: <3bceeb2d0804030440q60c89823jc801cec28f8feb2d@mail.gmail.com> References: <3bceeb2d0804030440q60c89823jc801cec28f8feb2d@mail.gmail.com> Message-ID: <1207437800-sup-3398@south> Reformatted excerpts from Daniel Brumbaugh Keeney's message of 2008-04-03: > In my mind, synchronization with rubyforge is the killer feature for a > ruby desktop issue tracker. I mention this principally as a feature > request, and would be elated to see this feature implemented. What would such an integration mean? You could file bugs locally against packages and they would be sent to the proper rubyforge page? That would be a little difficult because the only way to actually add a bug with ditz is to commit a change to the repository... -- William From wmorgan-ditz at masanjin.net Sat Apr 5 20:07:42 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 17:07:42 -0700 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> Message-ID: <1207440422-sup-6919@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-03: > - def operation method, desc > + def operation method, desc, *args_spec I think I like this. Let me play around with it a little. -- William From wmorgan-ditz at masanjin.net Sat Apr 5 20:48:37 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 17:48:37 -0700 Subject: [ditz-talk] [Ditz-talk] Merging issues additions? In-Reply-To: <96EA2740-6C34-48F8-BDE3-256929FBBC86@gmail.com> References: <96EA2740-6C34-48F8-BDE3-256929FBBC86@gmail.com> Message-ID: <1207442177-sup-3548@south> Reformatted excerpts from yrashk's message of 2008-04-05: > First if all, I would like to thank you for this great tool! In > StrokeDB project (http://strokedb.com) we've just started using it and > it looks great! Glad to hear it. > Though there seems to be few issues. One of them is addressed in this > merge request: > http://gitorious.org/projects/ditz/repos/mainline/merge_requests/39 Got it, thanks. > Another problem is a little bit more painful. When I add an issue and > another person adds an issue and then I pull his changes in, bugs.yaml > can't be merged automatically ? it messes last addition (it becomes a > conflict). Yeah, this is a minor flaw in the whole "let the SCM sort it out" philosophy---two append operations conflict with each other, although it's a trivial conflict. The order doesn't really matter, but the SCM doesn't know that. I will probably add a ditz command to do the conflict resolution for you in simple cases like this. -- William From wmorgan-ditz at masanjin.net Sat Apr 5 21:46:05 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 18:46:05 -0700 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox In-Reply-To: <20080403155306.GB2553@beekeeper.hobix.com> References: <20080403155306.GB2553@beekeeper.hobix.com> Message-ID: <1207445443-sup-1181@south> Reformatted excerpts from why's message of 2008-04-03: > I am trying to cook up a strategy to offer users an interface to > submit tickets and comment on tickets. I know that probably doesn't > fit very well into this approach, but I've been wondering. One of the big advantages of ditz is that it raises the bar for feature requests by requiring you to check out a repository and commit code. And here you are, trying to circumvent that! > Let's say I have a web interface that has a clone of the repository > that is kept fresh by cron. And largely the interface is read-only. > Except users can add new tickets and new comments. I don't really > want the web interface to alter the bugs.yaml, in case there is a > conflict. In the git world, at least, you wouldn't actually have to worry about conflicts. Don't do anything with cron. The website adds issues and comments to its local bugs.yaml, probably committing each time. In your maintainer repo, you pull from it, merging and resolving any conflicts. Then you commit and push the changes to the website repo. Voila. If there have been changes to bugs.yaml from the website in the meantime, it will yell about a non-fast-forward update, in which case you'll have to merge/resolve/push again until you've caught up. (There are probably similar approaches with other dscms, but SVN definitely won't cut it for something like this.) > You commit new bugs and comments in a directory and after you "read" > them through ditz, it merges them into the bugs.yaml. It certainly won't be hard to do something like this if the above doesn't work for you for some reason. Heck, each entry could be a file that you just cat into ditz. As long as there are no issue deletions, the local names would remain the same, and at some point I want to modify it to accept issue ids in addition to issue names, which solves that problem anyways. -- William From wmorgan-ditz at masanjin.net Sat Apr 5 21:56:49 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 18:56:49 -0700 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox In-Reply-To: <730b2b9d0804041824s570a9187oc29813b03fc2ae33@mail.gmail.com> References: <730b2b9d0804041824s570a9187oc29813b03fc2ae33@mail.gmail.com> Message-ID: <1207446432-sup-4353@south> Reformatted excerpts from proppy's message of 2008-04-04: > That would be super awesome usecase since one would be able to ACK a > bug, just by applying the attached patch to his repo. Yep, exactly. > ++Agree that having issue in separate file with unique id (as you both > suggested) would avoid/reduce conflicts. Interesting. Replacing bugs.yaml by such a directory would solve the order problem entirely, wouldn't it? (Which also manifests when people apply such patches such as the above in different orders, and later merge.) The other solution would be to enforce an issue order within bugs.yaml, e.g. by sorting on issue ids. But that doesn't solve the concurrent add case, which probably is going to be the most common cause of conflict. -- William From wmorgan-ditz at masanjin.net Sat Apr 5 22:10:14 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 05 Apr 2008 19:10:14 -0700 Subject: [ditz-talk] related project: ticgit Message-ID: <1207447765-sup-2812@south> Just discovered this project: http://github.com/schacon/ticgit/wikis Git-specific, but also a distributed issue tracker with a pretty similar interface. -- William From smparkes at smparkes.net Sat Apr 5 18:35:47 2008 From: smparkes at smparkes.net (Steven Parkes) Date: Sat, 5 Apr 2008 15:35:47 -0700 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox Message-ID: <000001c8976d$64ccc530$2e664f90$@net> Interesting. Replacing bugs.yaml by such a directory would solve the order problem entirely, wouldn't it? But that doesn't solve the concurrent add case, which probably is going to be the most common cause of conflict. This sounds an awful lot like activerecord migrations which, as I understand it, just went from sequentially generated to time-stamped in order to drastically reduce if not eliminate conflicts during concurrent adds. From nicolas.pouillard at gmail.com Sun Apr 6 06:56:15 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 06 Apr 2008 12:56:15 +0200 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <1207440422-sup-6919@south> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> <1207440422-sup-6919@south> Message-ID: <1207479371-sup-2643@ausone.local> Excerpts from William Morgan's message of Sun Apr 06 02:07:42 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-03: > > - def operation method, desc > > + def operation method, desc, *args_spec > > I think I like this. Let me play around with it a little. Cool! About contributions, what do you prefer: patches in mails or merge request on gitorious? -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080406/edf2f729/attachment.bin From nicolas.pouillard at gmail.com Sun Apr 6 14:41:48 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 06 Apr 2008 20:41:48 +0200 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox In-Reply-To: <1207446432-sup-4353@south> References: <730b2b9d0804041824s570a9187oc29813b03fc2ae33@mail.gmail.com> <1207446432-sup-4353@south> Message-ID: <1207506049-sup-3934@ausone.local> Excerpts from William Morgan's message of Sun Apr 06 03:56:49 +0200 2008: > Reformatted excerpts from proppy's message of 2008-04-04: > > That would be super awesome usecase since one would be able to ACK a > > bug, just by applying the attached patch to his repo. > > Yep, exactly. > > > ++Agree that having issue in separate file with unique id (as you both > > suggested) would avoid/reduce conflicts. > > Interesting. Replacing bugs.yaml by such a directory would solve the > order problem entirely, wouldn't it? (Which also manifests when people > apply such patches such as the above in different orders, and later > merge.) > > The other solution would be to enforce an issue order within bugs.yaml, > e.g. by sorting on issue ids. But that doesn't solve the concurrent add > case, which probably is going to be the most common cause of conflict. As you've said, sorting would not suffice for most common cause of conflicts. In fact using a directory will solve all conflicts except those that are about the same issue. However one must "keep it simple". One of it's great advantage is too be close to some hand written bugs.txt (kind of enhanced TODO file), even if I think that supporting a directory format is needed for real distributed approach. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080406/a43187a1/attachment.bin From nicolas.pouillard at gmail.com Sun Apr 6 14:47:24 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 06 Apr 2008 20:47:24 +0200 Subject: [ditz-talk] related project: ticgit In-Reply-To: <1207447765-sup-2812@south> References: <1207447765-sup-2812@south> Message-ID: <1207507398-sup-1804@ausone.local> Excerpts from William Morgan's message of Sun Apr 06 04:10:14 +0200 2008: > Just discovered this project: http://github.com/schacon/ticgit/wikis > > Git-specific, but also a distributed issue tracker with a pretty similar > interface. Indeed... Although I think that your system independent approach is better (as a darcs fan), moreover ticgit hide the data from the user, in fact they try hard to hide a bugtracker inside your DSCM more than making it part of your source tree. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080406/6fdd0c43/attachment.bin From nicolas.pouillard at gmail.com Sun Apr 6 14:53:15 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 06 Apr 2008 20:53:15 +0200 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox In-Reply-To: <000001c8976d$64ccc530$2e664f90$@net> References: <000001c8976d$64ccc530$2e664f90$@net> Message-ID: <1207507663-sup-2549@ausone.local> Excerpts from Steven Parkes's message of Sun Apr 06 00:35:47 +0200 2008: > Interesting. Replacing bugs.yaml by such a directory would solve the > order problem entirely, wouldn't it? > > But that doesn't solve the concurrent add > case, which probably is going to be the most common cause of conflict. > > This sounds an awful lot like activerecord migrations which, as I understand > it, just went from sequentially generated to time-stamped in order to > drastically reduce if not eliminate conflicts during concurrent adds. IHMO the migration would not be so hard, but perhaps it would worth an hybrid approach where both formats are allowed. That way when one works alone or in a centralized manner one bugs.yml file is enough, but when working a lot with others it's preferable that they populate the bugs/ directory. This requires a command to convert back and forth issues from file to directory and one option to add to select the format. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080406/ae1884e0/attachment.bin From nicolas.pouillard at gmail.com Sun Apr 6 15:38:08 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 6 Apr 2008 21:38:08 +0200 Subject: [ditz-talk] [PATCH] print_todo no longer exists use todo_list_for instead. Message-ID: <1207510688-18442-1-git-send-email-nicolas.pouillard@gmail.com> --- lib/operator.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/operator.rb b/lib/operator.rb index 938468c..a2df640 100644 --- a/lib/operator.rb +++ b/lib/operator.rb @@ -396,7 +396,7 @@ EOS def grep project, config, match re = /#{match}/ issues = project.issues.select { |i| i.title =~ re || i.desc =~ re } - print_todo issues + print todo_list_for(issues) end operation :edit, "Edit an issue", :issue -- 1.5.5.rc3 From wmorgan-ditz at masanjin.net Sun Apr 6 17:32:56 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 06 Apr 2008 14:32:56 -0700 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <1207479371-sup-2643@ausone.local> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> <1207440422-sup-6919@south> <1207479371-sup-2643@ausone.local> Message-ID: <1207516149-sup-1038@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-06: > About contributions, what do you prefer: patches in mails or merge > request on gitorious? I'm happy with either. It seems like merge requests probably make developers' lives easier (no need to worry about my local copy of the change versus its duplicate once applied in the remote repository), though I appreciate the immediate public review opportunities of the email patch. -- William From wmorgan-ditz at masanjin.net Sun Apr 6 17:51:26 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 06 Apr 2008 14:51:26 -0700 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox In-Reply-To: <1207507663-sup-2549@ausone.local> References: <000001c8976d$64ccc530$2e664f90$@net> <1207507663-sup-2549@ausone.local> Message-ID: <1207518526-sup-5916@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-06: > IHMO the migration would not be so hard, but perhaps it would worth > an hybrid approach where both formats are allowed. That way when one > works alone or in a centralized manner one bugs.yml file is enough, > but when working a lot with others it's preferable that they > populate the bugs/ directory. This requires a command to convert > back and forth issues from file to directory and one option to add to > select the format. I think for simplicity's sake, the official plan must be separate files per issue. As long as the UI is good enough, the user shouldn't really care about the details of how things are stored, and the monolithic file doesn't really any offer any advantages, only disadvantages. -- William From wmorgan-ditz at masanjin.net Sun Apr 6 18:17:43 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 06 Apr 2008 15:17:43 -0700 Subject: [ditz-talk] [PATCH] print_todo no longer exists use todo_list_for instead. In-Reply-To: <1207510688-18442-1-git-send-email-nicolas.pouillard@gmail.com> References: <1207510688-18442-1-git-send-email-nicolas.pouillard@gmail.com> Message-ID: <1207520252-sup-4100@south> Applied, thanks! -- William From wmorgan-ditz at masanjin.net Sun Apr 6 23:51:18 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 06 Apr 2008 20:51:18 -0700 Subject: [ditz-talk] [Ditz-talk] Merging issues additions? In-Reply-To: <96EA2740-6C34-48F8-BDE3-256929FBBC86@gmail.com> References: <96EA2740-6C34-48F8-BDE3-256929FBBC86@gmail.com> Message-ID: <1207540253-sup-1287@south> Reformatted excerpts from yrashk's message of 2008-04-05: > Though there seems to be few issues. One of them is addressed in this > merge request: > http://gitorious.org/projects/ditz/repos/mainline/merge_requests/39 This has been merged in. Thanks! -- William From wmorgan-ditz at masanjin.net Mon Apr 7 01:14:29 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 06 Apr 2008 22:14:29 -0700 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> Message-ID: <1207545077-sup-3797@south> This is in. But I made a lot of tweaks to it in later commits. Thanks! -- William From nicolas.pouillard at gmail.com Mon Apr 7 06:59:22 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 07 Apr 2008 12:59:22 +0200 Subject: [ditz-talk] [Ditz-talk] something like a ticket inbox In-Reply-To: <1207518526-sup-5916@south> References: <000001c8976d$64ccc530$2e664f90$@net> <1207507663-sup-2549@ausone.local> <1207518526-sup-5916@south> Message-ID: <1207565712-sup-9326@ausone.inria.fr> Excerpts from William Morgan's message of Sun Apr 06 23:51:26 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-06: > > IHMO the migration would not be so hard, but perhaps it would worth > > an hybrid approach where both formats are allowed. That way when one > > works alone or in a centralized manner one bugs.yml file is enough, > > but when working a lot with others it's preferable that they > > populate the bugs/ directory. This requires a command to convert > > back and forth issues from file to directory and one option to add to > > select the format. > > I think for simplicity's sake, the official plan must be separate files > per issue. As long as the UI is good enough, the user shouldn't really > care about the details of how things are stored, and the monolithic file > doesn't really any offer any advantages, only disadvantages. Don't get me wrong I also think that the bugs/ directory approach is a "must have" feature. However simplicity is not only in the code but also for the user, and keeping the internal representation simple is a great strength. Note: why not having different kind of "sources" for issues, one could be the original monolithic file and another could be directory approach. The gain is for future extensibility. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080407/71d505d3/attachment.bin From wmorgan-ditz at masanjin.net Mon Apr 7 13:03:52 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 07 Apr 2008 10:03:52 -0700 Subject: [ditz-talk] new in git: one file per issue Message-ID: <1207587768-sup-9894@south> It's here. Directly in master. Use bin/ditz-convert-from-monolith to convert your bugs.yaml into a shiny new bugs/ directory. -- William From nicolas.pouillard at gmail.com Mon Apr 7 15:00:43 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 07 Apr 2008 21:00:43 +0200 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207587768-sup-9894@south> References: <1207587768-sup-9894@south> Message-ID: <1207594711-sup-5748@ausone.local> Excerpts from William Morgan's message of Mon Apr 07 19:03:52 +0200 2008: > It's here. Directly in master. Use bin/ditz-convert-from-monolith to > convert your bugs.yaml into a shiny new bugs/ directory. Cool! Just a question... I don't get how you build short issue names (component-12), they seems to be kept ordered but since it's a directory now I'm lost? -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080407/7f073515/attachment.bin From wmorgan-ditz at masanjin.net Mon Apr 7 15:15:34 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 07 Apr 2008 12:15:34 -0700 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207594711-sup-5748@ausone.local> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> Message-ID: <1207595667-sup-945@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-07: > Just a question... I don't get how you build short > issue names (component-12), they seems to be kept ordered but since > it's a directory now I'm lost? Issues have creation times, and that's how they're assigned. These names are non-global and change if you drop earlier issues. -- William From nicolas.pouillard at gmail.com Mon Apr 7 15:33:56 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 07 Apr 2008 21:33:56 +0200 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207595667-sup-945@south> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> <1207595667-sup-945@south> Message-ID: <1207596798-sup-8906@ausone.local> Excerpts from William Morgan's message of Mon Apr 07 21:15:34 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-07: > > Just a question... I don't get how you build short > > issue names (component-12), they seems to be kept ordered but since > > it's a directory now I'm lost? > > Issues have creation times, and that's how they're assigned. These names > are non-global and change if you drop earlier issues. Ok I just don't see it in the code. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080407/caa7f836/attachment.bin From why at whytheluckystiff.net Mon Apr 7 16:08:49 2008 From: why at whytheluckystiff.net (_why) Date: Mon, 7 Apr 2008 15:08:49 -0500 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. Message-ID: <20080407200849.GY27840@beekeeper.hobix.com> --- lib/operator.rb | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/lib/operator.rb b/lib/operator.rb index e68087f..c48808b 100644 --- a/lib/operator.rb +++ b/lib/operator.rb @@ -401,6 +401,13 @@ EOS end end + operation :prune, "Drop all tickets related to a relase", :release + def prune project, config, release + issues = release.issues_from project + issues.each { |issue| project.drop_issue issue } + puts "Pruned #{release.name}." + end + operation :validate, "Validate project status" def validate project, config ## a no-op -- 1.4.4 From yrashk at gmail.com Mon Apr 7 17:34:46 2008 From: yrashk at gmail.com (Yurii Rashkovskii) Date: Tue, 8 Apr 2008 00:34:46 +0300 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207587768-sup-9894@south> References: <1207587768-sup-9894@south> Message-ID: <0CC5B08B-3A24-494E-9EBA-85C4EBC099EE@gmail.com> Shouldn't comments/log entries be in separate files as well to avoid conflicts if 2+ parties are trying to work with the same issue simultaneously? Or you don't want to go that far? On Apr 7, 2008, at 8:03 PM, William Morgan wrote: > It's here. Directly in master. Use bin/ditz-convert-from-monolith to > convert your bugs.yaml into a shiny new bugs/ directory. > > -- > William From wmorgan-ditz at masanjin.net Mon Apr 7 18:15:18 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 07 Apr 2008 15:15:18 -0700 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207596798-sup-8906@ausone.local> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> <1207595667-sup-945@south> <1207596798-sup-8906@ausone.local> Message-ID: <1207606487-sup-8070@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-07: > Excerpts from William Morgan's message of Mon Apr 07 21:15:34 +0200 2008: > > Issues have creation times, and that's how they're assigned. These > > names are non-global and change if you drop earlier issues. > > Ok I just don't see it in the code. Project#assign_issue_names! -- William From wmorgan-ditz at masanjin.net Mon Apr 7 18:36:19 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 07 Apr 2008 15:36:19 -0700 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <0CC5B08B-3A24-494E-9EBA-85C4EBC099EE@gmail.com> References: <1207587768-sup-9894@south> <0CC5B08B-3A24-494E-9EBA-85C4EBC099EE@gmail.com> Message-ID: <1207606521-sup-5265@south> Reformatted excerpts from Yurii Rashkovskii's message of 2008-04-07: > Shouldn't comments/log entries be in separate files as well to avoid > conflicts if 2+ parties are trying to work with the same issue > simultaneously? Or you don't want to go that far? You're right, this has the same problem. I think I'm happy to leave it for the time being, though, and see how many people complain. It's not going to be nearly as prevalent a problem, for one thing. -- William From wmorgan-ditz at masanjin.net Mon Apr 7 18:38:09 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 07 Apr 2008 15:38:09 -0700 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. In-Reply-To: <20080407200849.GY27840@beekeeper.hobix.com> References: <20080407200849.GY27840@beekeeper.hobix.com> Message-ID: <1207607828-sup-3995@south> I was actually thinking of having an archive command, which would be like this but would save the issues somewhere. What do you think? -- William From why at whytheluckystiff.net Mon Apr 7 19:38:01 2008 From: why at whytheluckystiff.net (_why) Date: Mon, 7 Apr 2008 18:38:01 -0500 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. In-Reply-To: <1207607828-sup-3995@south> References: <20080407200849.GY27840@beekeeper.hobix.com> <1207607828-sup-3995@south> Message-ID: <20080407233800.GZ27840@beekeeper.hobix.com> On Mon, Apr 07, 2008 at 03:38:09PM -0700, William Morgan wrote: > I was actually thinking of having an archive command, which would be > like this but would save the issues somewhere. What do you think? Oh, okay, sure. As long as I can move them out of the repository, that sounds great. Or maybe hooks could be offered to override the defaults? ~/.ditzrc: Ditz.on_archive do |project, config, release| release.issues_from(project). each { |issue| project.drop_issue issue } end Ditz.after_add do |project, config, issue| `git add bugs/#{ISSUE_TO_FN(issue)}` end Anyway, a very minor thing. The new dir structure is tops. _why From nicolas.pouillard at gmail.com Tue Apr 8 03:02:48 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 08 Apr 2008 09:02:48 +0200 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207606487-sup-8070@south> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> <1207595667-sup-945@south> <1207596798-sup-8906@ausone.local> <1207606487-sup-8070@south> Message-ID: <1207637842-sup-2223@port-ext16.ensta.fr> Excerpts from William Morgan's message of Tue Apr 08 00:15:18 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-07: > > Excerpts from William Morgan's message of Mon Apr 07 21:15:34 +0200 2008: > > > Issues have creation times, and that's how they're assigned. These > > > names are non-global and change if you drop earlier issues. > > > > Ok I just don't see it in the code. > > Project#assign_issue_names! In assign_issue_names! you iterate over project.issues in order, however if I read well @issues is defined once in bin/ditz project.issues = Dir[fn].map { |fn| Ditz::Issue.from fn } which seems to follow the directory order and not creation times. Moreover I think I've hit the relating bug where adding a bug and there after wanted to close it but it's name was not as intended the last + 1 but has been inserted between others that I made before. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080408/7adf509f/attachment.bin From wmorgan-ditz at masanjin.net Tue Apr 8 10:33:53 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 08 Apr 2008 07:33:53 -0700 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207637842-sup-2223@port-ext16.ensta.fr> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> <1207595667-sup-945@south> <1207596798-sup-8906@ausone.local> <1207606487-sup-8070@south> <1207637842-sup-2223@port-ext16.ensta.fr> Message-ID: <1207665016-sup-2090@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-08: > In assign_issue_names! you iterate over project.issues in order, > however if I read well @issues is defined once in bin/ditz > project.issues = Dir[fn].map { |fn| Ditz::Issue.from fn } > which seems to follow the directory order and not creation times. You're right. That worked when the issues were in the YAML file in creation order, but doesn't in the file-based world. What about this patch? diff --git a/lib/model-objects.rb b/lib/model-objects.rb index 1c4f311..5cd3156 100644 --- a/lib/model-objects.rb +++ b/lib/model-objects.rb @@ -86,7 +86,7 @@ EOS def assign_issue_names! prefixes = components.map { |c| [c.name, c.name.gsub(/^\s+/, "-").downcase] ids = components.map { |c| [c.name, 0] }.to_h - issues.each do |i| + issues.sort_by { |i| i.creation_time }.each do |i| i.name = "#{prefixes[i.component]}-#{ids[i.component] += 1}" end end > Moreover I think I've hit the relating bug where adding a bug and > there after wanted to close it but it's name was not as intended > the last + 1 but has been inserted between others that I made before. Yeah, that's exactly the behavior the above bug would cause. Good catch. -- William From nicolas.pouillard at gmail.com Tue Apr 8 10:51:21 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 08 Apr 2008 16:51:21 +0200 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207665016-sup-2090@south> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> <1207595667-sup-945@south> <1207596798-sup-8906@ausone.local> <1207606487-sup-8070@south> <1207637842-sup-2223@port-ext16.ensta.fr> <1207665016-sup-2090@south> Message-ID: <1207666003-sup-6269@port-ext16.ensta.fr> Excerpts from William Morgan's message of Tue Apr 08 16:33:53 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-08: > > In assign_issue_names! you iterate over project.issues in order, > > however if I read well @issues is defined once in bin/ditz > > project.issues = Dir[fn].map { |fn| Ditz::Issue.from fn } > > which seems to follow the directory order and not creation times. > > You're right. That worked when the issues were in the YAML file in > creation order, but doesn't in the file-based world. What about this > patch? > > diff --git a/lib/model-objects.rb b/lib/model-objects.rb > index 1c4f311..5cd3156 100644 > --- a/lib/model-objects.rb > +++ b/lib/model-objects.rb > @@ -86,7 +86,7 @@ EOS > def assign_issue_names! > prefixes = components.map { |c| [c.name, c.name.gsub(/^\s+/, "-").downcase] > ids = components.map { |c| [c.name, 0] }.to_h > - issues.each do |i| > + issues.sort_by { |i| i.creation_time }.each do |i| > i.name = "#{prefixes[i.component]}-#{ids[i.component] += 1}" > end > end > > > Moreover I think I've hit the relating bug where adding a bug and > > there after wanted to close it but it's name was not as intended > > the last + 1 but has been inserted between others that I made before. > > Yeah, that's exactly the behavior the above bug would cause. Good catch. That's a good fix however I've committed a similar one in my branch and made a merge request [1]. [1]: http://gitorious.org/projects/ditz/repos/mainline/merge_requests/42 -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080408/ed899c2d/attachment.bin From wmorgan-ditz at masanjin.net Tue Apr 8 12:35:15 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Tue, 08 Apr 2008 09:35:15 -0700 Subject: [ditz-talk] new in git: one file per issue In-Reply-To: <1207666003-sup-6269@port-ext16.ensta.fr> References: <1207587768-sup-9894@south> <1207594711-sup-5748@ausone.local> <1207595667-sup-945@south> <1207596798-sup-8906@ausone.local> <1207606487-sup-8070@south> <1207637842-sup-2223@port-ext16.ensta.fr> <1207665016-sup-2090@south> <1207666003-sup-6269@port-ext16.ensta.fr> Message-ID: <1207672504-sup-6700@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-08: > That's a good fix however I've committed a similar one in my branch and made > a merge request [1]. Merged! -- William From wmorgan-ditz at masanjin.net Wed Apr 9 12:32:16 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 09 Apr 2008 09:32:16 -0700 Subject: [ditz-talk] new in git: ditz log, and /commands for editing Message-ID: <1207758614-sup-1490@south> * 'ditz log' now prints all log events by recency * Within a multiline edit, you can use /reset to restart, and /edit to move the whole thing over to an editor -- William From nicolas.pouillard at gmail.com Wed Apr 9 13:29:08 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed, 09 Apr 2008 19:29:08 +0200 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <1207516149-sup-1038@south> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> <1207440422-sup-6919@south> <1207479371-sup-2643@ausone.local> <1207516149-sup-1038@south> Message-ID: <1207761940-sup-3950@port-ext16.ensta.fr> Excerpts from William Morgan's message of Sun Apr 06 23:32:56 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-06: > > About contributions, what do you prefer: patches in mails or merge > > request on gitorious? > > I'm happy with either. It seems like merge requests probably make > developers' lives easier (no need to worry about my local copy of the > change versus its duplicate once applied in the remote repository), > though I appreciate the immediate public review opportunities of the > email patch. I prefer the email-patch approach, but as I understand it, if you don't apply it quickly I we will have to 'rebase' it and then loose the fact that we have the same patch. The clone+merge-request approach seems to fix this but I'm not sure you like the web based approach, perhaps a mail on mailing list would be better. BTW I've just made such a merge request on gitorious. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080409/ca5d081b/attachment.bin From wmorgan-ditz at masanjin.net Wed Apr 9 15:44:39 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 09 Apr 2008 12:44:39 -0700 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <1207761940-sup-3950@port-ext16.ensta.fr> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> <1207440422-sup-6919@south> <1207479371-sup-2643@ausone.local> <1207516149-sup-1038@south> <1207761940-sup-3950@port-ext16.ensta.fr> Message-ID: <1207770182-sup-4188@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-09: > I prefer the email-patch approach, I guess I have a mild preference for it too because I reviewing the patches directly in email, but would rather lower the bar for contributions than enforce a strict policy. And it's only a mild preference. > but as I understand it, if you don't apply it quickly I we will have > to 'rebase' it and then loose the fact that we have the same patch. Actually, here's what I just discovered. If your email-submitted patches are kept on a separate branch (i.e. not applied directly to the tracking branch), and you pull your tracking branch to get remote changes and then rebase the submitted branch against that, the patches that were applied to the remote branch will become empty and the rebase will drop them. So there's no change duplication that way. Of course, if you just merge, the duplicates will appear in both places (except for some fast-forwarding behavior). Moral of the story: keep changes on branches, and rebase is your friend. > BTW I've just made such a merge request on gitorious. Got it! -- William From nicolas.pouillard at gmail.com Wed Apr 9 17:44:02 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Wed, 09 Apr 2008 23:44:02 +0200 Subject: [ditz-talk] [Ditz-talk] [PATCH] Improve automatic documentation and checking of command arguments. In-Reply-To: <1207770182-sup-4188@south> References: <12072249293848-git-send-email-nicolas.pouillard@gmail.com> <1207440422-sup-6919@south> <1207479371-sup-2643@ausone.local> <1207516149-sup-1038@south> <1207761940-sup-3950@port-ext16.ensta.fr> <1207770182-sup-4188@south> Message-ID: <1207777244-sup-8013@ausone.local> Excerpts from William Morgan's message of Wed Apr 09 21:44:39 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-09: > > I prefer the email-patch approach, > > I guess I have a mild preference for it too because I reviewing the > patches directly in email, but would rather lower the bar for > contributions than enforce a strict policy. And it's only a mild > preference. > > > but as I understand it, if you don't apply it quickly I we will have > > to 'rebase' it and then loose the fact that we have the same patch. > > Actually, here's what I just discovered. If your email-submitted patches > are kept on a separate branch (i.e. not applied directly to the tracking > branch), and you pull your tracking branch to get remote changes and > then rebase the submitted branch against that, the patches that were > applied to the remote branch will become empty and the rebase will drop > them. > > So there's no change duplication that way. Of course, if you just merge, > the duplicates will appear in both places (except for some > fast-forwarding behavior). Ok I will try this way then. I should be able to propose some shell completion support for commands, issue names, components, and releases hoping you'll like it! > Moral of the story: keep changes on branches, and rebase is your friend. Moral git is a lot more complicated than needed (reads it: "darcs is better"). > > BTW I've just made such a merge request on gitorious. > > Got it! Thanks. PS: darcs2 has been released! It's time to (re-)give a try! -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080409/7adad1de/attachment.bin From nicolas.pouillard at gmail.com Wed Apr 9 19:55:17 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 10 Apr 2008 01:55:17 +0200 Subject: [ditz-talk] [PATCH] Add support shell completion (zsh for now). Message-ID: <1207785317-93954-1-git-send-email-nicolas.pouillard@gmail.com> Note: patch pushed on my repo-clone as well. --- bin/ditz | 14 +++++++++++++- contrib/completion/_ditz.zsh | 29 +++++++++++++++++++++++++++++ lib/operator.rb | 15 ++++++++++++++- 3 files changed, 56 insertions(+), 2 deletions(-) create mode 100644 contrib/completion/_ditz.zsh diff --git a/bin/ditz b/bin/ditz index 0b042df..4b85d0a 100755 --- a/bin/ditz +++ b/bin/ditz @@ -1,5 +1,18 @@ #!/usr/bin/env ruby +# requires are splitted in two for efficiency reasons +# ditz should be really fast when using it for +# completion. +require 'operator' + +op = Ditz::Operator.new + +# a secret option for shell completion +if ARGV.include? '--commands' + puts op.class.operations.map { |name, _| name } + exit 0 +end + require 'rubygems' require 'fileutils' require 'trollop'; include Trollop @@ -17,7 +30,6 @@ $opts = options do end cmd = ARGV.shift or die "expecting a ditz command" -op = Ditz::Operator.new dir = $opts[:issue_dir] case cmd # some special cases not handled by Ditz::Operator diff --git a/contrib/completion/_ditz.zsh b/contrib/completion/_ditz.zsh new file mode 100644 index 0000000..656860f --- /dev/null +++ b/contrib/completion/_ditz.zsh @@ -0,0 +1,29 @@ +#compdef ditz + +ME=ditz +COMMANDS=--commands +OPTIONS='' + +if (($CURRENT == 2)); then + # We're completing the first word after the tool: the command. + _wanted command expl "$ME command" \ + compadd -- $( "$ME" "$COMMANDS" ) +else + # Find the options/files/URL/etc. for the current command by using the tool itself. + case "${words[$CURRENT]}"; in + -*) + _wanted args expl "Arguments for $ME ${words[2]}" \ + compadd -- $( "$ME" "${words[2]}" "$OPTIONS" ; _files ) + ;; + ht*|ft*) + _arguments '*:URL:_urls' + ;; + /*|./*|\~*|../*) + _arguments '*:file:_files' + ;; + *) + _wanted args expl "Arguments for $ME ${words[2]}" \ + compadd -- $( "$ME" "${words[2]}" "$OPTIONS" ) + ;; + esac +fi diff --git a/lib/operator.rb b/lib/operator.rb index 74c9507..74ce0b0 100644 --- a/lib/operator.rb +++ b/lib/operator.rb @@ -59,10 +59,12 @@ class Operator command = "command '#{method_to_op method}'" built_args = @operations[method][:args_spec].map do |spec| val = args.shift + generate_choices(project, method, spec) if val == '' case spec when :issue raise Error, "#{command} requires an issue name" unless val - project.issue_for(val) or raise Error, "no issue with name #{val}" + valr = val.sub(/\A(\w+-\d+)_.*$/,'\1') + project.issue_for(valr) or raise Error, "no issue with name #{val}" when :release raise Error, "#{command} requires a release name" unless val project.release_for(val) or raise Error, "no release with name #{val}" @@ -75,9 +77,20 @@ class Operator val # no translation for other types end end + generate_choices(project, method, nil) if args.include? '' raise Error, "too many arguments for #{command}" unless args.empty? built_args end + + def generate_choices project, method, spec + case spec + when :issue + puts project.issues.map { |i| "#{i.name}_#{i.title.gsub(/\W+/, '-')}" } + when :release, :maybe_release + puts project.releases.map { |r| r.name } + end + exit 0 + end end def do op, project, config, args -- 1.5.5.rc3 From nicolas.pouillard at gmail.com Thu Apr 10 08:48:49 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 10 Apr 2008 14:48:49 +0200 Subject: [ditz-talk] [PATCH] Generalize handling of issues to support more types of issue. Message-ID: <1207831729-99937-1-git-send-email-nicolas.pouillard@gmail.com> --- lib/lowline.rb | 5 +++- lib/model-objects.rb | 8 ++++++- lib/operator.rb | 58 +++++++++++++++++++++++++------------------------- lib/util.rb | 8 +++++++ 4 files changed, 48 insertions(+), 31 deletions(-) diff --git a/lib/lowline.rb b/lib/lowline.rb index 74895d6..3d0a781 100644 --- a/lib/lowline.rb +++ b/lib/lowline.rb @@ -17,7 +17,10 @@ class String def blank?; self =~ /\A\s*\z/ end def underline; self + "\n" + ("-" * self.length) end def multiline prefix=""; blank? ? "" : "\n" + self.gsub(/^/, prefix) end - def pluralize n; n.to_pretty_s + " " + (n == 1 ? self : self + "s") end # oh yeah + def pluralize n, b=true + s = (n == 1 ? self : (self == 'bugfix' ? 'bugfixes' : self + "s")) # oh yeah + b ? n.to_pretty_s + " " + s : s + end end class Array diff --git a/lib/model-objects.rb b/lib/model-objects.rb index 5cd3156..e5bf293 100644 --- a/lib/model-objects.rb +++ b/lib/model-objects.rb @@ -83,6 +83,10 @@ EOS issues.select { |i| i.release.nil? } end + def group_issues these_issues=issues + these_issues.group_by { |i| i.type }.sort_by { |(t,g)| Issue::TYPE_ORDER[t] } + end + def assign_issue_names! prefixes = components.map { |c| [c.name, c.name.gsub(/^\s+/, "-").downcase] }.to_h ids = components.map { |c| [c.name, 0] }.to_h @@ -122,6 +126,8 @@ class Issue < ModelObject STATUS_WIDGET = { :unstarted => "_", :in_progress => ">", :paused => "=", :closed => "x" } DISPOSITIONS = [ :fixed, :wontfix, :reorg ] TYPES = [ :bugfix, :feature ] + TYPE_ORDER = { :bugfix => 0, :feature => 1 } + TYPE_LETTER = { 'b' => :bugfix, 'f' => :feature } STATUSES = STATUS_WIDGET.keys STATUS_STRINGS = { :in_progress => "in progress", :wontfix => "won't fix" } @@ -213,7 +219,7 @@ class Issue < ModelObject def get_type config, project type = ask "Is this a (b)ugfix or a (f)eature?", :restrict => /^[bf]$/ - type == "b" ? :bugfix : :feature + TYPE_LETTER[type] end def get_component config, project diff --git a/lib/operator.rb b/lib/operator.rb index 74ce0b0..355b8e2 100644 --- a/lib/operator.rb +++ b/lib/operator.rb @@ -35,23 +35,20 @@ class Operator releases.each do |r| next if r.released? unless force_show - bugs = project.issues. - select { |i| i.type == :bugfix && i.release == r.name } - feats = project.issues. - select { |i| i.type == :feature && i.release == r.name } + groups = project.group_issues(project.issues_for_release(r)) - #next if bugs.empty? && feats.empty? unless force_show + #next if groups.empty? unless force_show - ret << [r, bugs, feats] + ret << [r, groups] end return ret unless show_unassigned - bugs = project.issues.select { |i| i.type == :bugfix && i.release.nil? } - feats = project.issues.select { |i| i.type == :feature && i.release.nil? } + groups = project.group_issues(project.unassigned_issues) - return ret if bugs.empty? && feats.empty? unless force_show - ret << [nil, bugs, feats] + return ret if groups.empty? unless force_show + + ret << [nil, groups] end private :parse_releases_arg @@ -132,7 +129,7 @@ EOS puts end - operation :add, "Add a bug/feature request" + operation :add, "Add an issue" def add project, config issue = Issue.create_interactively(:args => [config, project]) or return comment = ask_multiline "Comments" @@ -142,7 +139,7 @@ EOS puts "Added issue #{issue.name}." end - operation :drop, "Drop a bug/feature request", :issue + operation :drop, "Drop an issue", :issue def drop project, config, issue project.drop_issue issue puts "Dropped #{issue.name}. Note that other issue names may have changed." @@ -176,26 +173,30 @@ EOS operation :status, "Show project status", :maybe_release def status project, config, releases - releases.each do |r, bugs, feats| - title, bar = [r ? r.name : "unassigned", status_bar_for(bugs + feats)] - - ncbugs = bugs.count_of { |b| b.closed? } - ncfeats = feats.count_of { |f| f.closed? } - pcbugs = 100.0 * (bugs.empty? ? 1.0 : ncbugs.to_f / bugs.size) - pcfeats = 100.0 * (feats.empty? ? 1.0 : ncfeats.to_f / feats.size) + releases.each do |r, groups| + issues = groups.map { |_,g| g }.flatten + title = r ? r.name : "unassigned" + + groups = groups.map do |t,g| + nc = g.count_of { |i| i.closed? } + pc = 100.0 * (g.empty? ? 1.0 : nc.to_f / g.size) + [t, g, nc, pc] + end special = if r && r.released? "(released)" - elsif bugs.empty? && feats.empty? + elsif groups.empty? "(no issues)" - elsif ncbugs == bugs.size && ncfeats == feats.size + elsif issues.all? { |i| i.closed? } "(ready for release)" else - bar + status_bar_for(issues) end - printf "%-10s %2d/%2d (%3.0f%%) bugs, %2d/%2d (%3.0f%%) features %s\n", - title, ncbugs, bugs.size, pcbugs, ncfeats, feats.size, pcfeats, special + middle = groups.map do |(t,g,nc,pc)| + "%2d/%2d (%3.0f%%) %s" % [nc, g.size, pc, t.to_s.pluralize(g.size, false)] + end.join(', ') + printf "%-10s %s %s\n", title, middle, special end if project.releases.empty? @@ -230,13 +231,13 @@ EOS end def actually_do_todo project, config, releases, full - releases.each do |r, bugs, feats| + releases.each do |r, groups| if r puts "Version #{r.name} (#{r.status}):" else puts "Unassigned:" end - issues = bugs + feats + issues = groups.map { |_,g| g }.flatten issues = issues.select { |i| i.open? } unless full puts(todo_list_for(issues.sort_by { |i| i.sort_order }) || "No open issues.") puts @@ -347,10 +348,9 @@ EOS operation :changelog, "Generate a changelog for a release", :release def changelog project, config, r - feats, bugs = project.issues_for_release(r).partition { |i| i.feature? } puts "== #{r.name} / #{r.released? ? r.release_time.pretty_date : 'unreleased'}" - feats.select { |f| f.closed? }.each { |i| puts "* #{i.title}" } - bugs.select { |f| f.closed? }.each { |i| puts "* bugfix: #{i.title}" } + project.group_issues(project.issues_for_release(r)). + each { |t,g| g.select { |i| i.closed? }.each { |i| puts "* #{t}: #{i.title}" } } end operation :html, "Generate html status pages", :dir diff --git a/lib/util.rb b/lib/util.rb index 7812a1c..03dba7e 100644 --- a/lib/util.rb +++ b/lib/util.rb @@ -19,6 +19,14 @@ module Enumerable each { |e| x = yield(e); return x if x } nil end + + def group_by + inject({}) do |groups, element| + (groups[yield(element)] ||= []) << element + groups + end + end if RUBY_VERSION < '1.9' + end class Array -- 1.5.5.rc3 From nicolas.pouillard at gmail.com Thu Apr 10 08:48:57 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 10 Apr 2008 14:48:57 +0200 Subject: [ditz-talk] [PATCH] Add a new kind of issue, namely Tasks. Message-ID: <1207831737-99965-1-git-send-email-nicolas.pouillard@gmail.com> --- lib/model-objects.rb | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/model-objects.rb b/lib/model-objects.rb index e5bf293..7472769 100644 --- a/lib/model-objects.rb +++ b/lib/model-objects.rb @@ -125,9 +125,9 @@ class Issue < ModelObject STATUS_SORT_ORDER = { :unstarted => 2, :paused => 1, :in_progress => 0, :closed => 3 } STATUS_WIDGET = { :unstarted => "_", :in_progress => ">", :paused => "=", :closed => "x" } DISPOSITIONS = [ :fixed, :wontfix, :reorg ] - TYPES = [ :bugfix, :feature ] - TYPE_ORDER = { :bugfix => 0, :feature => 1 } - TYPE_LETTER = { 'b' => :bugfix, 'f' => :feature } + TYPES = [ :bugfix, :feature, :task ] + TYPE_ORDER = { :bugfix => 0, :feature => 1, :task => 2 } + TYPE_LETTER = { 'b' => :bugfix, 'f' => :feature, 't' => :task } STATUSES = STATUS_WIDGET.keys STATUS_STRINGS = { :in_progress => "in progress", :wontfix => "won't fix" } @@ -218,7 +218,7 @@ class Issue < ModelObject end def get_type config, project - type = ask "Is this a (b)ugfix or a (f)eature?", :restrict => /^[bf]$/ + type = ask "Is this a (b)ugfix, a (f)eature, or a (t)ask?", :restrict => /^[bft]$/ TYPE_LETTER[type] end -- 1.5.5.rc3 From wmorgan-ditz at masanjin.net Thu Apr 10 12:20:32 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Thu, 10 Apr 2008 09:20:32 -0700 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. In-Reply-To: <20080407233800.GZ27840@beekeeper.hobix.com> References: <20080407200849.GY27840@beekeeper.hobix.com> <1207607828-sup-3995@south> <20080407233800.GZ27840@beekeeper.hobix.com> Message-ID: <1207844408-sup-1739@south> Reformatted excerpts from _why's message of 2008-04-07: > Ditz.on_archive do |project, config, release| > release.issues_from(project). > each { |issue| project.drop_issue issue } > end > > Ditz.after_add do |project, config, issue| > `git add bugs/#{ISSUE_TO_FN(issue)}` > end Hookability is definitely in the plans. -- William From wmorgan-ditz at masanjin.net Thu Apr 10 13:28:23 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Thu, 10 Apr 2008 10:28:23 -0700 Subject: [ditz-talk] [Gitorious] ertai has requested a merge in ditz In-Reply-To: <47fcfba23957a_70d015ae47b26f003f@octimal.tmail> References: <47fcfba23957a_70d015ae47b26f003f@octimal.tmail> Message-ID: <1207848428-sup-2354@south> Out of curiousity, how are you getting nil descriptions? http://gitorious.org/projects/ditz/repos/clone-by-ertai/commits/dee960e98b6a60dcea4fb5160e22858bbedef338 Reformatted excerpts from Gitorious's message of 2008-04-09: > Hello wmorgan, > > ertai has requested that you merge clone-by-ertai with mainline in the ditz > project. > > --- > small fix showed by ditz show when the issue have a nil description > --- > > You can review the request and its commits here: > http://gitorious.org/p/ditz/repos/mainline/merge_requests/45 > > Thank you > > http://gitorious.org -- William From nicolas.pouillard at gmail.com Thu Apr 10 17:13:23 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 10 Apr 2008 23:13:23 +0200 Subject: [ditz-talk] [Gitorious] ertai has requested a merge in ditz In-Reply-To: <1207848428-sup-2354@south> References: <47fcfba23957a_70d015ae47b26f003f@octimal.tmail> <1207848428-sup-2354@south> Message-ID: <1207861345-sup-1511@ausone.local> Excerpts from William Morgan's message of Thu Apr 10 19:28:23 +0200 2008: > Out of curiousity, how are you getting nil descriptions? Hum... I can't reproduce it, but it was some very basic usage. I've added a bunch of issues, most of them without description or comments, and then done a "ditz show ...", and got this error. I will run without the fix for a while in order to see it again. > http://gitorious.org/projects/ditz/repos/clone-by-ertai/commits/dee960e98b6a60dcea4fb5160e22858bbedef338 > > Reformatted excerpts from Gitorious's message of 2008-04-09: > > Hello wmorgan, > > > > ertai has requested that you merge clone-by-ertai with mainline in the ditz > > project. > > > > --- > > small fix showed by ditz show when the issue have a nil description > > --- > > > > You can review the request and its commits here: > > http://gitorious.org/p/ditz/repos/mainline/merge_requests/45 > > > > Thank you > > > > http://gitorious.org > -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080410/4c093d78/attachment.bin From nicolas.pouillard at gmail.com Thu Apr 10 17:14:50 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Thu, 10 Apr 2008 23:14:50 +0200 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. In-Reply-To: <1207844408-sup-1739@south> References: <20080407200849.GY27840@beekeeper.hobix.com> <1207607828-sup-3995@south> <20080407233800.GZ27840@beekeeper.hobix.com> <1207844408-sup-1739@south> Message-ID: <1207862027-sup-9449@ausone.local> Excerpts from William Morgan's message of Thu Apr 10 18:20:32 +0200 2008: > Reformatted excerpts from _why's message of 2008-04-07: > > Ditz.on_archive do |project, config, release| > > release.issues_from(project). > > each { |issue| project.drop_issue issue } > > end > > > > Ditz.after_add do |project, config, issue| > > `git add bugs/#{ISSUE_TO_FN(issue)}` > > end > > Hookability is definitely in the plans. Why not reuse the hookmanager module of sup? I could perhaps give it a try tomorrow. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080410/d03a71e1/attachment.bin From wmorgan-ditz at masanjin.net Thu Apr 10 18:14:11 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Thu, 10 Apr 2008 15:14:11 -0700 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. In-Reply-To: <1207862027-sup-9449@ausone.local> References: <20080407200849.GY27840@beekeeper.hobix.com> <1207607828-sup-3995@south> <20080407233800.GZ27840@beekeeper.hobix.com> <1207844408-sup-1739@south> <1207862027-sup-9449@ausone.local> Message-ID: <1207865428-sup-606@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-10: > Why not reuse the hookmanager module of sup? I could perhaps give it a > try tomorrow. It sounds plausible. Heck, I've often thought of pulling that out and making it a library of its own. I don't know if there's really enough code in there to make that worthwhile, but there might be. -- William From its.jeff.balogh at gmail.com Fri Apr 11 01:06:12 2008 From: its.jeff.balogh at gmail.com (Jeff Balogh) Date: Fri, 11 Apr 2008 01:06:12 -0400 Subject: [ditz-talk] [PATCH] `ditz init` was trying to save the bugs dir, should be bugs/project.yaml Message-ID: <1207890302-sup-1678@archie> --- bin/ditz | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/bin/ditz b/bin/ditz index ee52b15..c82f106 100755 --- a/bin/ditz +++ b/bin/ditz @@ -24,8 +24,9 @@ case cmd # some special cases not handled by Ditz::Operator when "init" die "#{dir} directory already exists" if File.exists? dir FileUtils.mkdir dir + fn = File.join dir, PROJECT_FN project = op.init - project.save! dir + project.save! fn puts "Ok, #{dir} directory created successfully." exit when "help" -- 1.5.5 From its.jeff.balogh at gmail.com Fri Apr 11 02:27:15 2008 From: its.jeff.balogh at gmail.com (Jeff Balogh) Date: Fri, 11 Apr 2008 02:27:15 -0400 Subject: [ditz-talk] [PATCH] catch keyboard interrupt so it doesn't print a traceback Message-ID: <1207895184-sup-5873@archie> --- I prefer not to see 15 lines of traceback when I ctrl-c ditz, though I'd be fine with something short like 'caught signal'. This patch lets ditz make a quiet exit. bin/ditz | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/bin/ditz b/bin/ditz index ee52b15..729dc46 100755 --- a/bin/ditz +++ b/bin/ditz @@ -82,6 +82,8 @@ begin op.do cmd, project, config, args rescue Ditz::Operator::Error => e die e.message +rescue Interrupt + exit 1 end ## save project.yaml -- 1.5.5 From its.jeff.balogh at gmail.com Fri Apr 11 02:33:32 2008 From: its.jeff.balogh at gmail.com (Jeff Balogh) Date: Fri, 11 Apr 2008 02:33:32 -0400 Subject: [ditz-talk] [PATCH] Add support shell completion (zsh for now). In-Reply-To: <1207785317-93954-1-git-send-email-nicolas.pouillard@gmail.com> References: <1207785317-93954-1-git-send-email-nicolas.pouillard@gmail.com> Message-ID: <1207895514-sup-4028@archie> Nicolas Pouillard wrote: > Note: patch pushed on my repo-clone as well. > > --- > bin/ditz | 14 +++++++++++++- > contrib/completion/_ditz.zsh | 29 +++++++++++++++++++++++++++++ > lib/operator.rb | 15 ++++++++++++++- > 3 files changed, 56 insertions(+), 2 deletions(-) > create mode 100644 contrib/completion/_ditz.zsh > > diff --git a/bin/ditz b/bin/ditz > index 0b042df..4b85d0a 100755 > --- a/bin/ditz > +++ b/bin/ditz > @@ -1,5 +1,18 @@ > #!/usr/bin/env ruby > > +# requires are splitted in two for efficiency reasons > +# ditz should be really fast when using it for > +# completion. > +require 'operator' > + > +op = Ditz::Operator.new > + > +# a secret option for shell completion > +if ARGV.include? '--commands' > + puts op.class.operations.map { |name, _| name } > + exit 0 > +end > + > require 'rubygems' > require 'fileutils' > require 'trollop'; include Trollop > @@ -17,7 +30,6 @@ $opts = options do > end > > cmd = ARGV.shift or die "expecting a ditz command" > -op = Ditz::Operator.new > dir = $opts[:issue_dir] > > case cmd # some special cases not handled by Ditz::Operator > diff --git a/contrib/completion/_ditz.zsh b/contrib/completion/_ditz.zsh > new file mode 100644 > index 0000000..656860f > --- /dev/null > +++ b/contrib/completion/_ditz.zsh > @@ -0,0 +1,29 @@ > +#compdef ditz > + > +ME=ditz > +COMMANDS=--commands > +OPTIONS='' > + > +if (($CURRENT == 2)); then > + # We're completing the first word after the tool: the command. > + _wanted command expl "$ME command" \ > + compadd -- $( "$ME" "$COMMANDS" ) > +else > + # Find the options/files/URL/etc. for the current command by using the tool > itself. > + case "${words[$CURRENT]}"; in > + -*) > + _wanted args expl "Arguments for $ME ${words[2]}" \ > + compadd -- $( "$ME" "${words[2]}" "$OPTIONS" ; _files ) > + ;; > + ht*|ft*) > + _arguments '*:URL:_urls' > + ;; > + /*|./*|\~*|../*) > + _arguments '*:file:_files' > + ;; > + *) > + _wanted args expl "Arguments for $ME ${words[2]}" \ > + compadd -- $( "$ME" "${words[2]}" "$OPTIONS" ) > + ;; > + esac > +fi > diff --git a/lib/operator.rb b/lib/operator.rb > index 74c9507..74ce0b0 100644 > --- a/lib/operator.rb > +++ b/lib/operator.rb > @@ -59,10 +59,12 @@ class Operator > command = "command '#{method_to_op method}'" > built_args = @operations[method][:args_spec].map do |spec| > val = args.shift > + generate_choices(project, method, spec) if val == '' > case spec > when :issue > raise Error, "#{command} requires an issue name" unless val > - project.issue_for(val) or raise Error, "no issue with name #{val}" > + valr = val.sub(/\A(\w+-\d+)_.*$/,'\1') > + project.issue_for(valr) or raise Error, "no issue with name #{val}" > when :release > raise Error, "#{command} requires a release name" unless val > project.release_for(val) or raise Error, "no release with name > #{val}" > @@ -75,9 +77,20 @@ class Operator > val # no translation for other types > end > end > + generate_choices(project, method, nil) if args.include? '' > raise Error, "too many arguments for #{command}" unless args.empty? > built_args > end > + > + def generate_choices project, method, spec > + case spec > + when :issue > + puts project.issues.map { |i| "#{i.name}_#{i.title.gsub(/\W+/, '-')}" } > + when :release, :maybe_release > + puts project.releases.map { |r| r.name } > + end > + exit 0 > + end > end > > def do op, project, config, args This is *very* useful. Thanks! From wmorgan-ditz at masanjin.net Fri Apr 11 12:28:55 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 09:28:55 -0700 Subject: [ditz-talk] another alternative Message-ID: <1207931320-sup-2011@south> dtt: http://gitorious.org/projects/dtt. Like tracgit, is git-specific. -- William From wmorgan-ditz at masanjin.net Fri Apr 11 12:34:37 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 09:34:37 -0700 Subject: [ditz-talk] [PATCH] `ditz init` was trying to save the bugs dir, should be bugs/project.yaml In-Reply-To: <1207890302-sup-1678@archie> References: <1207890302-sup-1678@archie> Message-ID: <1207931603-sup-4393@south> Applied, thanks. -- William From wmorgan-ditz at masanjin.net Fri Apr 11 12:35:41 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 09:35:41 -0700 Subject: [ditz-talk] [PATCH] catch keyboard interrupt so it doesn't print a traceback In-Reply-To: <1207895184-sup-5873@archie> References: <1207895184-sup-5873@archie> Message-ID: <1207931723-sup-5518@south> Applied, thanks. -- William From nicolas.pouillard at gmail.com Fri Apr 11 12:43:46 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri, 11 Apr 2008 18:43:46 +0200 Subject: [ditz-talk] another alternative In-Reply-To: <1207931320-sup-2011@south> References: <1207931320-sup-2011@south> Message-ID: <1207932187-sup-9629@ausone.local> Excerpts from William Morgan's message of Fri Apr 11 18:28:55 +0200 2008: > dtt: http://gitorious.org/projects/dtt. Like tracgit, is git-specific. He started 4 days ago, perhaps one should just inform him? -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080411/d8142057/attachment.bin From wmorgan-ditz at masanjin.net Fri Apr 11 12:43:44 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 09:43:44 -0700 Subject: [ditz-talk] [Gitorious] ertai has requested a merge in ditz In-Reply-To: <1207861345-sup-1511@ausone.local> References: <47fcfba23957a_70d015ae47b26f003f@octimal.tmail> <1207848428-sup-2354@south> <1207861345-sup-1511@ausone.local> Message-ID: <1207932164-sup-816@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-10: > Excerpts from William Morgan's message of Thu Apr 10 19:28:23 +0200 2008: > > Out of curiousity, how are you getting nil descriptions? > > Hum... I can't reproduce it, but it was some very basic usage. I've > added a bunch of issues, most of them without description or > comments, and then done a "ditz show ...", and got this error. I will > run without the fix for a while in order to see it again. It should "never happen" but I've applied the patch anyways. -- William From nicolas.pouillard at gmail.com Fri Apr 11 12:50:52 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri, 11 Apr 2008 18:50:52 +0200 Subject: [ditz-talk] [PATCH] added 'prune' command to drop all tickets for a release. In-Reply-To: <1207865428-sup-606@south> References: <20080407200849.GY27840@beekeeper.hobix.com> <1207607828-sup-3995@south> <20080407233800.GZ27840@beekeeper.hobix.com> <1207844408-sup-1739@south> <1207862027-sup-9449@ausone.local> <1207865428-sup-606@south> Message-ID: <1207932354-sup-8002@ausone.local> Excerpts from William Morgan's message of Fri Apr 11 00:14:11 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-10: > > Why not reuse the hookmanager module of sup? I could perhaps give it a > > try tomorrow. > > It sounds plausible. I've something working but slightly different, in fact it's more like in the Why's example. All hooks are in one file that is "load"ed. I do some more tests and I submit a patch. > Heck, I've often thought of pulling that out and making it a library of > its own. I don't know if there's really enough code in there to make > that worthwhile, but there might be. I think it's too short to deserve a separated distribution. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080411/882260e5/attachment.bin From wmorgan-ditz at masanjin.net Fri Apr 11 13:03:40 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 10:03:40 -0700 Subject: [ditz-talk] another alternative Message-ID: <1207933397-sup-4275@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-11: > Excerpts from William Morgan's message of Fri Apr 11 18:28:55 +0200 2008: > > dtt: http://gitorious.org/projects/dtt. Like tracgit, is git-specific. > > He started 4 days ago, perhaps one should just inform him? There are comments on his Gitorious page about ditz, so he knows about it. Whatever, maybe he just wants a more git-specific thing. -- William From wmorgan-ditz at masanjin.net Fri Apr 11 13:09:07 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 10:09:07 -0700 Subject: [ditz-talk] [ANN] ditz 0.2 Released Message-ID: <1207933716-sup-1923@south> ditz version 0.2 has been released! * Ditz is a simple, light-weight distributed issue tracker designed to work with distributed version control systems like darcs and git. Ditz maintains an issue database directory on disk, with files written in a line-based and human- editable format. This directory is kept under version control alongside project code. Changes in issue state is handled by version control like code change: included as part of a commit, merged with changes from other developers, conflict-resolved in the standard manner, etc. Ditz provides a simple, console-based interface for creating and updating the issue database files, and some rudimentary HTML generation capabilities for producing world-readable status pages. It offers no central public method of bug submission. Release notes: In ditz 0.2, we store issues per file. This avoids many unnecessary conflicts that occur in the single-file case. To upgrade your bugs.yaml to a bugs/ directory, you must run ditz-convert-from-monolith. Synopsis: # set up project. creates the bugs.yaml file. 1. ditz init 2. ditz add-release # add an issue 3. ditz add # where am i? 4. ditz status 5. ditz todo # do work 6. write code 7. ditz close 8. commit 9. goto 3 # finished! 10. ditz release Changes: ## 0.2 / 2008-04-11 * bugfix: store each issue in a separate file to avoid false conflicts * added per-command help * added 'log' command for recent activity * added better exception handling---turn into pretty error messages * added text-area commands like /edit, /reset, etc * all times now stored in UTC ## 0.1.2 / 2008-04-04 * bugfix: add_reference very broken ## 0.1.1 / 2008-04-04 * bugfix: bugfix/feature question always returns feature ## 0.1 / 2008-04-02 * Initial release! * -- William From wmorgan-ditz at masanjin.net Fri Apr 11 15:30:13 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 12:30:13 -0700 Subject: [ditz-talk] a modest proposal for collaboration Message-ID: <1207942127-sup-6882@south> Here's an experiment I'd like to try for how to collaborate on ditz. I think this will make adding your code to ditz easier and quicker, and it will put me in more of a maintainership role. (Which is good because I need to get back to working on Sup!) I'm going to make an 'edge' branch. It will be like the 'next' branch in Sup, except with a better name. If you track it, you will get all the latest and greatest features, at the risk of encountering some brokenness. The master branch will be like the master branch in Sup: it will consist of stable features that will be included in the next release. If you track it, you "should" never encounter bugs. Trivial changes I will accept via email as usual and will merge as appropriate. For non-trivial changes (i.e. things that require more than one commit, or things that have a non-zero probability of needing further refinement), here's what I ask: - Publish a "feature branch" with a descriptive name on your Gitorious repo, containing just the commits for that feature. - Every time you make some changes that you want added to edge, make a merge request. - When you make bugfixes or modifications of that feature, make them to that branch, and make another merge request. In return, here's what I promise: - I will apply merge requests to edge with little to no review, as soon as I receive it. Getting code into edge should be fast and easy. - If I have a change I'd like to make to a feature that you maintain, I will send YOU a patch. (Or, if it's non-trivial, I'll publish a branch and send you a merge request.) - I will maintain a 'bugs' branch with the current state of everything (using ditz, of course), and update the website with the report, etc. - I will maintain the master and edge branches, merging feature branches down to master once they seem stable. - I will build and publish releases as appropriate. So, for example, I would love to see a 'hook' branch, a 'tasks' branch, a 'shell-completion' branch out there that I can merge. Comments? Suggestions? -- William From wmorgan-ditz at masanjin.net Fri Apr 11 16:11:06 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Fri, 11 Apr 2008 13:11:06 -0700 Subject: [ditz-talk] a modest proposal for collaboration In-Reply-To: <1207942127-sup-6882@south> References: <1207942127-sup-6882@south> Message-ID: <1207944371-sup-3728@south> Addendum: to create a remote branch, speak this arcane spell: git push origin master:refs/heads/ git branch --track origin/ To delete a remote branch, speak this arcane spell: git push origin :refs/heads/ git branch -d -- William From cyberlync at gmail.com Sat Apr 12 02:36:51 2008 From: cyberlync at gmail.com (Eric Merritt) Date: Fri, 11 Apr 2008 23:36:51 -0700 Subject: [ditz-talk] [PATCH] support searching up directory structure for root Message-ID: <1207982211-6737-1-git-send-email-cyberlync@gmail.com> This patch adds support for search up the directory structure for the bugs directory. In actually it looks up the directory structure for a /projects.yaml structure. When it finds that it uses that as the project root. This change has been enacted in every command except init. --- bin/ditz | 22 +++++++++++++--------- lib/ditz.rb | 18 ++++++++++++++++++ 2 files changed, 31 insertions(+), 9 deletions(-) diff --git a/bin/ditz b/bin/ditz index ee52b15..7859e45 100755 --- a/bin/ditz +++ b/bin/ditz @@ -24,8 +24,9 @@ case cmd # some special cases not handled by Ditz::Operator when "init" die "#{dir} directory already exists" if File.exists? dir FileUtils.mkdir dir + fn = File.join dir, PROJECT_FN project = op.init - project.save! dir + project.save! fn puts "Ok, #{dir} directory created successfully." exit when "help" @@ -33,14 +34,17 @@ when "help" exit end -die "No #{dir} directory---use 'ditz init' to initialize" unless File.exists? dir +project_root = Ditz::find_project_root dir, Dir.pwd + +die "No #{dir} directory---use 'ditz init' to initialize" unless project_root != nil and File.exists? project_root + project = begin - fn = File.join dir, PROJECT_FN + fn = File.join project_root, PROJECT_FN Ditz::debug "loading project from #{fn}" project = Ditz::Project.from fn - fn = File.join dir, "issue-*.yaml" + fn = File.join project_root, "issue-*.yaml" Ditz::debug "loading issues from #{fn}" project.issues = Dir[fn].map { |fn| Ditz::Issue.from fn } Ditz::debug "found #{project.issues.size} issues" @@ -87,7 +91,7 @@ end ## save project.yaml dirty = project.each_modelobject { |o| break true if o.changed? } || false if dirty - fn = File.join dir, PROJECT_FN + fn = File.join project_root, PROJECT_FN Ditz::debug "project is dirty, saving #{fn}" project.each_modelobject { |o| o.before_serialize project } project.save! fn @@ -98,26 +102,26 @@ end project.issues.each do |i| if i.changed? i.before_serialize project - fn = File.join dir, ISSUE_TO_FN(i) + fn = File.join project_root, ISSUE_TO_FN(i) Ditz::debug "issue #{i.name} is dirty, saving #{fn}" i.save! fn end end project.deleted_issues.each do |i| - fn = File.join dir, ISSUE_TO_FN(i) + fn = File.join project_root, ISSUE_TO_FN(i) Ditz::debug "issue #{i.name} has been deleted, deleting #{fn}" FileUtils.rm fn end unless project.added_issues.empty? puts "You may have to inform your SCM that the following files have been added:" - project.added_issues.each { |i| puts " " + File.join(dir, ISSUE_TO_FN(i)) } + project.added_issues.each { |i| puts " " + File.join(project_root, ISSUE_TO_FN(i)) } end unless project.deleted_issues.empty? puts "You may have to inform your SCM that the following files have been deleted:" - project.deleted_issues.each { |i| puts " " + File.join(dir, ISSUE_TO_FN(i)) } + project.deleted_issues.each { |i| puts " " + File.join(project_root, ISSUE_TO_FN(i)) } end config.save! $opts[:config_file] if config.changed? diff --git a/lib/ditz.rb b/lib/ditz.rb index 7cab4a6..f3a6a30 100644 --- a/lib/ditz.rb +++ b/lib/ditz.rb @@ -1,3 +1,4 @@ +require 'pathname' module Ditz VERSION = "0.1.2" @@ -7,6 +8,23 @@ def debug s end module_function :debug + +def find_project_root(dir, pwd) + p = Pathname.new pwd + np = p.join dir, "project.yaml" + if np.exist? + return np.dirname + else + if p.dirname != p + find_project_root dir, p.dirname + else + return nil + end + end +end + +module_function :find_project_root + end require 'model-objects' -- 1.5.4.4 From kentarok at gmail.com Sat Apr 12 11:11:15 2008 From: kentarok at gmail.com (Kentaro Kuribayashi) Date: Sun, 13 Apr 2008 00:11:15 +0900 Subject: [ditz-talk] Emacs interface to Ditz Message-ID: Hi, Ditz is very interesting. However I'm an Emacs lover, I want to use it from Emacs, so I wrote an Emacs interface to Ditz. http://github.com/kentaro/emacs-ditz/tree/master Please give me some feedback if you like it. I've not known about Ditz well, so I may miss some commands to be implemented in my elisp. It seems `ditz edit' command always runs $EDITOR. Which is why, ditz.el can't work with the command in Emacs. I guess the command should check tty or other place. -- Kentaro Kuribayashi http://kentarok.org/ From wmorgan-ditz at masanjin.net Sat Apr 12 21:06:28 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 12 Apr 2008 18:06:28 -0700 Subject: [ditz-talk] Emacs interface to Ditz In-Reply-To: References: Message-ID: <1208048584-sup-3769@south> Reformatted excerpts from Kentaro Kuribayashi's message of 2008-04-12: > Ditz is very interesting. However I'm an Emacs lover, I want to use it > from Emacs, so I wrote an Emacs interface to Ditz. > > http://github.com/kentaro/emacs-ditz/tree/master > > Please give me some feedback if you like it. I'm not an Emacs user, but it seems great. Thanks! > It seems `ditz edit' command always runs $EDITOR. Which is why, > ditz.el can't work with the command in Emacs. I guess the command > should check tty or other place. I'm happy to try to make this work for you, but I don't quite understand what you need. What should ditz do when it detects that it's being called from within Emacs? -- William From wmorgan-ditz at masanjin.net Sat Apr 12 21:10:49 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 12 Apr 2008 18:10:49 -0700 Subject: [ditz-talk] [PATCH] support searching up directory structure for root In-Reply-To: <1207982211-6737-1-git-send-email-cyberlync@gmail.com> References: <1207982211-6737-1-git-send-email-cyberlync@gmail.com> Message-ID: <1208048825-sup-4724@south> Reformatted excerpts from Eric Merritt's message of 2008-04-11: > This patch adds support for search up the directory structure for the > bugs directory. In actually it looks up the directory structure for a > /projects.yaml structure. When it finds that it uses that as > the project root. This change has been enacted in every command except > init. Thanks for the patch. However, if the point is to allow renaming the "bugs" directory without having to specify -i every time, I think this is a better approach: http://ditz.rubyforge.org/ditz/issue-10fed072ce82c9920cd960377a74b8084997ffee.html Would that give you what you needed? -- William From cyberlync at gmail.com Sat Apr 12 21:22:09 2008 From: cyberlync at gmail.com (Eric Merritt) Date: Sat, 12 Apr 2008 18:22:09 -0700 Subject: [ditz-talk] [PATCH] support searching up directory structure for root In-Reply-To: <1208048825-sup-4724@south> References: <1207982211-6737-1-git-send-email-cyberlync@gmail.com> <1208048825-sup-4724@south> Message-ID: No thats not the point at all. The point is to allow me to run the ditz command in subdirectories of a project. It searches up the tree to find the correct bugs dir. I don't do a lot of ruby coding so that may not have been clear. On Sat, Apr 12, 2008 at 6:10 PM, William Morgan wrote: > Reformatted excerpts from Eric Merritt's message of 2008-04-11: > > > This patch adds support for search up the directory structure for the > > bugs directory. In actually it looks up the directory structure for a > > /projects.yaml structure. When it finds that it uses that as > > the project root. This change has been enacted in every command except > > init. > > Thanks for the patch. However, if the point is to allow renaming the > "bugs" directory without having to specify -i every time, I think this > is a better approach: > > http://ditz.rubyforge.org/ditz/issue-10fed072ce82c9920cd960377a74b8084997ffee.html > > Would that give you what you needed? > > -- > William > _______________________________________________ > ditz-talk mailing list > ditz-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/ditz-talk > From kentarok at gmail.com Sat Apr 12 21:52:54 2008 From: kentarok at gmail.com (Kentaro Kuribayashi) Date: Sun, 13 Apr 2008 10:52:54 +0900 Subject: [ditz-talk] Emacs interface to Ditz In-Reply-To: <1208048584-sup-3769@south> References: <1208048584-sup-3769@south> Message-ID: Thank you for your reply! > I'm happy to try to make this work for you, but I don't quite understand > what you need. What should ditz do when it detects that it's being > called from within Emacs? For example, `ditz add' command provides line-based editing functionality first, then if user performes `/edit' command to edit description, ditz run $EDITOR. (Is my recognithion right?) Otherwise, `ditz edit' command runs $EDITOR immediately without user's performing `/edit' command. It's good if you're in tty, but you'll see an error message like below in Emacs: *ERROR*: Terminal type "dumb" is not powerful enough to run Emacs Incidentally, my $EDITOR variable is bound to `emacsclient'. I don't have precise idea to improve this problem. I guess it may work well if `ditz edit' command check itself being called whether in tty or other place like in Emacs. -- Kentaro Kuribayashi kentarok at gmail.com http://kentarok.org/ From wmorgan-ditz at masanjin.net Sat Apr 12 22:22:33 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 12 Apr 2008 19:22:33 -0700 Subject: [ditz-talk] [PATCH] support searching up directory structure for root In-Reply-To: References: <1207982211-6737-1-git-send-email-cyberlync@gmail.com> <1208048825-sup-4724@south> Message-ID: <1208053326-sup-8130@south> Reformatted excerpts from Eric Merritt's message of 2008-04-12: > No thats not the point at all. The point is to allow me to run the > ditz command in subdirectories of a project. It searches up the tree > to find the correct bugs dir. Got it. Applied to the edge branch. Thanks! -- William From wmorgan-ditz at masanjin.net Sat Apr 12 22:49:01 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 12 Apr 2008 19:49:01 -0700 Subject: [ditz-talk] Emacs interface to Ditz In-Reply-To: References: <1208048584-sup-3769@south> Message-ID: <1208054342-sup-9498@south> Reformatted excerpts from Kentaro Kuribayashi's message of 2008-04-12: > For example, `ditz add' command provides line-based editing > functionality first, then if user performes `/edit' command to edit > description, ditz run $EDITOR. (Is my recognithion right?) Yes. > Otherwise, `ditz edit' command runs $EDITOR immediately without user's > performing `/edit' command. It's good if you're in tty, but you'll see > an error message like below in Emacs: > > *ERROR*: Terminal type "dumb" is not powerful enough to run Emacs > > Incidentally, my $EDITOR variable is bound to `emacsclient'. Hm. When I run ditz through emacs, everything works fine. I do: M-x server-start and M-x shell. Within shell-mode, TERM is "dumb" and EDITOR is "vim". If I set EDITOR to emacsclient, then ditz edit and using "/edit" both do the right thing---load the file into another Emacs buffer, and C-x # sends the data back to ditz. So somehow I suspect that EDITOR isn't being set to emacsclient when you're calling ditz from within emacs. Is there any chance that it's being set to just "emacs" somehow? You can try this patch to find out: --- a/lib/lowline.rb +++ b/lib/lowline.rb @@ -63,6 +63,9 @@ module Lowline cmd = "#{editor} #{f.path.inspect}" mtime = File.mtime f.path + puts "TERM IS #{ENV["TERM"].inspect}" + puts "EDITOR IS #{ENV["EDITOR"].inspect}" + puts "running: #{cmd}" system cmd or raise Error, "cannot execute command: #{cmd.inspect}" File.mtime(f.path) == mtime ? nil : f.path -- William From kentarok at gmail.com Sun Apr 13 00:00:26 2008 From: kentarok at gmail.com (Kentaro Kuribayashi) Date: Sun, 13 Apr 2008 13:00:26 +0900 Subject: [ditz-talk] Emacs interface to Ditz In-Reply-To: <1208054342-sup-9498@south> References: <1208048584-sup-3769@south> <1208054342-sup-9498@south> Message-ID: Hi, > So somehow I suspect that EDITOR isn't being set to emacsclient when > you're calling ditz from within emacs. Is there any chance that it's > being set to just "emacs" somehow? I applied the new patched ditz and got messages below: TERM IS "dumb" EDITOR IS "emacsclient -t" running: emacsclient -t "/tmp/ditz.21554.0" *ERROR*: Terminal type "dumb" is not powerful enough to run Emacs Oh, I set $EDITOR variable to "emacsclient -t" not just "emacsclient"... After changing it to just "emacsclient", ditz edit started to work well in Emacs. Sorry for my mistake. The "-t" option runs emacsclient enabling multi-tty feature in CVS HEAD of Emacs, and I can't live without it at all. Anyways, I'll set the value just "emaclient" only in Emacs. Thank you! -- Kentaro Kuribayashi kentarok at gmail.com http://kentarok.org/ From yesmar at speakeasy.net Sun Apr 13 01:54:51 2008 From: yesmar at speakeasy.net (Ramsey Dow) Date: Sat, 12 Apr 2008 22:54:51 -0700 Subject: [ditz-talk] [PATCH] added GNU/Readline support Message-ID: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> ditz is great, but I've got fat fingers and make a lot of typos. GNU Readline comes with Ruby, so adding Readline support to ditz is a simple matter of programming. Now when I make mistakes I can edit them right there without having to use /edit. :) yesmar p.s. this patch should be applied to mainline --- lib/lowline.rb | 29 ++++++++++++++++++----------- 1 files changed, 18 insertions(+), 11 deletions(-) diff --git a/lib/lowline.rb b/lib/lowline.rb index 50836bc..966a1c2 100644 --- a/lib/lowline.rb +++ b/lib/lowline.rb @@ -1,3 +1,4 @@ +require 'readline' require 'tempfile' require "util" @@ -82,8 +83,8 @@ module Lowline end while true - print [q, default_s, tail].compact.join - ans = gets.strip + prompt = [q, default_s, tail].compact.join + ans = Readline::readline(prompt) if opts[:default] ans = opts[:default] if ans.blank? else @@ -109,16 +110,22 @@ module Lowline puts "#{q} (ctrl-d, ., or /stop to stop, /edit to edit, /reset to reset):" ans = "" while true - print "> " - case(line = gets) && line.strip! - when /^\.$/, nil, "/stop" - break - when "/reset" - return ask_multiline(q) - when "/edit" - return ask_via_editor(q, ans) + line = Readline::readline('> ') + if line + Readline::HISTORY.push(line) + case line + when /^\.$/, "/stop" + break + when "/reset" + return ask_multiline(q) + when "/edit" + return ask_via_editor(q, ans) + else + ans << line + "\n" + end else - ans << line + "\n" + puts + break end end ans.multistrip -- 1.5.4.4 From nicolas.pouillard at gmail.com Sun Apr 13 08:56:14 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 13 Apr 2008 14:56:14 +0200 Subject: [ditz-talk] a modest proposal for collaboration In-Reply-To: <1207942127-sup-6882@south> References: <1207942127-sup-6882@south> Message-ID: <1208091105-sup-4174@ausone.local> Excerpts from William Morgan's message of Fri Apr 11 21:30:13 +0200 2008: > Here's an experiment I'd like to try for how to collaborate on ditz. I > think this will make adding your code to ditz easier and quicker, and it > will put me in more of a maintainership role. (Which is good because I > need to get back to working on Sup!) > > I'm going to make an 'edge' branch. It will be like the 'next' branch in > Sup, except with a better name. If you track it, you will get all the > latest and greatest features, at the risk of encountering some > brokenness. > > The master branch will be like the master branch in Sup: it will consist > of stable features that will be included in the next release. If you > track it, you "should" never encounter bugs. > > Trivial changes I will accept via email as usual and will merge as > appropriate. > > For non-trivial changes (i.e. things that require more than one commit, > or things that have a non-zero probability of needing further > refinement), here's what I ask: > > - Publish a "feature branch" with a descriptive name on your Gitorious > repo, containing just the commits for that feature. > > - Every time you make some changes that you want added to edge, make a > merge request. > > - When you make bugfixes or modifications of that feature, make them > to that branch, and make another merge request. > > In return, here's what I promise: > > - I will apply merge requests to edge with little to no review, as > soon as I receive it. Getting code into edge should be fast and > easy. > > - If I have a change I'd like to make to a feature that you maintain, > I will send YOU a patch. (Or, if it's non-trivial, I'll publish a > branch and send you a merge request.) > > - I will maintain a 'bugs' branch with the current state of everything > (using ditz, of course), and update the website with the report, > etc. > > - I will maintain the master and edge branches, merging feature > branches down to master once they seem stable. > > - I will build and publish releases as appropriate. > > So, for example, I would love to see a 'hook' branch, a 'tasks' branch, > a 'shell-completion' branch out there that I can merge. > > Comments? Suggestions? That's very good plan! -- Even if it took me a lot more time to setup all these branches that effectively writing the code :( I've made these three branches and request for merges. Cheers, PS: thanks for these git incantations, it was a really good start -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080413/3d62a502/attachment.bin From wmorgan-ditz at masanjin.net Sun Apr 13 13:42:30 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 13 Apr 2008 10:42:30 -0700 Subject: [ditz-talk] Emacs interface to Ditz In-Reply-To: References: <1208048584-sup-3769@south> <1208054342-sup-9498@south> Message-ID: <1208108126-sup-5803@south> Reformatted excerpts from Kentaro Kuribayashi's message of 2008-04-12: > The "-t" option runs emacsclient enabling multi-tty feature in CVS > HEAD of Emacs, and I can't live without it at all. Anyways, I'll set > the value just "emaclient" only in Emacs. I think this is the right idea. In fact, I would forcibly overwrite the user's $EDITOR variable when calling ditz from within emacs, no matter what it was originally. I.e, even if my $EDITOR is vim, if I use ditz from within Emacs, it should use emacsclient to let me edit stuff in an Emacs buffer. -- William From wmorgan-ditz at masanjin.net Sun Apr 13 17:09:12 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 13 Apr 2008 14:09:12 -0700 Subject: [ditz-talk] [PATCH] added GNU/Readline support In-Reply-To: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> References: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> Message-ID: <1208120771-sup-3464@south> Reformatted excerpts from Ramsey Dow's message of 2008-04-12: > ditz is great, but I've got fat fingers and make a lot of typos. GNU > Readline comes with Ruby, so adding Readline support to ditz is a > simple matter of programming. Now when I make mistakes I can edit them > right there without having to use /edit. :) Sounds great. Thanks! I've created a topic branch for this and merged it into edge. If you're going to make further contributions, please publish them as topic branches against master. -- William From wmorgan-ditz at masanjin.net Sun Apr 13 17:55:21 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 13 Apr 2008 14:55:21 -0700 Subject: [ditz-talk] a modest proposal for collaboration In-Reply-To: <1208091105-sup-4174@ausone.local> References: <1207942127-sup-6882@south> <1208091105-sup-4174@ausone.local> Message-ID: <1208120986-sup-9834@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-13: > That's very good plan! -- Even if it took me a lot more time to setup > all these branches that effectively writing the code :( Sorry! I think that I'll create topic branches for people the first time, but ask that subsequent changes be published on branches from master. I don't want to set the bar too high. > I've made these three branches and request for merges. Thanks! Tasks and shell-completion have been merged into edge. The hooks branch contains some commits that are not hook-related (the bugs/*.yaml changes, the prettification change, and the final merge against edge that the prettification change requires because of the recursive directory stuff.) The entire bugs directory has been moved to the "bugs" branch, so that's a delete+modify conflict, which is easy enough for me to resolve. :) But the final commit in the branch (the merge) means I won't be able to apply the hooks changes to master without applying the recursive directory search changes as well. Should I apply anyways? I don't want to be overly strict about this type of thing. You tell me. -- William From wmorgan-ditz at masanjin.net Sun Apr 13 21:48:12 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 13 Apr 2008 18:48:12 -0700 Subject: [ditz-talk] [PATCH] added GNU/Readline support In-Reply-To: <04D4C03F-A150-45D4-9FB4-CD25C42D96C8@speakeasy.net> References: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> <1208120771-sup-3464@south> <04D4C03F-A150-45D4-9FB4-CD25C42D96C8@speakeasy.net> Message-ID: <1208136300-sup-4806@south> [Sending to ditz-talk because I think others might find this useful too] Reformatted excerpts from Ramsey Dow's message of 2008-04-13: > How do I do this? I cloned the ditz master branch on Gitorious, but > there are no other branches listed. How do I track edge without > deleting & recloning? Ok, strap on your seatbelt for a Git crash course. There are three repos involved: the mainline repo on Gitorious, your Gitorious clone, and your local repo on disk. What you want (trust me for now) is to be able to pull down changes from the master and edge branches of the mainline repo to your local repo, make changes locally, and then push those changes to a new branch on your Gitorious clone. Then I'll merge that branch into edge, and you'll see them when you next pull down changes from edge. The miracle of distributed SCM is that the above scenario actually works. (It's actually even more complicated than that, because I have a local repo on disk where I'm making all the changes before pushing them to the Gitorious mainline repo. But forget about that for now!) So here's what you need to do. First, tell your local repo about the mainline repo. $ git remote add mainline git://gitorious.org/ditz/mainline.git Now git knows about a remote repo called mainline. Your repo, incidentally, is called origin. The next step is to get the remote branches: $ git remote update Updating mainline From git://gitorious.org/ditz/mainline * [new branch] bugs -> mainline/bugs * [new branch] cyberlync-recurse-dirs -> mainline/cyberlync-recurse-dirs * [new branch] edge -> mainline/edge * [new branch] master -> mainline/master * [new branch] yesmar-readline -> mainline/yesmar-readline Updating origin Ok, now you have references to all the current branches in the mainline repo. Now we'll make local branches to track these ones we're interested in: $ git branch --track mainline-master mainline/master Branch mainline-master set up to track remote branch refs/remotes/mainline/master. $ git branch --track mainline-edge mainline/edge Branch mainline-edge set up to track remote branch refs/remotes/mainline/edge. At this point the mainline-edge branch on your local machine tracks the mainline edge branch, so if you git pull while it's checked out, you'll get the latest and greatest features. Finally, let's make some changes. We'll make a feature branch against mainline's master. $ git checkout -b my-awesome-feature mainline-master Switched to a new branch "my-awesome-feature" $ ... work work work ... $ git commit Ok, time to publish: $ git publish-branch my-awesome-feature The last is a little utility I wrote. The actual git commands to do this are bizarre and obscure. It's here: http://git-wt-commit.rubyforge.org/git-publish-branch And that's "all" there is to it. Implicit in the above is that your Gitorious clone is not updated in any way except when you manually update it. It starts with the set of branches that were available when it was cloned, but that (and the code itself) quickly gets out of sync. It's a place for you to push your changes to, and nothing more. Hope that helps! -- William From yesmar at speakeasy.net Mon Apr 14 02:47:05 2008 From: yesmar at speakeasy.net (yesmar) Date: Sun, 13 Apr 2008 23:47:05 -0700 Subject: [ditz-talk] GNU/Readline redux Message-ID: <4875FE80-2082-4EA9-8683-365E528AAF64@speakeasy.net> I created a second patch for GNU/Readline support in ditz. This one is published in the readline2 branch of the yesmar-clone of ditz: http://gitorious.org/projects/ditz/repos/yesmar-clone/logs/readline2 William, please merge into ditz edge when you get a chance. Description of change: Although GNU/Readline support is ostensibly included in all Ruby distributions (for use in irb) sometimes it may not be present. Two examples come to mind: (1) you roll your own Ruby and forget to include Readline into the mix, (2) you download a pre-compiled binary release that either has no Readline support or your library search path is messed up. Regardless, it would be a shame to get a stack trace when you run Ditz just because Readline isn't accessible. This patch moves the Readline require from lib/lowline.rb to the lib/ ditz.rb and traps the require. We set a class variable in the Ditz module to true if and only if Readline was successfully required. If Readline isn't present, Ditz falls back on the original text entry code. If, on the other hand, Readline was successfully required, you get GNU/Readline editing (with history and vi/emacs key bindings). From nicolas.pouillard at gmail.com Mon Apr 14 03:37:22 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 14 Apr 2008 09:37:22 +0200 Subject: [ditz-talk] [PATCH] added GNU/Readline support In-Reply-To: <1208136300-sup-4806@south> References: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> <1208120771-sup-3464@south> <04D4C03F-A150-45D4-9FB4-CD25C42D96C8@speakeasy.net> <1208136300-sup-4806@south> Message-ID: <1208158343-sup-2306@ausone.inria.fr> Excerpts from William Morgan's message of Mon Apr 14 03:48:12 +0200 2008: > [Sending to ditz-talk because I think others might find this useful too] > > Reformatted excerpts from Ramsey Dow's message of 2008-04-13: > > How do I do this? I cloned the ditz master branch on Gitorious, but > > there are no other branches listed. How do I track edge without > > deleting & recloning? > > Ok, strap on your seatbelt for a Git crash course. I'm starting to think that most of git lessons are kind of "crash course" :) > $ git remote update This command is a kind of grouped "git fetch", right? If so you have to merge by yourself, right? Then why not using "git pull"? [...] > $ git publish-branch my-awesome-feature > > The last is a little utility I wrote. The actual git commands to do this > are bizarre and obscure. It's here: > http://git-wt-commit.rubyforge.org/git-publish-branch Thanks for these tools! [...] > Implicit in the above is that your Gitorious clone is not updated in any > way except when you manually update it. It starts with the set of > branches that were available when it was cloned, but that (and the code > itself) quickly gets out of sync. It's a place for you to push your > changes to, and nothing more. I don't get why my Gitorious clone should/could/must not by updated and become out of sync? -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080414/d08cfc8c/attachment.bin From wmorgan-ditz at masanjin.net Mon Apr 14 11:19:04 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 14 Apr 2008 08:19:04 -0700 Subject: [ditz-talk] [PATCH] added GNU/Readline support In-Reply-To: <1208158343-sup-2306@ausone.inria.fr> References: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> <1208120771-sup-3464@south> <04D4C03F-A150-45D4-9FB4-CD25C42D96C8@speakeasy.net> <1208136300-sup-4806@south> <1208158343-sup-2306@ausone.inria.fr> Message-ID: <1208185201-sup-8092@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-14: > I'm starting to think that most of git lessons are kind of "crash > course" :) That's the beauty of it. Only the strong survive. > > $ git remote update > > This command is a kind of grouped "git fetch", right? Yes. > If so you have to merge by yourself, right? > > Then why not using "git pull"? It could be my lack of knowledge, but to me it seems like in order for git pull to work nicely, the branch needs to be set up to track the remote branch, and in order to get a reference to the remote branch, you need that initial fetch/update. > I don't get why my Gitorious clone should/could/must not by > updated and become out of sync? It's fine to keep it updated by hand if you want. My only point is that changes to the mainline repo don't get propagated to its clones automatically. So if you want to track edge, you can't just track origin/edge. -- William From nicolas.pouillard at gmail.com Mon Apr 14 16:15:34 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Mon, 14 Apr 2008 22:15:34 +0200 Subject: [ditz-talk] [PATCH] added GNU/Readline support In-Reply-To: <1208185201-sup-8092@south> References: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> <1208120771-sup-3464@south> <04D4C03F-A150-45D4-9FB4-CD25C42D96C8@speakeasy.net> <1208136300-sup-4806@south> <1208158343-sup-2306@ausone.inria.fr> <1208185201-sup-8092@south> Message-ID: <1208203886-sup-409@ausone.local> Excerpts from William Morgan's message of Mon Apr 14 17:19:04 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-14: > > I'm starting to think that most of git lessons are kind of "crash > > course" :) > > That's the beauty of it. Only the strong survive. Only strong users or only strong SCMs? > > > $ git remote update > > > > This command is a kind of grouped "git fetch", right? > > Yes. > > > If so you have to merge by yourself, right? > > > > Then why not using "git pull"? > > It could be my lack of knowledge, but to me it seems like in order for > git pull to work nicely, the branch needs to be set up to track the > remote branch, and in order to get a reference to the remote branch, you > need that initial fetch/update. Ok so that's just an initial step? > > I don't get why my Gitorious clone should/could/must not by > > updated and become out of sync? > > It's fine to keep it updated by hand if you want. My only point is that > changes to the mainline repo don't get propagated to its clones > automatically. So if you want to track edge, you can't just track > origin/edge. Right I've origin and mainline. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080414/80e6ae00/attachment.bin From wmorgan-ditz at masanjin.net Tue Apr 15 01:27:07 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 14 Apr 2008 22:27:07 -0700 Subject: [ditz-talk] GNU/Readline redux In-Reply-To: <4875FE80-2082-4EA9-8683-365E528AAF64@speakeasy.net> References: <4875FE80-2082-4EA9-8683-365E528AAF64@speakeasy.net> Message-ID: <1208237205-sup-2369@south> Reformatted excerpts from Ramsey Dow's message of 2008-04-13: > William, please merge into ditz edge when you get a chance. In, thanks! -- William From wmorgan-ditz at masanjin.net Tue Apr 15 01:28:53 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 14 Apr 2008 22:28:53 -0700 Subject: [ditz-talk] [PATCH] added GNU/Readline support In-Reply-To: <1208203886-sup-409@ausone.local> References: <6C5A6F9A-D907-47B6-9DA1-27E4B541F95B@speakeasy.net> <1208120771-sup-3464@south> <04D4C03F-A150-45D4-9FB4-CD25C42D96C8@speakeasy.net> <1208136300-sup-4806@south> <1208158343-sup-2306@ausone.inria.fr> <1208185201-sup-8092@south> <1208203886-sup-409@ausone.local> Message-ID: <1208237253-sup-8766@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-14: > Excerpts from William Morgan's message of Mon Apr 14 17:19:04 +0200 2008: > > It could be my lack of knowledge, but to me it seems like in order > > for git pull to work nicely, the branch needs to be set up to track > > the remote branch, and in order to get a reference to the remote > > branch, you need that initial fetch/update. > > Ok so that's just an initial step? Yep. Then git pull and git push should work without any arguments, and pull from/push to the right place. -- William From nicolas.pouillard at gmail.com Tue Apr 15 09:06:00 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 15 Apr 2008 15:06:00 +0200 Subject: [ditz-talk] a modest proposal for collaboration In-Reply-To: <1208120986-sup-9834@south> References: <1207942127-sup-6882@south> <1208091105-sup-4174@ausone.local> <1208120986-sup-9834@south> Message-ID: <1208264475-sup-6601@port-ext16.ensta.fr> Excerpts from William Morgan's message of Sun Apr 13 23:55:21 +0200 2008: > Reformatted excerpts from nicolas.pouillard's message of 2008-04-13: > > That's very good plan! -- Even if it took me a lot more time to setup > > all these branches that effectively writing the code :( > > Sorry! > > I think that I'll create topic branches for people the first time, but > ask that subsequent changes be published on branches from master. I > don't want to set the bar too high. > > > I've made these three branches and request for merges. > > Thanks! Tasks and shell-completion have been merged into edge. > > The hooks branch contains some commits that are not hook-related (the > bugs/*.yaml changes, the prettification change, and the final merge > against edge that the prettification change requires because of the > recursive directory stuff.) > > The entire bugs directory has been moved to the "bugs" branch, so that's > a delete+modify conflict, which is easy enough for me to resolve. :) I'm not fond of putting bugs in another branch, I it defeats the purpose of this kind of system, because it turns to centralize bugs instead of tying to the related topic branch. However that's another debate and while ditz let me do otherwise I'm happy. > But the final commit in the branch (the merge) means I won't be able to > apply the hooks changes to master without applying the recursive > directory search changes as well. > > Should I apply anyways? I don't want to be overly strict about this type > of thing. You tell me. As you like, either you merge the 'hook' branch and resolve conflicts or I merge them into my edge branch and you pull my edge branch merged and resolved. Cheers, -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://rubyforge.org/pipermail/ditz-talk/attachments/20080415/b10b4976/attachment.bin From hhausman at gmail.com Tue Apr 22 00:48:33 2008 From: hhausman at gmail.com (Harold Hausman) Date: Mon, 21 Apr 2008 22:48:33 -0600 Subject: [ditz-talk] I don't have all the same environment variables as you Message-ID: Hi, Ditz is awesome. It hits on all the levels I like. Congratulations are in order. :) However, ditz makes some assumptions about environment variables that make it fail not-so-gracefully on some of my machines. (Their operating systems to remain nameless to protect the otherwise innocent.) Something like the following patch might (it's not tested extensively, or at all really) save some users some trouble. Thanks for ditz, I'm really enjoying using it. Regards, -Harold $ git diff diff --git a/lib/model-objects.rb b/lib/model-objects.rb index 5cd3156..0d696a8 100644 --- a/lib/model-objects.rb +++ b/lib/model-objects.rb @@ -251,12 +251,22 @@ class Config < ModelObject def get_default_name require 'etc' - name = Etc.getpwnam(ENV["USER"]).gecos.split(/,/).first + begin + name = Etc.getpwnam(ENV["USER"]).gecos.split(/,/).first + rescue + name = "ditzy-user" + end end def get_default_email require 'socket' - email = ENV["USER"] + "@" + + + begin + user = ENV["USER"] + rescue + user = "ditzy-user" + end + email = user + "@" + begin Socket.gethostbyname(Socket.gethostname).first rescue SocketError From wmorgan-ditz at masanjin.net Sun Apr 27 02:46:00 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 26 Apr 2008 23:46:00 -0700 Subject: [ditz-talk] I don't have all the same environment variables as you Message-ID: <1209278751-sup-9004@south> Reformatted excerpts from Harold Hausman's message of 2008-04-21: > Ditz is awesome. It hits on all the levels I like. Congratulations are > in order. :) Thanks! > However, ditz makes some assumptions about environment variables that > make it fail not-so-gracefully on some of my machines. (Their > operating systems to remain nameless to protect the otherwise > innocent.) Got it. :) > + begin > + name = Etc.getpwnam(ENV["USER"]).gecos.split(/,/).first > + rescue > + name = "ditzy-user" > + end [snip] > + begin > + user = ENV["USER"] > + rescue > + user = "ditzy-user" > + end This is the right idea but in both cases I would rather see the nil value handled explicitly (even with a || in the latter case) rather than rescue, which is overkill and might mask other legitimate exceptions in the first case. You can work up another patch and get your name in the official ditz development history (oooh) or I'll throw something together. Thanks for the bug report either way. -- William From wmorgan-ditz at masanjin.net Sun Apr 27 02:46:55 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 26 Apr 2008 23:46:55 -0700 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output Message-ID: <1209278809-sup-7322@south> This is for Nicolas's 'tasks' branch. -- William From wmorgan-ditz at masanjin.net Sun Apr 27 02:46:43 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 26 Apr 2008 23:46:43 -0700 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output Message-ID: <1209278793-sup-8857@south> Column alignment was broken with the introduction of tasks. I also removed the percentages because typical output is getting a little too wide for an 80-char screen. --- lib/operator.rb | 56 +++++++++++++++++++++++++++++++++++++++--------------- 1 files changed, 40 insertions(+), 16 deletions(-) diff --git a/lib/operator.rb b/lib/operator.rb index eb42af9..0ce61f4 100644 --- a/lib/operator.rb +++ b/lib/operator.rb @@ -172,19 +172,32 @@ EOS operation :status, "Show project status", :maybe_release def status project, config, releases - releases.each do |r, groups| - issues = groups.map { |_,g| g }.flatten - title = r ? r.name : "unassigned" + if releases.empty? + puts "No releases." + return + end + + ## TODO: remove weird and deprecated :maybe_release semantics + releases = releases.map { |r, groups| r } + + entries = releases.map do |r| + title, issues = if r + [r.name, project.issues_for_release(r)] + else + ["unassigned", project.unassigned_issues] + end - groups = groups.map do |t,g| - nc = g.count_of { |i| i.closed? } - pc = 100.0 * (g.empty? ? 1.0 : nc.to_f / g.size) - [t, g, nc, pc] + middle = Issue::TYPES.map do |type| + type_issues = issues.select { |i| i.type == type } + num = type_issues.size + nc = type_issues.count_of { |i| i.closed? } + pc = 100.0 * (type_issues.empty? ? 1.0 : nc.to_f / num) + "%2d/%2d %s" % [nc, num, type.to_s.pluralize(num, false)] end - special = if r && r.released? + bar = if r && r.released? "(released)" - elsif groups.empty? + elsif issues.empty? "(no issues)" elsif issues.all? { |i| i.closed? } "(ready for release)" @@ -192,15 +205,26 @@ EOS status_bar_for(issues) end - middle = groups.map do |(t,g,nc,pc)| - "%2d/%2d (%3.0f%%) %s" % [nc, g.size, pc, t.to_s.pluralize(g.size, false)] - end.join(', ') - printf "%-10s %s %s\n", title, middle, special + [title, middle, bar] end - if project.releases.empty? - puts "No releases." - return + title_size = 0 + middle_sizes = [] + + entries.each do |title, middle, bar| + title_size = [title_size, title.length].max + middle_sizes = middle.zip(middle_sizes).map do |e, s| + [s || 0, e.length].max + end + end + + entries.each do |title, middle, bar| + printf "%#{title_size}-s ", title + middle.zip(middle_sizes).each_with_index do |(e, s), i| + sep = i < middle.size - 1 ? "," : "" + printf "%#{s + sep.length}-s ", e + sep + end + puts bar end end -- William From wmorgan-ditz at masanjin.net Sun Apr 27 02:51:48 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sat, 26 Apr 2008 23:51:48 -0700 Subject: [ditz-talk] hooks, tab completion Message-ID: <1209279100-sup-4369@south> For those of you who use these features, are they stable? I'll merge them down to master if so. -- William From nicolas.pouillard at gmail.com Sun Apr 27 05:12:38 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 27 Apr 2008 11:12:38 +0200 Subject: [ditz-talk] hooks, tab completion In-Reply-To: <1209279100-sup-4369@south> References: <1209279100-sup-4369@south> Message-ID: <1209287501-sup-2764@ausone.local> Excerpts from William Morgan's message of Sun Apr 27 08:51:48 +0200 2008: > For those of you who use these features, are they stable? I'll merge > them down to master if so. Works fine for me at least. Both features could/will be extended, but not in the meantime. -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Sun Apr 27 05:19:15 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 27 Apr 2008 11:19:15 +0200 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output In-Reply-To: <1209278809-sup-7322@south> References: <1209278809-sup-7322@south> Message-ID: <1209287849-sup-8497@ausone.local> Excerpts from William Morgan's message of Sun Apr 27 08:46:55 +0200 2008: > This is for Nicolas's 'tasks' branch. That's strange but your answers are not in threaded with the original message (I'm using sup). -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Sun Apr 27 05:47:20 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 27 Apr 2008 11:47:20 +0200 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output In-Reply-To: <1209278793-sup-8857@south> References: <1209278793-sup-8857@south> Message-ID: <1209289377-sup-2871@ausone.local> Excerpts from William Morgan's message of Sun Apr 27 08:46:43 +0200 2008: > Column alignment was broken with the introduction of tasks. I also removed > the percentages because typical output is getting a little too wide for an > 80-char screen. > --- > lib/operator.rb | 56 +++++++++++++++++++++++++++++++++++++++--------------- > 1 files changed, 40 insertions(+), 16 deletions(-) > > diff --git a/lib/operator.rb b/lib/operator.rb > index eb42af9..0ce61f4 100644 > --- a/lib/operator.rb > +++ b/lib/operator.rb > @@ -172,19 +172,32 @@ EOS > [...] > - middle = groups.map do |(t,g,nc,pc)| > - "%2d/%2d (%3.0f%%) %s" % [nc, g.size, pc, t.to_s.pluralize(g.size, > false)] Have you an idea of who wrapped this line? I don't think it's mine, and its in the raw message too. > + entries.each do |title, middle, bar| > + printf "%#{title_size}-s ", title Are you sure of the syntax "%42-s"? It seems to be rejected, you perhaps meant "%-42s"? If so I can change it my self. > + middle.zip(middle_sizes).each_with_index do |(e, s), i| > + sep = i < middle.size - 1 ? "," : "" > + printf "%#{s + sep.length}-s ", e + sep Same thing... -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From nicolas.pouillard at gmail.com Sun Apr 27 05:53:39 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Sun, 27 Apr 2008 11:53:39 +0200 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output In-Reply-To: <1209289377-sup-2871@ausone.local> References: <1209278793-sup-8857@south> <1209289377-sup-2871@ausone.local> Message-ID: <1209289987-sup-7253@ausone.local> I've pushed a patch and a fix on my gitorious repo. Excerpts from Nicolas Pouillard's message of Sun Apr 27 11:47:20 +0200 2008: > Excerpts from William Morgan's message of Sun Apr 27 08:46:43 +0200 2008: > > Column alignment was broken with the introduction of tasks. I also removed > > the percentages because typical output is getting a little too wide for an > > 80-char screen. > > --- > > lib/operator.rb | 56 +++++++++++++++++++++++++++++++++++++++--------------- > > 1 files changed, 40 insertions(+), 16 deletions(-) > > > > diff --git a/lib/operator.rb b/lib/operator.rb > > index eb42af9..0ce61f4 100644 > > --- a/lib/operator.rb > > +++ b/lib/operator.rb > > @@ -172,19 +172,32 @@ EOS > > > > [...] > > > - middle = groups.map do |(t,g,nc,pc)| > > - "%2d/%2d (%3.0f%%) %s" % [nc, g.size, pc, t.to_s.pluralize(g.size, > > false)] > > Have you an idea of who wrapped this line? I don't think it's mine, and its > in the raw message too. > > > + entries.each do |title, middle, bar| > > + printf "%#{title_size}-s ", title > > Are you sure of the syntax "%42-s"? It seems to be rejected, you perhaps > meant "%-42s"? If so I can change it my self. > > > + middle.zip(middle_sizes).each_with_index do |(e, s), i| > > + sep = i < middle.size - 1 ? "," : "" > > + printf "%#{s + sep.length}-s ", e + sep > > Same thing... > -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From wmorgan-ditz at masanjin.net Mon Apr 28 18:38:52 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 28 Apr 2008 15:38:52 -0700 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output In-Reply-To: <1209287849-sup-8497@ausone.local> References: <1209278809-sup-7322@south> <1209287849-sup-8497@ausone.local> Message-ID: <1209422210-sup-5085@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-27: > That's strange but your answers are not in threaded with the original > message (I'm using sup). Sorry! I found out on the 26th that all the email I had sent from the 23rd had all been discarded. So I re-sent it all, but the Sup edit-message-as-new command doesn't preserve the in-reply-to header (maybe it should?), and it was too late at night for me to notice. -- William From wmorgan-ditz at masanjin.net Mon Apr 28 19:02:44 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 28 Apr 2008 16:02:44 -0700 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output In-Reply-To: <1209289377-sup-2871@ausone.local> References: <1209278793-sup-8857@south> <1209289377-sup-2871@ausone.local> Message-ID: <1209422356-sup-9896@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-27: > Have you an idea of who wrapped this line? I don't think it's mine, > and its in the raw message too. Sorry. Probably the Sup edit-messaage-as-new thing again. Who wrote such a crappy email client anyways. > Are you sure of the syntax "%42-s"? It seems to be rejected, you perhaps > meant "%-42s"? If so I can change it my self. Weird, it does seem to work for me: >> "%-30s" % ["hello"] => "hello " >> "%30-s" % ["hello"] => "hello " >> "%30s" % ["hello"] => " hello" -- William From wmorgan-ditz at masanjin.net Mon Apr 28 21:18:40 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 28 Apr 2008 18:18:40 -0700 Subject: [ditz-talk] [PATCH] make 'ditz status' align its output In-Reply-To: <1209289987-sup-7253@ausone.local> References: <1209278793-sup-8857@south> <1209289377-sup-2871@ausone.local> <1209289987-sup-7253@ausone.local> Message-ID: <1209431879-sup-6461@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-27: > I've pushed a patch and a fix on my gitorious repo. Re-merged into edge. -- William From wmorgan-ditz at masanjin.net Mon Apr 28 21:46:23 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Mon, 28 Apr 2008 18:46:23 -0700 Subject: [ditz-talk] [Gitorious] ertai has requested a merge in ditz In-Reply-To: <4815b0b04180e_6309158ec60a8efc27d@octimal.tmail> References: <4815b0b04180e_6309158ec60a8efc27d@octimal.tmail> Message-ID: <1209432417-sup-8954@south> Nicolas, The two merge requests you've made have history in them from the edge branch or from merges you've made against master. This means I can't merge these into master without bringing in all that unrelated stuff. Can you rebase these onto a commit from the mainline master branch? The easiest way is something like: For factorize-html: git checkout factorize-html git rebase --onto remotes/mainline/master HEAD^ for remove-ucfirst: git checkout remove-ucfirst git rebase --onto remotes/mainline/master HEAD^^^ or whatever you're calling "mainline/master". Note that when you push, you'll have to use -f because this will be a non-fast-forward update. Thanks, -- William From nicolas.pouillard at gmail.com Tue Apr 29 04:47:18 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Tue, 29 Apr 2008 10:47:18 +0200 Subject: [ditz-talk] [Gitorious] ertai has requested a merge in ditz In-Reply-To: <1209432417-sup-8954@south> References: <4815b0b04180e_6309158ec60a8efc27d@octimal.tmail> <1209432417-sup-8954@south> Message-ID: <1209458700-sup-6896@port-ext16.ensta.fr> Excerpts from William Morgan's message of Tue Apr 29 03:46:23 +0200 2008: > Nicolas, > > The two merge requests you've made have history in them from the edge > branch or from merges you've made against master. This means I can't > merge these into master without bringing in all that unrelated stuff. > > Can you rebase these onto a commit from the mainline master branch? The > easiest way is something like: > > For factorize-html: > git checkout factorize-html > git rebase --onto remotes/mainline/master HEAD^ > > for remove-ucfirst: > git checkout remove-ucfirst > git rebase --onto remotes/mainline/master HEAD^^^ > > or whatever you're calling "mainline/master". Note that when you push, > you'll have to use -f because this will be a non-fast-forward update. Done! And thanks again for making me progressing using the obscure force of git! -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From cyberlync at gmail.com Wed Apr 30 19:40:41 2008 From: cyberlync at gmail.com (Eric Merritt) Date: Wed, 30 Apr 2008 23:40:41 +0000 Subject: [ditz-talk] hooks, tab completion In-Reply-To: <1209287501-sup-2764@ausone.local> References: <1209279100-sup-4369@south> <1209287501-sup-2764@ausone.local> Message-ID: Will this make its way in? On Sun, Apr 27, 2008 at 9:12 AM, Nicolas Pouillard wrote: > Excerpts from William Morgan's message of Sun Apr 27 08:51:48 +0200 2008: > > > For those of you who use these features, are they stable? I'll merge > > them down to master if so. > > Works fine for me at least. Both features could/will be extended, but not in > the meantime. > > -- > Nicolas Pouillard aka Ertai > _______________________________________________ > ditz-talk mailing list > ditz-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/ditz-talk > > From wmorgan-ditz at masanjin.net Wed Apr 30 20:36:02 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 30 Apr 2008 17:36:02 -0700 Subject: [ditz-talk] [Gitorious] ertai has requested a merge in ditz In-Reply-To: <1209458700-sup-6896@port-ext16.ensta.fr> References: <4815b0b04180e_6309158ec60a8efc27d@octimal.tmail> <1209432417-sup-8954@south> <1209458700-sup-6896@port-ext16.ensta.fr> Message-ID: <1209601090-sup-9357@south> Reformatted excerpts from nicolas.pouillard's message of 2008-04-29: > Done! And thanks again for making me progressing using the obscure > force of git! I've merged remove-ucfirst into master, and factorize-html into edge. I think you can prevent future rebase --onto calls if you branch topic branches off of mainline/master. -- William From wmorgan-ditz at masanjin.net Wed Apr 30 20:51:31 2008 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Wed, 30 Apr 2008 17:51:31 -0700 Subject: [ditz-talk] hooks, tab completion In-Reply-To: References: <1209279100-sup-4369@south> <1209287501-sup-2764@ausone.local> Message-ID: <1209603037-sup-9100@south> Reformatted excerpts from Eric Merritt's message of 2008-04-30: > Will this make its way in? Merged the both down to master, along with the tasks stuff. An 0.3 release is getting close! http://ditz.rubyforge.org/ditz/release-0.3.html -- William