[OpenAFS-devel] Re: [OpenAFS-devel] volume-dont-artificially-untimeout-vlservers-20061218 updated?

Jeffrey Hutzelman jhutz@cmu.edu
Tue, 30 Jan 2007 18:35:24 -0500


On Friday, January 26, 2007 04:44:05 PM -0500 Christopher Allen Wing 
<wingc@engin.umich.edu> wrote:

> I think that the botched version of the CVS delta:
>
>  	volume-dont-artificially-untimeout-vlservers-20061218
>
> is crashing some of our AFS clients.  I noticed that the fixed version of
> this patch made it into CVS yesterday.

This doesn't surprise me much; I suspected that this might cause issues for 
any client which actually saw a vlserver go down.  Fortunately, we had the 
chance to fix it before 1.4.3 final.  I'm glad there are people out there 
deploying release candidates.



> My question is, why doesn't the delta name change in this case?

Because the gatekeepers chose to treat it as part of the same delta. 
Personally, I wish they wouldn't do this, especially when there's a release 
in between.  It also confuses wdelta and some other tools if there happen 
to have been any other commits to the affected files between the two parts 
of the delta.



  It's
> somewhat confusing when looking through CVS e.g. with the wdelta web
> interface on the openafs.org web site.  I see that the correction was
> made yesterday but the web interface for listing deltas:
>
>  	http://www.openafs.org/cgi-bin/wdelta/MAIN/index/month/openafs
>
> only shows the delta first being entered last year, not the recent
> update. Maybe it's possible to get the web interface to list deltas
> sorted by most recent update instead?

Currently, wdelta's sort-by-date uses the timestamp that is part of the 
delta name.  Most of the time, this works fine.  Actually using the 
timestamp of the last commit would be harder, because we'd have to inspect 
the CVS data for each affected file to find the timestamps.  I'll look into 
it, but no promises at this point.

-- Jeff