Hi Greg,
Well, althought you seem to know the problem, I can't tell that you
understand where it comes from nor where it should be fixed. Let's see:
>That's only a problem with your search tools. If I'm not too far out of
>touch I seem to recall that the "Base" directory is within the CVS
>administrative sub-directory. So, you need to purposefully ignore the
>stuff in the CVS administrative directories.
No way! First CVS sets up the trap, and then the search tools are to blame?!
You must be kidding. Also, I am not using one single search tool, but few
different ones. Some of them can be modifed to filter the fake copies out,
some can't. The problem is created by CVS, and there is no reason to have
that feature (that is unedit without contact with the server) implemented
the way it cause me more trouble than benefits (I always have connection to
the server other the LAN, I don't need the Base directory at all!).
As I mentioned, there are two serious mistakes made with the contents of
'Base' directory. First one is to make a copy of the file with the exactly
same name (very bad practice) and second (even worse!) is to make that copy
writable. If there was only one of these things then it is OK. But combined
together became a deadly binary weapon, which may cost you lost of many
hours work. That also means that if just one of these (name or writable
attrib) are fixed then problem will be gradually reduced or gone. Can
anybody explain me WHY the copy made to the Base directory is wtitable? I
mean, you are not supposed to modify that file, right? It is a copy to be
recovered/restored, nothing to modify or compile etc, so WHY?
>Yes I know this is a bit of a pain and lead to all sorts of simlilar
>ugliness spread all throughout scripts and tools that build and manage
>sources, but it's an old and common problem and there are many old and
>common solutions to it already widely deployed. For example to generate
>a list of just the non-administrative files:
??? There should be one solution, in the CVS source. This is actaully almost
a BUG, if not the fact that it seems to be designed that way. But the design
is wrong, and it should be fixed.
I am on this list long enought to realize that it is all for nothing and it
won't be fixed anyway, no matter how many troubles it cause. I only raised
the issue to confirm that it is a problem and it should be fixed /
worked-around in my DevStudio addin. Since I can not make it fixed on the
official CVS side, I am fixing it locally in my addin. First I will make a
work around, but later on I might go to the source and modify cvs.exe and
distribute it fixed together. Not sure yet. But one thing I know - it is a
problem originating from CVS, do not blame search tools...
BR,
Jerzy
The first thing they don't teach you at school: "Never say never".
All the issues not related to the list please send to me in private, thanks.
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
