On Friday, January 26, 2007 04:44:05 PM -0500 Christopher Allen Wing
<[EMAIL PROTECTED]> 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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
