Key: Active Review Fixed Tested Deferred Closed
# Type Status Created By Subsys Changed Assigned Svr Pri Title  
108 code review 2002 Aug anonymous cvstrac 2002 Oct drh 1 1 wrong encoding in http header edit
cgi.c inserts the encoding in the header with the help of


on my systems (various linux with LANG=de[_DE[@euro]]) this gives

  ANSI_X3.4-1968 (aka US-ASCII)

and this is no known encoding. So browsers like mozilla that honour these setting switch the page encoding to US-ASCII what is not appropriate for e.g. commit comments with umlauts ...

don't know why nl_langinfo() gives this result :-(

Suggestion: Make the encoding a configurable project variable. So that someone with a hebrew locale setting can have an english project with properly displayed comments.

Use full locale name - de_DE.ISO8859-1

unfortunately, this doesn't work for me. I am not able to get any other encoding from nl_langinfo than ANSI_X3.4-1968. Here is the small program I have tested with:

#include <stdio.h> #include <langinfo.h>

int main (char *argv[], int argc) { printf ("nl_langinfo(CODESET) returns: %s\n", nl_langinfo(CODESET)); return 0; }

And though 'locale -m' shows "ISO-8859-1" as available locale LC_ALL=de_DE.ISO-8859-1 langinfo shows the well known "ANSI_X3.4-1968" :-(((

253 new active 2003 Sep anonymous   2007 Aug drh 1 1 Changing commit logs in the repository edit
cvs admin -mrev:msg - Replace the log message of revision rev with msg.

It would be nice to have the option of having the changes to commit logs in cvstrac propagate into the repository, using this command.

Same as ticket #179.

2005-Dec-21 15:46:51 by anonymous:
If we use the cvs admin -o command to remove latest version of file from repository cvstrac gets a bit out of sync with cvs. The checkin info for the first version checked in is kept in cvstrac and on subsequent checkin of the file it doesn't get replaced with new checkin info.

e.g. oops scenario - check in a bunch of files including one or more that you did not intend to checkin, undo that, later checkin a change to one of the files whose version was removed

cvs ci -m"checkin bunch of stuff" # myfile.c version is now 1.14

cvs admin -o1.14: myfile.c # oops! remove myfile.c latest version:

cvs ci -m"file update" # later check in a change to that file # myfile.c version is now 1.14

We see this in cvstrac:

1. on the cvstrac browse file page the comment for the version (myfile.c 1.14) is the OLD comment.

2. on the timeline and chngview the latest commit on that file is not seen. (if the file is checked in by itself)

3. on the chngview of the old commit the file version (that was removed for that checkin) is seen and diff is for the new commit

2005-Dec-21 18:08:20 by cpb:
CVSTrac doesn't really place nice with "cvs admin". That's a known problem. Unfortunately, "cvs admin" usually acts directly on the RCS files and doesn't notify CVSTrac about it.

Rather than using "cvs admin" to back out bogus changes (which doesn't exactly sound like a Best Practice), I'd recommend checking in a merge from the last known good revision as documented at

  cvs update -j 1.14 -j 1.13 myfile.c
  cvs commit -m "backing out changes" myfile.c

Besides working correctly with CVSTrac, this keeps a record that someone on the development team screwed up a commit.

2005-Dec-22 09:53:58 by anonymous:
Subsequent commits to files which were "cvs admin -o"ed this way do show up correctly in cvstrac. So inconsistency is only seen on the versions that were removed and that problem is quite minor.

Thank you for the pointer to the proper way of reverting changes. :)

A cvstrac setup reconstruct database will get all cvs file versions and comments back correctly in the database but of course may well break links between tickets and checkins.

2005-Dec-22 13:51:24 by cpb:

  Subsequent commits to files which were "cvs admin -o"ed this
  way do show up correctly

The -o operator doesn't really remove the revision from the CVS repository (i.e. the CVS history), only from the specific RCS file. Once the revision shows back up in the file the revision numbers sync up again and the "hole" is plugged.

  A cvstrac setup reconstruct database will get all cvs file
  versions and comments back correctly in the database but of
  course may well break links between tickets and checkins.

I expect that if you did the -o before CVSTrac picked up the change then things would be okay. CVSTrac doesn't pick up repository changes until someone tries to access it.

2007-Aug-02 14:01:06 by anonymous:
It would be nice to have a button the setup user could mash, periodically, that went through every file in the sqlite database got the message for the most recent version and ran the cvs admin command to fix the comma v file.

2007-Aug-02 14:55:38 by cpb:

  ... a button the setup user could mash, periodically, that went
  through every file in the sqlite database got the message for
  the most recent version and ran the cvs admin command to fix
  the comma v file.

Such a button would be useful for some sites. Other sites, on the other hand, might prefer a button which pulls the latest messages from CVS and copies them to the database. Other sites might only want to see the differences between the database and the repository. Other sites might want to completely disable the ability to change commit messages in CVS and/or CVSTrac.

It really comes down to how people use CVS and CVSTrac.

However, such a button is not going to happen. The idea of a single button which does large-scale non-revertable copies from the CVSTrac database to the CVS repository... No. I'd like to think CVSTrac has a decent history of not trashing peoples "crown jewels", and it'd be best to keep it that way.

If someone really wants this, we do offer external tools.

2007-Aug-04 12:03:31 by anonymous:
CVSTrac already does get the check in messages out of cvs and put them into CVSTrac, on initialization. Maybe it just reads the history file, but I'D LIKE TO THINK of CVSTrac as a wrapper to cvs such that it is the missing functionality that cvs should have had. The founder of this product was a genius.

As for going the other way, it just doesn't make sense for users the "correct" there comments in a user friendly way (again, CVSTrac is a friendly way to interact with cvs, plus more . . . I don't know why you'd want people to have to use tons of other tools that overlap in functionality just) . . . and then find that their changelog in their (say) automated build system still has the old comments.

Without this change, one can QUICKLY find their files associated with change sets using CVSTrac (again, the point) . . . but then still have to meander around looking for the files in their (say) wincvs tool and retype the correction.

Since CVSTrac sucks out the comments on project initialization (in the setup), it's obvious that the intent is for the comments to stay in sync (not to diverge).

If folks don't want CVSTrac to mess with their "Crown Jewels", (a) they don't have to mash the button (as a 'setup' user), or (b) they don't have to even use CVSTrac. The latter is the case if they don't TRUST the tool.

Oh, and guess what . . . they are less likely to trust the tool if "Edit comment" doesn't actually edit the comment. EVERY person I've EVER shown this tool to . . . all the way from the beginning . . . loses a little faith in that command once they find out that there's no integration in that command. Again, they call it a flaky tool, not a design decision.

I make fun of ClearQuest for its poor integration with actual code. I call it a lie when folks who use ClearQuest say that they have "integration". I tell them to look at CVSTrac. . . . that it's way better.

It's still better, but the mentality I'm seeing in that argument seriously worries me. I'd like to hear from the author on his thoughts.

2007-Aug-04 13:38:56 by cpb:

  The founder of this product was a genius.

I can't argue with that.

  Since CVSTrac sucks out the comments on project initialization
  (in the setup), it's obvious that the intent is for the comments
  to stay in sync (not to diverge).

I'd have a hard time agreeing with that assumption. For one thing, evidence is against you. Checkin message editting has been in CVSTrac since [1] and synchronization was never addressed (in either direction). The nearest thing to synchronization is my message sync hack using external tools.

I'm not against checkin synchronization (I'm not just the author of, I'm also an enthusiastic user). I am not in favour of doing in on a large-scale, nor am I keen on doing it "silently". If it came down to having a "[ ] write message change to CVS repository" flag in the chngedit form... I could live with that.

  I'd like to hear from the author on his thoughts.

I don't think he's exactly hiding his thoughts on SCM integration with CVSTrac-like tools.

2007-Aug-05 05:35:38 by anonymous:
can anon folks see an example of an external tool in use? I'm having a hard time visualizing it. does it become another button like "Edit"?

2007-Aug-05 12:53:37 by cpb:
At you can see the [blame] button in action bar. That pretty much sums it up. I doubt you'll see anything on a public network which allows anon users to change anything in the database.

I suppose I could upload some screenshots or something of what I use at work.

259 code review 2003 Oct anonymous cvstrac 2005 Sep   1 1 missing link in about page edit
in common.c:

  void common_about(void){
    static const char *azLink[] = { 
       "index", "Home", 
    common_header("About This Server", azLink);

this should be changed to:

  void common_about(void){
    common_add_menu_item("index", "Home");  <-- added
    common_header("About This Server", 0);  <-- changed

in the original version, the "Home" link is not displayed in the header of the page.

This: common_header("About This Server", azLink);

nees to be changed to: common_header("About This Server", 0);

invalid reference to removed variable 'azLink'

294 doc active 2004 Mar anonymous   2004 Mar anonymous 1 1 Documentation on the CVS Repository edit
CVSTRac doesnt recognize the CVS Repository even if you do a commit after an import. You must actually manually add each file like this cvs -d $CVSROOT add [file] then CVSTrac will display the CVS directory that this file resides in.
This can be done by checking out your files from the repository and then doing a cvs -f -m "No Change" commit . on the files. test
305 new active 2004 Apr anonymous cvstrac 2004 Apr lansil 1 1 css customization edit
Is there scope for the site to be customized using css ?
2004-Apr-06 15:33:35 by anonymous:
It is possible to add a style sheet by going to Setup => Headers & Footers. I use a header like this:

           <title>%N: %T</title>
           <link rel="stylesheet" type="text/css" href="/~progers/cvstrac/diff2html.css">

The classes specified in the html don't have great names (they use generic style names like 'box1' rather than 'menuBar' that would be easier to customize) and not all elements have a class, but it is possible to control the document with some tweaking. I've attached a copy of my stylesheet for reference.

It would be cool if cvstrac had more descriptive class names and, and if it hosted it's own internal style sheet (but this could be perceived as needless embellishment since you can supply an external one).

2004-May-11 06:44:19 by anonymous:
It would be fairly easy to refactor much of the HTML as DIVs, etc - and in cases where tables were absolutely necessary those could all have CSS classes. I'd love to be able to customize my install with CSS, and this would fix #318 if the context and navigation links were separated in different divs.

drh - I'm a happy lackey to do this, thugh I'm not a competent c hacker, I could modify the html and create default css. email

336 new active 2004 Aug anonymous cvstrac 2004 Aug drh 1 1 Missing Fields in CVS Trac edit
PROBLEM Not enough multi line fields

SYMPTOM There is only 1 multi line field in the screen 'Create a new Ticket'

SOLUTION In order to keep descriptions simple I'd like to have a set of different multi line fields: - Symptom - (Requested)Solution - Steps to Reproduce

COMMENT Many people who report an issue make it 1 long story. Using separate fields for each part will force them to clearly state their point. The single line possibilities in 'User-Defined Fields' are not an option.

369 doc active 2005 Jan anonymous   2005 Jan drh 1 1 Studying the source code edit
Could anybody give me some background on the design philosophy behind cvstrac?

I like the software, and I like the idea of writing native CGI applications. So, I started digging in the cvstrac sources to get inspiration.

I understand individual lines, but I fail to understand the big picture. What is the guiding principle behind the subdivision in separate files.

Usually, you find simple guiding principles, such as: one source file corresponds to one web page (typical in php, asp,, ...) or corresponds to one abstract data type (such as one table and its related methods, or one memory struct and its related methods, ...), or is otherwise organised around another particular guiding principle, which tremendously facilitates locating particular logic. It turns a source tree into an addressable grid, where you can almost calculate where some logic must be located, and where you can make changes, if needed.

What is the guiding principle underlying cvstrac?

2005-Jan-30 04:38:26 by drh:
Your request for better documentation is noted. Until a proper explanation can be composed, I offer these hints:

  • Individual webpages are implemented by functions. A special header comment on the function (example:

              ** WEBPAGE: /example

    identifies the function as one that implements a webpage and gives the name of the web page it implements.

  • Lines that begin with "@" become the HTML output. Within a @-line, %d(expr) prints "expr" as an integer, %s(expr) as a string, and so forth. %h(expr) prints expr as a string but also escapes any characters that are special to HTML so that < is converted into &lt;, and so forth.

Both of the above tricks are accomplished by preprocessing the source code before it is handed to the C compiler.

370 new active 2005 Feb anonymous cvstrac 2005 Feb drh 1 1 Why not to scan the cvs directory to get the reponsitory? edit
Why not scan the cvs directory to get the reponsitory? I setup the reponsitory of cvstrace, but the history file don't includes all informations of the modules, so I Only can get the Reponsitories which is in history file.
2005-Feb-04 18:30:07 by anonymous:
I have this same problem. Also when I import a module, I then have to do an additional commit to get it show. Plus, I am unclear how to remove a module from CVSTrac. Test
376 new active 2005 Mar anonymous cvstrac 2005 Mar drh 1 1 create a .pid when run in server mode - crontab friendly edit
I am running CVSTrac as a standalone server. It would be nice, when standalone server is launched, if it created a pid file. That way I could easily check from crontab is CVSTrac is still running and restart it if not.
402 todo review 2005 Apr anonymous cvstrac 2005 Apr anonymous 1 1 Prueba de Ticket edit
Esta es una prueba de Ticket ... NO LE DEN IMPORTANCIA y eliminenla :d

Se agrego una linea a la descripcion

Se agrego una nueva marca
428 event active 2005 Jun anonymous cvstrac 2005 Jun drh 1 2 cvstrac does not see modules, which are created via pserver edit
I today installed cvstrac running from inetd under FreeBSD 4.11 from the port. I did setup the cvsroot path and left the module field blank, to see all modules. When browsing cvs from cvstrac I see some modules missing. When checking CVSROOT/history I saw that the missing modules were created remotely via pserver access using cervisia frontend. But I can see other remotely created modules. There are 88 modules in our repository.
2005-Jul-01 23:41:11 by cpb:
In the modules that aren't being seen... Were there ever any changes made to any of the files in the history?

The thing is that CVStrac's history processing ignores module creation, including "import". So if you just do a "cvs import" on the module and then nothing else, the module won't be seen.

2005-Jul-05 09:21:39 by anonymous:
Yes, we did one change in a file and now see the module in the repository. But we only see this one file, where we made a change.

2005-Jul-05 19:19:43 by cpb:
Yeah, unfortunately only changed files are visible because, basically, they're the only things that ever show up in the history file.

This isn't the easiest thing to fix. When reading the history file, for every 'O' entry encountered you'd need to do a recursive scan of the directory (and Attic) and extract the initial version info of each encountered file, treating each one as an 'A' or maybe 'M' action. It can be done, but it's nasty. It also assumes that later versions of CVS don't create 'A' entries when importing.

448 new active 2005 Aug anonymous   2005 Aug cpb 1 1 import of svnserve users edit
Attached diff enables svntrac to import users from svnserve users file. This is not equivalent to reading of CVSROOT/passwd since some installations of Subversion don't use svnserve and hence don't have relevant users file. This is not the best solution, but ATM I have no plans to add support for importing users from mod_dav_svn .

svntrac supports only import of users, and unlike cvstrac , it can't update svnserve users file based on the contents of svntrac db. This limitation is imposed by the fact that passwords are stored encrypted in svntrac db, while they are stored as plain text in svnserve users file. Only way, AFAICT, to support it would be to store plain text passwords in db, but I guess this goes against cvstrac design goals?
Though it would be nice to have this "user export" feature since AFAIK there is no way to manage svnserve users other then to edit users file directly.

2005-Aug-19 18:33:19 by cpb:

  Only way, AFAICT, to support it would be to store plain
  text passwords in db, but I guess this goes against cvstrac
  design goals?

Not storing plain text passwords in a database is just common sense. That svnserve is doing otherwise is simply poor design. I could understand if they used a different hash for storage, but to do nothing at all?!?

2005-Aug-19 19:21:29 by anonymous:
I guess they wanted to make it really easy to edit the file directly and rely on FS permissions to make it "safe". Not the greatest design out there, I must agree.

2005-Aug-19 19:34:50 by cpb:
Definitely not. It's a Bad Thing when a password is stolen because of network sniffing, but when someone steals an entire database of passwords....

2005-Sep-01 15:46:02 by cpb:
This issue could be dealt with by allowing the definition of an external account manager script which could do whatever it wanted with users and passwords. For example, it could be called and (on stdin) passed any of:

  add <userid> <passwd>
  perms <userid> <CVSTrac perms>
  passwd <userid> <newpasswd>
  remove <userid>

This would also be convenient for CVS users like myself who use CVS-over-ssh rather than pserver.

475 doc active 2005 Sep drh   2005 Sep drh 1 1 Add wysiwyg editing of wiki and tickets. edit
2005-Sep-06 22:57:15 by cpb:
It's still pretty far from being generally usable, though. I found a bug using Firefox after, literally, one click and one keypress.
563 doc active 2006 Feb anonymous cvstrac 2006 Feb drh 1 2 Target fix version edit
When creating a ticket, i would like to be able to set a string that gives the version the bug need to be fixed for (eg: 1.1)

Would be even better if this could be a drop down and that we could set some marketing version somewhere in the setup

2006-Feb-02 17:27:16 by chorlya:
You can do that already with user-defined fields.
Take a look at User-Defined Fields in setup section. Also take a look at Ticket Types in setup to see how you should enter those versions.

2006-Feb-02 17:29:25 by chorlya:
Perhaps we should add a note about this to wiki since a lot of people seem to want this feature and don't know how to set it up

2006-Feb-02 18:35:43 by cpb:
See also #559.
660 event active 2006 Sep anonymous cvstrac 2006 Sep drh 1 2 How to convert "cvstrac" database to "mantis"? edit
I've been a happy cvstrac user for quite a while. But I've had to change my server, and I cannot run cvstrac on it any longer (due to IT constraints).

I have set up "Mantis" ( as a reasonable substitute, but I have an existing cvstrac database I would very much like to convert to "Mantis" so I don't lose any of my data.

My first attempt at conversion was not very successful. Does anyone have any pointers or (hopefully) a script to convert the format?

Thank you.

2006-Sep-08 13:06:34 by cpb:
Sorry to hear about your sorry IT support ;)

I think I saw something on the Trac mailing list about a script to convert from CVSTrac to Trac. How well this works for you, of course, depends on how close the Mantis and Trac database schemas are. I know nothing about Mantis internals, so I can't really say anything else.

747 event active 2008 Mar anonymous cvstrac 2008 May cpb 1 1 Does cvstrac.exe work? How (step by step wiki)? edit
The precompiled binary inside cvstrac-2.0.1-MinGW-20071107.7z just crashs (unhandled exception) with the command:

cvstrac.exe cgi

Does someone run cvstrac.exe as a CGI Apache (Windows build) program?

805 event active 2009 Jul anonymous cvstrac 2009 Jul cpb 1 1 amendment to ticket 801 re. CVSTracNT hang edit
Hi - I'm about to pull out my few remaining hairs... installing CVStracNT on a Windows 2003 server machine that has the CVS repository on it - I created a new DB, I can log in as setup but if I try importing users, creating a ticket, rescanning the repository (i.e. any DB writes it seems) I can see a journal file getting created and the process never returns. I have to stop the service and remove the journal file to continue. Has anyone seen this behaviour before? I've tried everything I can think of (permissioning on the db file, on the service - even run it as administrator) Is there some sort of debugging output that can be enabled so I can see what's going on? Thanks - Dave
2009-Jul-28 17:21:35 by cpb:
Since CVSTracNT is basically a fork of CVSTrac, and isn't kept particularly up-to-date, it's pretty difficult for us to determine if it's a setup problem on your end, an actual CVSTrac bug (which may have already been fixed more recently than the last CVSTracNT release) or a problem introduced by the CVSTracNT folks when they forked and ported to Windows.

I'd suggest visiting a CVSTracNT support forum, if they've still got them.

You could also try building CvstracOnWindows from the latest CVSTrac source yourself and see if you still have problems.

313 doc active 2004 Apr anonymous cvstrac 2004 Oct   2 2 Date shown in timeline is wrong edit
When looking at timeline and chgview, cvstrac is off by a day, here's a sample check-in:

  Date:  	2004-Apr-20 17:40:23 (local)
                2004-Apr-20 21:40:23 (UTC)

  ---	2004/03/22 17:02:53	1.45
  +++	2004/04/21 21:40:23

Notice the 1 day difference between the date reported by chngview 2004-Apr-20 (UTC) and diff 2004/04/21, same problem shows in timeline, all dates are off by 1.

I am pretty sure this is not a bug but something to do with our configuration, but can't figure out what and where to configure this.

Thanks for any insight.

2004-Apr-22 20:30:10 by anonymous:
I also started having this problem just today with 1.2.2. Seems rather odd that we would both experience this problem on the same day, when everything previously worked fine. I haven't checked the source yet, but perhaps there's a bug in the way dates are handled which only manifests with certain numbers?

2004-May-13 09:17:06 by anonymous:
I've noticed this myself today with cvstrac 1.1.2: our checkin is dated:

  revision 1.3
  date: 2004/05/11 13:03:14;  author: [...];  state: Exp;  lines: +14 -13

in the output of 'cvs log [...]', which is correct, but cvstrac incorrectly displays:

  2004-May-10 16:50  1.4  Check-in [647]: [...] (diff)
  2004-May-10 14:03  1.3  Check-in [642]: [...] (diff)
  2003-Nov-19 17:09  1.2  Check-in [384]: [...] (diff)

around and for the change in question for the same file. The first samples above is reporting in UTC and the second is BST (UTC+0100) admittedly, but that only accounts for on hour's difference. The month day field is still off by one, so this does not seem to be timezone related, given the previous commentor's experience.

2004-May-20 15:40:56 by anonymous:
This appears to be a follow-on for #203.

Should be fixed in 1.1.3 and higher.

To fix the dates on existing records, the procedure would appear to be:

  • update to 1.1.3 or higher
  • copy your project database, (called project.db here)

  $ cp project.db project.db.bak

  • check my calc on Mar 01:

  sqlite> select strftime('%s','2004-03-01') from chng limit 1;

  • Update times:

  $ sqlite project.db
  sqlite> update chng set date=date+(60*60*24) where date > 1078099200;

  • Check to see that the right records have been updated (use cvs log vs the timeline especially close to Feb 29)
  • revert from project.db.bak if necessary
  • Make sure you do this just once.


I just updated from 1.1.2 to 1.1.4 and applied the correction to our database. The previous version showed a one-off error in the calculation (we had check-ins on Feb. 29th that still were wrong). Actually correcting the date for date > 2004-03-01 gives the right result.

-- Edelhard Becker <>

343 code defer 2004 Aug anonymous cvstrac 2005 Dec drh 2 1 AUX filters in report not initialized properly edit
Use an AUX field as a filter in an SQL query for a report. Try to show the report. The content of the field contains a random default content.

For example look at this report:

Looks like an unititalized variable.

2004-Aug-18 15:10:05 by anonymous:
The problem seems to be in the SqlLite function sqlite_mprintf. See:
368 new active 2005 Jan anonymous cvstrac 2007 Feb drh 2 2 Enable to set output encoding or use utf-8 by default edit
I'm using cvstract for acces to the repository with various language mutations of processed texts. It is boring to set manualy utf-8 encoding in my browser for each page with source diff i want to review.

It would be nice to have configuration option for output encoding

2005-Jan-28 11:49:39 by anonymous:

2007-Feb-05 16:07:33 by anonymous:
I'll glad to see this ticket done too.
373 new active 2005 Feb anonymous   2005 Feb drh 2 2 Add ability to create templates for new tickets edit
It would be helpful if we have the ability to reuse mutliple templates to open new tickets.


  1. Should be able to save a template with default values set to different parameters.
  2. Reuse these templates to open different types of tickets
2005-Sep-02 18:25:49 by anonymous:
504 new active 2005 Nov anonymous cvstrac 2014 Feb drh 2 2 Timeline is not saving date in Defaults - VERY annoying! edit
The Timeline feature is interesting, but rendered only half-useful, because it defaults to "today and backward", no matter what the user wants. Entering a future date (e.g. 2020-Jan-01) so that all milestone dates are visible (highly desirable behavior on my entire development team) and clicking "Make Default" does not save the preferred date.

I understand that "Make Default" could end up saving today's date and making the feature of dubious use for those who (if there are any) don't want to see future dates in the timeline, so I would propose a checkbox next to "Make Default" that says "include date in saved default", checked "off" by default.

I think this single change would improve CVSTrac's overall usefulness by about 20%. Seriously.

2005-Nov-05 14:21:12 by cpb:
As long as it's never a default behaviour, sure. I've been bitten by the date thing just by copying and pasting the timeline URL, so I can speak from experience that inadvertant use of a non-empty date can be a really Bad Thing.

2005-Nov-08 03:19:37 by cpb:
I'm not entirely convinced that it's that much of a useful feature, but at least it's quite non-intrusive. Try the attached patch.

2010-Sep-09 11:37:24 by anonymous:
I miss this feature, as well. Thinking of a milestone message that contains a list of tickets as demonstrated in #463 it would give you the dates of the 2 or 3 milestones that are in the near future on top of the current timeline. Very useful for a basic project planning with milestones.

Trying to understand the supplied patch in the attachments it looks like a fixed date will be saved in the config table. Just considering what this means: The administrator could specify what timerange to use and thus which milestones would be visible. That's okay. And if he defines a new milestone he has to decide again if the timerange should be extended to include the new milestone as well.

So the workflow would be to specify a new milestone and additionally check if the date is still inside the default timerange for the timeline. A similar two step workflow would be needed if the target date of a milestone is moved to a later date (a quite typical operation in project planning). Of course if the timeline end day is something like 2099-12-31 the second step would not be required within the next 90 years. (On second thought I have to adjust this to 2038-01-19, because the date is stored as seconds since epoch.)

As I had the same feature request (but did not search the tickets here) I used a different workaround with a look ahead period that is read from the config file. Currently I simply read the number of days that the timeline should be extended to the future. (Configuration changes need direct access to the sqlite backend database - that's okay for me). The change is in the timeline_page() function after the line:

  i = atoi(PD("d","0"));
  if( i>0 ) days = i;
  begin = end - 3600*24*days;

  end += (atoi(db_config("timeline_future_days","0")) + 1)*3600*24) - 1;

The days that we look back into history are still the range that is defined in the input field of the timeline form:

  begin  +  P("d")  +  timeline_future_days  =  end

In other words this would say "... and include the milestones that are due in the next N days in the timeline." Acutally it would include anything within the next N days in the timeline. But the only thing I can think of that might have a future timestamp are milestones.

-- Rolf

2010-Sep-09 13:26:55 by anonymous:
Apart from the paranthesis being wrong in the changed line, it should be:

  end += (atoi(db_config("timeline_future_days","0")) + 1)*3600*24 - 1;

this not really working as I thought. The modified end date (+N days) is not only used in the query statement but also put in the input field "d" of the timeline form. If the form is resent that field will be evaluated and used as the staring point for the end date ... and another N days will be added.

With each request the range is shifted another N days to the future.

2010-Sep-10 13:52:31 by cpb:
If all that's needed is some kind of "n days in the future" setting, ticket_504_2.patch might be sufficient. All it does is extend the "days back" value into both directions when an end time isn't explicitly defined. The phrasing of the "days back" text entry would need to be fixed, though.

2010-Sep-15 23:56:56 by anonymous:
It took me some time to get the patch applied and test the changes. I had local changes in my file timeline.c and the patch simply looked at the line numbers. Unified diff might have been more tolerant in such cases.

The results are good if the timeline is called from the navigation menu without parameters. 120 days reaching back in history and another 120 days in the future. The problem comes in when you look at the timeline and decide that you need other states of the tickets to be shown or hidden. If you check/uncheck the options and submit the timeline form the modified future date &e=2011-Jan-13 will be send as request parameter and the new range will be:

  2011-01-13 -120 days (=today)  ...  2011-01-13 (or 2011-01-13 +120 ?)


And it shows only the changes from today (plus the milestones that are due in the next 120 days -- in my case there are none in this range)

Not sure, how this can be handled properly. I had some idea in mind to keep the current date in the "e"nd input field and just silently extend the query to include N more days. The N days would then be a system wide parameter coming from the config table and not something that the normal user can decide. Actually if symetric ranges are okay your solution to get the N value from the "d" request parameter (or from the cookie) is very appealing.

Note also the different rendering of the Milestone comment in the red separating box and in the normal timeline content. As long as you do not use more (complex) markup it is still okay though.

-- Rolf

2010-Sep-16 02:26:55 by cpb:
Ah, yes. I'd forgotten about the end date sticking around in the form submission. Quite frankly, my instinct is to just remove that behaviour; it's mainly there as a formatting hint for the user and there are other ways to accomplish that. Besides this problem, it also makes it difficult to change settings and then provide the resulting URL to someone else.

2010-Sep-16 10:23:09 by anonymous:
I would be the first one to scream out loud if you'd remove the input field. It is absolutely crucial if you want to look back in history, because you roughly remember that there was something in last december. If I couldn't filter out the flood of checkins and changes of the last few months I would be lost.

Or maybe i should try to figure out the other ways to achieve it that you have mentioned...

  > it also makes it difficult to change settings and then provide the resulting
  > URL to someone else.

Would that be working currently? Most of the settings depend on the cookie? Or am I wrong here? Typically I only exchange URLs to reports or tickets, but so far I never did this for the timeline.

2010-Sep-16 13:45:54 by cpb:

  > I would be the first one to scream out loud if you'd
  > remove the input field.

Oh, no, that's not what I meant. The problem is that the input field is pre-filled with the present date. Then when you submit a change to the form, that date becomes the end time. The only reason to have that pre-filled value is to provide a "hint" as to the expected format.

So no, the input field stays. The pre-filled end date, however, can go.

  > Most of the settings depend on the cookie? Or am I wrong here?

It's both. The settings go into a cookie for later visits, but when you're actively changing things they also end up in the URL.

Exchanging timeline URLs isn't something I commonly do either, which is actually part of the problem. Every time I do copy a timeline URL I seem to forget to remove the end time from it...

2010-Sep-20 11:26:57 by anonymous:

  > The only reason to have that pre-filled value is to provide a "hint" as to the expected format.

Thanks for this information. It showed me the right direction: I use a boolean variable to check if the end point of the timeline was explicitly specified by the user or if a default is used. The behaviour for a user specified range is the same as before, but for a default time the range is extended into the future and the "e" text input field is left empty. So I have something like the following in the form:

  timeline of [90 ] days going backwards from today [       ] peeking into future till 2011-Feb-27
  timeline of [90 ] days going backwards from today [2010-Sep-20]

The "into future" hint can be visually modified/hidden via CSS (typically a smaller and lighter font would be used for it). On second thought it might be even better to make it a tooltip (title attribute) for the word "today".

I still use my "administrator only" approach, because the alternative to have the same amount of days reaching backwards and forward didn't suite me. See the attached patch "ticket-504_3.patch"

734 code review 2007 Dec anonymous svntrac 2007 Dec   2 2 svntrac crashes with SHTTPD on Windows edit
Running svntrac as CGI with SHTTPD (admittedly a less than full featured web server) causes svntrac to crash in a call to strcmp() with a NULL pointer AV. I was able to eliminate the crash by commenting out the code in main() in this section:

     /* Microsoft IIS doesn't define REQUEST_URI variable,
Hmm, now (with Abyss) I get:

   Assertion failed: zPath[0]==0 || zPath[0]=='/', file main_.c, line 464

2007-Dec-19 04:30:14 by anonymous:
More info...

URI: /proj.trac/dirview

SCRIPT_NAME: /proj.trac

PATH_INFO: /dirview


   while(zPath && zScript && *zPath && *zScript && *zPath == *zScript)

strips the '/' off the front of the path. The assert fails.

2007-Dec-19 11:40:19 by cpb:
Okay... It appears that the Windows support assumes CVSTRAC_WINDOWS==IIS, and SHTTPD is actually a proper HTTP server.

I think I'll need to clean it up such that there's actually an explicit check for IIS and most of the CVSTRAC_WINDOWS trickery will only happen with IIS.

Won't get to that until tonight.

2007-Dec-19 19:35:58 by anonymous:
I just changed

  zScript = getenv("SCRIPT_NAME");
  /* If the PATH_INFO & SCRIPT_NAME are the same, means we got
  ** IIS wildcard ScriptMap, therefore we allow only one level wilcard mappings.
  ** Othwerwise we remove common part of zPath and zScript.
  if( zScript ){


  zScript = getenv("SCRIPT_NAME");
  /* If the PATH_INFO & SCRIPT_NAME are the same, means we got
  ** IIS wildcard ScriptMap, therefore we allow only one level wilcard mappings.
  ** Othwerwise we remove common part of zPath and zScript.
  if( g.isIIS == 1 && zScript ){

and it works for me. -e

2007-Dec-19 22:37:40 by cpb:
Try [991]. It does something like that, and lets us eliminate some ifdeffery.
90 new active 2002 Aug anonymous   2002 Aug drh 3 2 Handle different projects in one CVSROOT edit
When more than one project is located under one CVSROOT it is difficult (or impossible) to create an Milestone for an special project.

Remark: Yes, I know how to it from the command line.

191 event active 2003 Mar anonymous cvstrac 2003 Mar drh 3 1 User keeps getting logged out edit
One of my developers keeps getting logged out. He says a typical session goes like this:

     Yip. Cookies enabled. I just tried it under netscape as well.
     1) Login
     2) Wiki
     3) edit (or was it note, edit?)
     4) Now logged in as anon. not Andre

Same thing happens with making or editing tickets.

Please help me to reproduce this by providing additional information. If possible, capture TCP/IP traffic between the browser and the host using a program such as the "sockettee" script attached. Include the captured session as another attachment to this ticket.

ASO - Done. Captured output attached. If this output is not sufficient, please e-mail me: and thanks for the help drh. :)

2006-Apr-26 03:19:24 by cpb:
One solution to these login problems might be to allow specific user accounts to be tagged as having a volatile IP address. In other words, the IP is ignored when checking for cookie validity.

I could certainly use this sort of thing...

193 new active 2003 Mar anonymous cvstrac 2016 Nov anonymous 3 2 Seting MIME types edit
Our cvs repository contains various binary files, inclduing some PowerPoint files. When browsing the repository cvstrac uses the MIME type text/plain for .ppt files. It would be nice to be able to configure this some how.
299 new active 2004 Mar anonymous cvstrac 2004 Mar drh 3 2 Add enums for severity and priority edit
The numeric constants (1-5) for severity and priority are a source of confusions for our users - other systems that we have are using different numbering systems.

It will help if the "enum" table will be extended to allow the assignment of labels to those levels. There is no need to change the actual coding - the 1-5 level are more than enough.

The enums should be edited by the 'setup' user, and should be used for ticket entry and editing.

2004-Aug-19 09:27:34 by anonymous:
  • I would like that, too. It is not obvious which number is the highest priority, so labels like 'high', 'low', 'medium', 'very high' or similar would be a great improvement.
  • Additionaly, I would propose a medium default value (3), or let the setup user choose it.
325 new active 2004 May anonymous cvstrac 2004 May drh 3 2 Make wiki diff configurable edit
The diff output for wiki entries should be configurable - both in terms of diff format (unified format preferred), and the ability to pipe to an external process so pretty output can be displayed. The stuff you already have implemented for the cvs external diff processes would work great for the wiki diff processes.

(Note that the external diff config doesn't make clear that it only applies to the cvs part and not the wiki part.)

2004-May-18 02:36:09 by anonymous:
link to #322


text in html
include br

2004-May-18 02:40:22 by anonymous:
47 new defer 2002 Jun anonymous   2003 Jan   4 1 Cannot browse base versions edit
I can only browse version 1.2 files. No imports/version 1.1 files appear in the browse section.
Unable to reproduce.

I have a similar problem -- I don't see anything at all in the browser since I have just imported a project and all files are at version 1.1. It seems that CVS import does not add the appropriate entries to the history file. Is there a way to kick-start CVSTrac such that it will find the base versions of the project files, e.g., by faking history file `A' entries? --Anselm Lingnau <>

151 code active 2002 Dec anonymous cvstrac 2017 Mar drh 4 1 html-encodes swedish chars in wiki pages with mozilla edit
I tried to edit wikipages containing swedish characters with latest mozilla and when i previewed and submitted the changes, all these characters where encoded with amp-hash-asciicode... Editing with IE was ok, tho. Is it mozilla, me or cvstrac?.
Using Opera 7, any non-ASCII character becomes a question mark. As an example, here's an accented "E": ?
This also happens with ISO-8859-1 characters. Some i18n effort is necessary here, or at least handling the text forms properly.

2004-Jul-17 14:52:14 by anonymous:
I'm having the same problem with Mozilla (under Linux) and French/German characters. E.g., a "ü" gets recoded into "ü", as you can see here :-(. Then, the ampersend & gets re-encoded again, so that the result doesn't even display as an international character.

The problem doesn't appear when using konqueror. Perhaps this is related to the document encoding information send by the built-in webserver?

2004-Nov-29 11:55:21 by anonymous:
I have the same problem with Mozilla 1.7.3 on Windows.

I found a workaround: in Mozilla change the codepage from US-ASCII to ISO-8859-1 before submitting changes.

187 new active 2003 Mar anonymous cvstrac 2008 Jan drh 4 2 cvs import/commit "Browse Repository" annoyance edit
I've created some new repositories to manage our projects and i first realized why the files aren't listed in the "browse repository" section. This seems to be described also in #88 and #113.

I ever use cvs import to checkin new source trees. That's why cvstrac didn't update the tables (if this is right).

The problem is, using "cvs add" takes time, can only be used with a "find . -print -exec cvs add {} \;" to automate many file checkins, and "cvs add" is even not mentioned to use for cvs with initial checkins of complete source trees.

There are two ideas how to "fix" this problem 1. Name the "Browse - Browse the CVS repository tree." menu as "Browse - Browse changed files in the repository tree.", but this is not the way i want to work with cvstrac

2. Find a way to "reconstruct" the filechng (and other influenced tables) as setup-menu or as "realtime-sync-filetree-on-browse" which seems to be useful...

Is there another way to fix this? cvs rtag tagname modname doesn't work, did i used the rtag command wrong ?`

Bye, Bjoern

As attachement, a first test version of a filetree browse patch for version 1.1.2, Attic isn't used yet. This is just the "realtime-sync-filetree-on-browse" example which doesn't update the sqlite tables.

Bye, Bjoern

2006-May-30 12:58:24 by cpb:
The cvs rls -R -d / command is the most appropriate way to scan the repository for files. Doing something like this when the history position is at zero might be adequate...
231 todo active 2003 Jul anonymous cvstrac 2007 Oct cpb 4 1 Replace all hard-coded colors with CSS classes edit
Customizing CVStrac can be a hellish nuisance with all the hard-coded colors within the C code. This is especially true in report tables, where there is no way to customize the rows themselves.

My proposal is to make CVStrac layout and coloring fully CSS-based. In this fashion, a report table would have the following tagging:

<table class="reportTable" ...> <tr class="reportHeader"><td class="reportHeader ticketNumber">... <tr class="reportRow activeTicket">...<td class="activeTicket ticketSubsys">

...etc. Note the use of multiple classes to enable full customization.

You can, for instance, say:

.reportTable { font-size: 8pt; } .reportHeader { font-weight: bold; text-align: center; } .reportRow { padding: 2px; } .ticketNumber { font-face: Courier; } .ticketSubsys { font-style: italic; } .activeTicket { background-color: orange; }

This would make the entire table 8pt size, the report headers bold and centered, give each report row extra padding, and give distinct coloring and fonts to both active ticket rows and specific columns.

I might find the time to make a patch, but I'd like to have some feedback first as to whether this would be incorporated.

2005-Aug-25 20:29:10 by anonymous:
In the meantime, I went through the motions and did some tests several months ago - only to figure out that multiple CSS classes isn't something IE, for instance, supports properly (which rather killed the report reformatting idea, at least based on TD formatting alone).


2005-Aug-25 20:42:17 by cpb:
Be warned... I know next to nothing about CSS

What happens when you specify all the different classes and just don't reference them in the stylesheet? In other words, can we output "good" CSS-compliant HTML and worry around browser stupidity in the stylesheets (or in the future, when IE catches up with standards).

2005-Aug-25 22:08:34 by anonymous:
Hmmm. It depends. You see, some things specified in HTML actually cause trouble when attempting to override them via CSS...

Ideally, CVStrac should have a layout like so:

  <div id="header">$title</div>
  <div id="navigation">status, search, links as a UL (see "a list apart" for amazing ways to deal with navigation as bulleted lists)</div>
  <div id="content">timeline and so</div>
  <div id="footer">$version</div>

and a default stylesheet somewhat like:

  body { font-family: Arial, Helvetica, sans-serif; font-size; 10pt ... }
  #header { width: 100%; background-color: light-blue; }
  #content, #navigation { float: left; }
  #header H1 { font-family: Times; }
  #navigation li a { color: blue; }

...that would take care of the fixed elements. Then you'd use classes for the ones that may or may not appear, or to tweak visual aspect based on status:

  .milestone { padding: 2px; border: 1 pixel solid blue; }
  .open { color: red; }
  .closed { color: grey; }

...etc. I can try to think about it a bit more later, but this approach would remove practically all FONT and require a lot of changes to the way H1, H2, etc. are used...

2005-Aug-25 23:30:38 by cpb:

  some things specified in HTML actually cause trouble
  when attempting to override them via CSS...

Ah. So you're really better off stripping down to minimal HTML rather than just tacking class="foo" or id="bar" on to already existing stuff?

  CVStrac should have a layout like so:

Needs an "action" section (see [352]) and maybe a "whoami". Otherwise it captures the page structure quite nicely.

  see "a list apart" for amazing ways to deal with navigation
  as bulleted lists

Sweet. I won't pretend to understand the CSS, but if they can get that sort of nav bar from just straight <li> tags, I'm up for it.

I guess the question to ask is what's the best approach? Obviously there's a need for infrastructure (i.e. a way to setup the CSS and download it), and the overall page layout needs attention (<DIV>, etc). Is this something where we can stop there and have something "decent" (as in functional and not uglier than now) which we can incrementally cleanup or are we talking about "all or nothing"?

2005-Aug-26 02:19:57 by chorlya:
I'm all for it. CSS has many benefits over current markup in cvstrac :

  • Reduces code size
  • Eases maintenance
  • Increased customization options

  are we talking about "all or nothing"?

It's not really all that useful if you can just change header and menu with it, and not timeline, for example. SO I guess it would have to be done in one go. Between two releases of cvstrac , that is, and that doesn't have to be short time at all : )

Browsers cache CSS so it is being resent to browser only once in a while. For that reason I'm for a "global" CSS, that is, one CSS for whole cvstrac . And even that would probably be less then 20kB for default CSS.

  Obviously there's a need for infrastructure

I'm not sure what exactly you mean by this, but as far as I can see there are no big problems here.
Here's how I see that CSS infrastructure. Since cvstrac can't serve files from local file system, this would obviously had to be kept in db. We'd need a page to upload CSS to db. We could also strip white space while we're at it and that would reduce CSS size for some good 10-20%. Sending this "file" from db to browser is already implemented for attachments, so no problem here.

I'm just wondering about BC. what is the goal of cvstrac in this regard? How far back do we have to look? What about text browsers? De we even care about them? I know I don't : )

Use of layers also depends on our BC strategy I guess. Those things don't really work on older browsers and they were buggy for some time, and still are to some extent.
What I'm trying to say is, it was easy to have good cross browser compatibility with current cvstrac use of HTML. But it would be pretty hard if not impossible to make cvstrac work with all browsers that it does now when layers and CSS are introduced. Perhaps tables+CSS would be good compromise, but it is a compromise .

Personally, I don't really care about BC since I use Firefox all the time. But if we know that there is some big user base with older browsers (from last century : ) out there, we might need to take them into consideration here.

I'd really like to know where do we stand in regard to this BC stuff?

2005-Aug-26 11:30:09 by anonymous:
Yes, it's better to strip down to minimal HTML - far better. I never could get rid of the margin around the top table, for instance, and have the page flush with my layout (left ugly white gaps).

"action" and "whoami" can be placed in content and nav, but I'll have to see where they are generated...

I think a balance can be struck where a minimal CSS can be included (and edited via the current layout editing options) that looks just like the current markup regardless of browser - just about any browser can display background colors and bulleted lists on baseline CSS, and cvstrac doesn't need much more (except the reports table, for which I have no easy solution yet).

Targeting Firefox (and keeping the fancy trickery down) would be a nice way to ensure it works properly on most browsers (including IE, Safari, etc.), and advanced customizations can simply attach a JavaScript/extra CSS files to the Wiki and reference them from the HEAD tag. Worked for me :)


2005-Aug-26 11:36:15 by anonymous:
Here's something that could be adapted for a compact timeline view, for instance (drilling down from the date to a check-in, to a list of files, etc.):


2005-Aug-26 14:21:29 by cpb:
I may have to write up a CvstracRoadMap at some point, but for now I'll just shotgun out some comments...

0. No arguments from me on the advantages of CSS.

1. "all or nothing" is a bad situation to get into, especially when talking about something that going to touch as much code as a full CSS conversion. It's important that at any point in time, CVSTrac builds and runs as a useful product. Hence any "all or nothing" conversion happens in a branch and at some point there's a brutal merge back into HEAD. I'd prefer to take things incrementally, even if that may not be the most efficient approach.

2. That's basically what I mean by "infrastructure". A way to administer and serve up stylesheets. This needs to be planned out before anything else because I'm already seeing multiple paths. You're thinking "one stylesheet to rule them" (my preference too), RuiCarmo is talking about a minimalist CSS with optional add-on sheets in the header attached to Wiki pages (or maybe that's just how he hacks around it now?). I'd hope that a sane infrastructure wouldn't involve Wiki attachments, but my understanding on CSS is that supporting multiple stylesheets is a Good Thing.

3. My philosophy on browser compatibility (which may differ from drh)... If someone is in a situation so insane that they can't run a CSS-compatible (for some definition of "compatible") browser, I'm guessing that being able to access CVSTrac isn't a high priority. People doing stuff with lynx and such are probably better off building tools directly around the the SQLite database. Anyhow, if we're generating clean HTML I'd hope older browsers would degrade acceptably enough to be functional, although CVSTrac wouldn't look as good on them as it does now.

4. As to what kind of CSS... I'd rather see CVSTrac output the simplest HTML possible and move the complexity to the stylesheet. In other words, try to get rid of table magic. On the other hand, it'd be nice if the default stylesheet is simple enough that compatibility isn't really a big deal. It sounds like this is feasible, except for the reports.

5. No JavaScript in the defaults. Please.

6. compact timeline view Sweet, from a functional viewpoint. Have to watch the scalability, though. It seems to have included all the data for the drilldown in the one page. Try that with, say, the browse view and those of us with 12000 files in our CVS repositories won't be too happy. For a timeline view, it would be okay where it doesn't bloat things, but my 30 day timeline is already cracking 100k...

2005-Aug-26 15:33:44 by chorlya:

  I may have to write up a CvstracRoadMap at some point, ...

I was just about to propose a similar thing. I don't' really have much time now, but it would be nice to have at least a few bigger things on that roadmap.

A few quick remarks to your comments:

1. I meant that it would be best if we don't release any official versions with partial support for CSS. I agree that CVS code should always compile and run properly.

2. I don't really see any big advantage to having multiple stylesheets. RuiCarmo would you care to elaborate as to why this is good?

3. Basically I agree. Though it would be nice to know where exactly our baseline is. IE4 + NS4?

4. Yes, getting rid of tables would be nice. But trying to emulate tables with <div>'s can be tricky, even with modern browsers. Though it is being done every day, so I guess we'll just have to try and see how good/bad it is. When I say try, I mean try it on a plain HTML file of course. Integrating it into C code is the last thing to do here. Actually I'd like to have all pages as plain HTML first.

5. Agreed.

6. Since we agree that javascript is a no-no, I don't see how above proposed compact view can be implemented?
I'd expect timeline to greatly benefit from CSS integration so timeline as it is now will decrease in size considerably.

2005-Aug-26 15:44:27 by cpb:

  I don't really see any big advantage to having
  multiple stylesheets.

Supporting different display devices, mainly. For example, for a PDA you might want to represent the navigation bar as a space-saving popdown menu and not even display the title section (since the browser has a title bar). On the other hand, navigation isn't needed at all if you're printing a report.

  I don't see how above proposed compact view can be implemented?

I wouldn't see it as a default. The default CSS should be functionally and visually as close to the existing HTML as possible. But it's worth structuring the HTML such that this sort of thing might be possible. I could see a timeline where each day can be collapsed down as useful.

Although... including all the data in a timeline and using toggles to turn elements on and off in the display would mean larger pages, but may cut down on the number of hits on a server. It would also simplify the code for the timeline generation.

2005-Aug-26 17:00:17 by chorlya:

  Supporting different display devices, mainly.

I know next to nothing about PDAs so I can't comment here. But as far as screen vs. print goes @media screen { and @media print { worked very well for me up till now. Perhaps there is a similar @media for PDAs?
If we decide to go for multiple stylesheets, how do we detect what stylesheet needs to be loaded?

I agree about the timeline. As long as we keep the default as it is now, I'm happy : )

2007-May-08 09:10:17 by anonymous:
Another vote for changing all the html into something nice and simple and semantic - i.e. getting rid of things like <big> and <small> and some tables etc - and using <div> and <span> wrappers where appropriate, generally with "id" or "class" attributes as approriate so we can easily style the output. It'd also make the source a bit cleaner.

An example of the kind of change we made:

  <     @ <small><a href="logout" title="Logout %h(g.zUser)">Logged in</a> as
  >     @ <div id="bbc_is_logged_in">
  >     @ <a href="logout" title="Logout %h(g.zUser)">Logged in</a> as

We added a few other dov/spans of varying classes and ids and additionally referenced our own stylesheet.

2007-May-08 13:55:44 by cpb:
This is what's currently in HEAD for the login section:

  <p id="identity">
  <a href="logout" title="Logout cpb">Logged in</a> as
  <a class="user" href="wiki?p=cpb">cpb</a></p>

I can see where it'd be worth adding a class the the <p> to differentiate between logged in and out. Putting actual user ids into the CSS... Not sure about that. I guess you could do some neat things like show a mugshot for the user when they're logged in.

2007-Oct-18 00:44:42 by anonymous:
Is there an expected completion date for this? The checkins make it look like the priority has fallen off. I'd love this feature to be implemented because it's one more chance to compete with Trac. Nothing against Trac, but I prefer CVSTrac because it give better performance and is a lot easier to administer. I'd like to be able to package something up for customers that's as pretty as Trac but has CVSTrac's speed.

2007-Oct-18 01:18:21 by cpb:

  > Is there an expected completion date for this?

Not really. The "core" is complete in that basic page layout (headers, footers, menus and various wiki markup elements) can use CSS. The timeline is mostly done, although I don't particularly like how it works. I've done some work with alternate stylesheets which demonstrate that it's possible to dramatically alter the look of CVSTrac. Details like the file browser, ticket layouts, etc, however... they're going to be a while.

  > The checkins make it look like the priority has fallen off.

Very. To quote Her Majesty, it has turned out to be an Annus Horribilis. I've been able to manage bug fixes and small bits of functionality, but further battles with CSS have definitely been low priority.

484 new active 2005 Sep anonymous cvstrac 2005 Sep drh 5 2 Please increase the rows and cols of the textarea in ticket page edit
rows="20" cols="100" is preferred.

Or add function let user set them by himself.

Because when I write more lines, the small textarea makes me feel as look through a small window to the outsider.


598 new active 2006 Apr anonymous cvstrac 2006 Apr   5 2 Add pagination display function to browsing tickets edit
I create many tickets, i want to browse these tickets on pagination display mode. Can you add pagination display function to browsing tickets?
2006-Apr-11 00:17:40 by cpb:
The attached patch works and it's quite simple. But I'm not really convinced that it's any better than the timeline, however.

2006-Apr-11 00:31:28 by cpb:
In the name of consistency, it would make sense to add this to check-ins, too.
Rows: 34