Date: Mon, 8 Jul 2002 11:26:08 -0400 From: Khachaturov Vassilii <Vassilii.Khachaturov@comverse.com> To: "'Ville Skytta'" <scop@FreeBSD.org> Cc: "'cvsweb development'" <freebsd-cvsweb@FreeBSD.org> Subject: RE: FW: [PATCH] fileSortCmp() should properly weed out rogue non- dir files Message-ID: <6B1DF6EEBA51D31182F200902740436803B24BBA@mail-in.comverse.com>
next in thread | raw e-mail | index | archive | help
> Both are fine with me, but it seems inlining works better with the > archives as you already noticed. :-( Unfortunately, the inlining doesn't work quite well - I just checked the archives, and saw broken lines and things like =20 in the archived message text... I will use both at the same time next time - one for easy application of the patch by whoever needs it and the other for those who want to read it off the archive. > Could you shed a bit more light on this, I can't verify the problem > here. I'm unable to get non-,v files in the repo dirs to show up in > CVSweb's directory listings or the sort orders to break... The rogue files never show in the directory listings by CVSweb, but they do get fed to the comparison routine. In our CVS repository directories, the rogue files (report files by a proprietary legacy release report system co-existing with it) are named starting with an underline (which puts them betw. capital and lowercase-starting filenames). If both (cap. and low-case-starting files) are present in the repository, and if the sort order is not name-base (but, e.g., date-based), then we consistently have the sort order randomly broken (because the sorting routine discovers no rlog-generated info on the rogue files cached and resorts to name-based comparison when asked to compare between a rogue and real file.) Imagine, e.g., two files: Foo (modified in 2000) and bar (modified in 1999) Name-based comparison orders them as (Foo, bar). Date-based comparison - as (bar, Foo). Suppose that also a file Now imagine that the sort routine gets invoked on (Foo, _rogue) and (bar, _rogue). The partial order that it will infer will be (Foo, _rogue, bar), regardless of the actual sort order selected. So, if the sort order was date-based, this will break the consistency of the partial order built by the perl sort algorithm, and the results will be ordered badly. The patch will force the rogue files always to be "greater" than real ones, so that comparisons with them won't be possible to be used by the perl sort outer algorithm to infer the partial order between the real ones. Please apply, Vassilii To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-cvsweb" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B1DF6EEBA51D31182F200902740436803B24BBA>