Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Am 07.05.2007 um 13:55 schrieb Tony Hoyle: > Jens Miltner wrote: >> Hi, >> >> is the timestamp in the history file written as GMT or as local time? > > Everything internally in cvsnt is GMT (well, UTC actually). Output is > generally UTC unless the command supports an option to switch to local > time (log -T, etc.) > > Date parameters are local time historically. > > This is unchanged from standard CVS.. from the cvs manual > (http://ximbiot.com/cvs/manual/cvs-1.11.19/cvs_16.html#SEC117) > > "The date is interpreted as being in the local timezone, unless a > specific timezone is specified." Ok - thanks for this clarification. > >> The reason I'm asking is that I'm using cvstrac (http:// >> www.cvstrac.org) >> to track cvs commits, but every now and then cvstrac will fail to >> retrieve the commit information, basically because rlog won't list >> any >> commits in the time window requested. > > That's a very inefficient way of doing it - rlog is about the slowest > (and most memory inneficient) command it's possible to execute as it > requires parsing the entire rcs file for each file it references. OK > for a single user but I really wouldn't recommend using that when more > than one user is using the system. Well, cvstrac only does this when updating the history. It then reads those commits that haven't been processed before and caches them in an sqlite database. This mechanism is independent of the source control system used, but because things are cached, it's not that terrible performance-wise ;-) > > You could probably achieve what you want with audit and/or the email > plugins. Failing that a simple commitinfo/loginfo script. I agree that would be the best approach for a cvsnt-only solution, but as I mentioned above, cvstrac can work independently of the underlying source control... Anyway, I believe that cvstrac's conversion to gmt before using strftime is incorrect, since this date/time string is then used as a commandline argument, which apparently is supposed to be local time. Only I'm not sure why this never failed when we used the "stock" cvs server... </jum>