These are great suggestions! Thanks. I'm trying them out right now and so far they look fit for the job.
On 3/17/06, Christian Boos <[EMAIL PROTECTED]> wrote: > Mark wrote: > > I'm a little bit concerned about a certain ticket issued by one of our > > programmers. He's using this ticket as a placeholder for minor issues > > that don't have tickets. For example: > > > > 1. He fixed a minor spelling error in a field > > 2. He changed the background color of a form > > 3. He changed the name of a column in a database > > > > Since he thinks that all these are too minor to be issued their own > > tickets, he simply commits each of the above changes one by one while > > referencing this "generic" ticket. In other words, the generic > > ticket's lifespan is infinite and may never close. > > IIUC, the intent here is to be able to ''categorize'' changesets, > or is it just because you require to have a reference to a ticket > in each changeset? > > If it's the latter, maybe you should simply relax your rules :) > > If it's for the former reason, that would be an use case for the > TracCrossReferences features. With that, one could either: > * write in the changeset message that "this is a MinorEdit". > Then, using the backlinks for the MinorEdit wiki page, one > could retrieve all the changesets referencing this page. > * write an explicit 'tag' relation in the log message: > <<tag MinorEdit>>. > Then, one could write some query to retrieve all the changesets > tagged that way, like [[Sources(<<tag MinorEdit>>)]]. > > > > > There is also another ticket for deprecated or deleted files. That is, > > if the programmer deletes a file no longer in use in the project he > > will then commit his latest copy and in the commit message type in > > something like "re #40". Where #40 is the ticket number for another > > generic ticket whose purpose is to log all the commits where files > > where removed from the project. > > As someone else wrote, this information is already in the repository, > even in the cache. It should be easy to write a macro, e.g. [[Attic]] > that would produce a list of all the files that have been removed. > > > > > In my mind, I disagree about how the ticket is being used because they > > are supposed to initiate action rather than just record it. > > Well, see that as an inventive use of the system :) > > > Furthermore, tickets should have a finite lifespan. On the other hand, > > I also understand that keeping a logfile of deleted files or minor > > issue resolutions might be of some use to the programmer. My questions > > then are: > > > > 1. Is this an acceptable way of using the ticketing system? > > 2. If not, what other convenient way is available that will allow the > > programmer to log minor changes and file deletions without using a > > ticket? > > As I said, the above suggestions would only work using the trac-xref code, > and if can suggest that you could try it out, be aware that it's now a bit > outdated w.r.t to the current trunk. > > -- Christian > _______________________________________________ > Trac mailing list > [email protected] > http://lists.edgewall.com/mailman/listinfo/trac > _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
