cvstrac - Showstoppers

  nl_langinfo(CODESET

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.

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" :-(((

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

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

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 http://cvsbook.red-bean.com/cvsbook.html#The%20Fast%20Method%20Of%20Reverting

  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.

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.

  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.

  ... 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.

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.

  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 cvstrac_chngsync.pl, 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.

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

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

this should be changed to:

  void common_about(void){
    login_check_credentials();
    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.

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

invalid reference to removed variable 'azLink'

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

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).

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 root@turingstudio.com.

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.

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, asp.net, ...) 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?

• 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.

Se agrego una linea a la descripcion

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.

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.

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.

  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?!?

  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.

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

I have set up "Mantis" (http://www.mantisbt.org/) 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.

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.

cvstrac.exe cgi

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

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.

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

  --- LDAP.pm	2004/03/22 17:02:53	1.45
  +++ LDAP.pm	2004/04/21 21:40:23	1.45.2.1

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.

  ----------------------------
  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.

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;
  1078099200

• 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.

--Derek

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 <ebecker@software-manufaktur.de>

For example look at this report: http://www.cvstrac.org/cvstrac/rptview?rn=23

Looks like an unititalized variable.

It would be nice to have configuration option for output encoding

Expected:

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

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.

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

  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.

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

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.

  > 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...

  > 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
  or
  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"

   #ifdef CVSTRAC_WINDOWS
     /* Microsoft IIS doesn't define REQUEST_URI variable,

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

URI: /proj.trac/dirview

SCRIPT_NAME: /proj.trac

PATH_INFO: /dirview

The

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

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

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.

  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 ){

to

  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

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

     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.

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

I could certainly use this sort of thing...

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.

• 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.

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

(test)

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 <anselm.lingnau@linupfront.de>

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

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

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

Bye, Bjoern

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.

RuiCarmo

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).

Ideally, CVStrac should have a layout like so:

  <body>
  <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>
  </body>

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...

  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"?

• 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?

"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 :)

RuiCarmo

http://www.alistapart.com/d/complexdynamiclists/finder.html

RuiCarmo

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...

  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.

  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.

  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 : )

An example of the kind of change we made:

  389c390,391
  <     @ <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.

  <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.

  > 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.

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.

thanks.