bgcolor # Type Status Created By Subsys Changed Assigned Svr Pri Title _Description _Remarks #f2dcdc 253 new active 2003 Sep anonymous 2007 Aug drh 1 1 Changing commit logs in the repository 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:_ {linebreak} 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:_ {linebreak} 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 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. ---- _2005-Dec-22 09:53:58 by anonymous:_ {linebreak} 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:_ {linebreak} 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 {wiki: ExternalToolsCookbook external tools}. ---- _2007-Aug-04 12:03:31 by anonymous:_ {linebreak} 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 {link: attach_get/167/cvstrac_chngsync.pl message sync} hack using {wiki: ExternalToolsCookbook external tools}. I'm not against checkin synchronization (I'm not just the author of {link: attach_get/167/cvstrac_chngsync.pl 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 {link: http://fossil-scm.hwaci.com/ his thoughts} on SCM integration with CVSTrac-like tools. ---- _2007-Aug-05 05:35:38 by anonymous:_ {linebreak} 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:_ {linebreak} At http://cvstrac.pfsense.com/rlog?f=tools/builder_scripts/cvsup_current 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. #f2dcdc 294 doc active 2004 Mar anonymous 2004 Mar anonymous 1 1 Documentation on the CVS Repository 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 #f2dcdc 305 new active 2004 Apr anonymous cvstrac 2004 Apr lansil 1 1 css customization Is there scope for the site to be customized using css ? _2004-Apr-06 15:33:35 by anonymous:_ {linebreak} It is possible to add a style sheet by going to Setup => Headers & Footers. I use a header like this:
... |
...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:_ {linebreak} 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). RuiCarmo ---- _2005-Aug-25 20:42:17 by cpb:_ {linebreak} _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:_ {linebreak} 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: $title timeline and so 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 , 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:_ {linebreak} 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.{linebreak} 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.{linebreak} 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.{linebreak} 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:_ {linebreak} 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 :) RuiCarmo ---- _2005-Aug-26 11:36:15 by anonymous:_ {linebreak} 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.): http://www.alistapart.com/d/complexdynamiclists/finder.html RuiCarmo ---- _2005-Aug-26 14:21:29 by cpb:_ {linebreak} 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 '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?{linebreak} 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?{linebreak} 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:_ {linebreak} Another vote for changing all the html into something nice and simple and semantic - i.e. getting rid of things like and and some tables etc - and using and 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: 389c390,391 < @ Logged in as --- > @ > @ Logged in 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:_ {linebreak} This is what's currently in HEAD for the login section: I can see where it'd be worth adding a =class= the the 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:_ {linebreak} 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.
#f2dcdc 484 new active 2005 Sep anonymous cvstrac 2005 Sep drh 5 2 Please increase the rows and cols of the textarea in ticket page 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. thanks.
#f2dcdc 598 new active 2006 Apr anonymous cvstrac 2006 Apr 5 2 Add pagination display function to browsing tickets 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:_ {linebreak} 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:_ {linebreak} In the name of consistency, it would make sense to add this to check-ins, too.
#cacae5 343 code defer 2004 Aug anonymous cvstrac 2005 Dec drh 2 1 AUX filters in report not initialized properly 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: http://www.cvstrac.org/cvstrac/rptview?rn=23 Looks like an unititalized variable. _2004-Aug-18 15:10:05 by anonymous:_ {linebreak} The problem seems to be in the SqlLite function sqlite_mprintf. See: http://www.sqlite.org/cvstrac/tktview?tn=812
#cacae5 47 new defer 2002 Jun anonymous 2003 Jan 4 1 Cannot browse base versions 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 |