[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hash.c.312: findnode:
From: |
Manu |
Subject: |
Re: hash.c.312: findnode: |
Date: |
Sat, 25 Jan 2003 01:29:50 +0100 |
Pierre Asselin wrote:
>>Manu wrote:
>>"cvs update" gives:
>>nothing known about lib/Makefile
>>nothing know about src/Makefile
>
>>Seems that cvs corrupted my repository,
>
>Or your working copy. Try editing the CVS/Entries file manually in
>Notepad or Wordpad. Do the entries have the correct case?
I checked out a brand new copy of my repository.
There is no entry for lib/makefile, src/makefile, lib/Makefile, src/Makefile,
*/makefile are no longer in the repository and */Makefile are not in yet.
:) Little summary:
1. Original files in the repository:
lib/makefile
src/makefile
winui/src/makefile
2. Misc attempts to "cvs add lib/Makefile src/Makefile" &&
"cvs commit".
I think I never tried "cvs add winui/src/Makefile", this is why
I have no troubles with that one.
3. The three original files were manually removed by SF.net team.
4. I had no troubles to "cvs add winui/src/Makefile" &&
"cvs commit".
OTOH, I receive the same error message when trying to commit
"lib/Makefile src/Makefile", despite the fact that original files no
longer exist, and that new ones don't exist yet.
I think something wrong occurred with my repository, when
I performed step (2).
>If you're worried about your repository state, check out a new sandbox
>somewhere else, you'll see (indirectly) what files are in the repository
>and what case they have. Do a "cvs update -r1.1" if necessary to retrieve
>any files in the Attic.
The only makefile in my repository is now the brand new "winui/src/Makefile".
>>[ ... ]
>>IMO, this is a serious issue.
>
>Yes, but what to do about it? It's an OS issue as much as anything else.
I understand that developers can't test softwares under any OS, OTOH
maybe end users would like to fix specific bugs, but don't have the needed
knowledge to do that.
I don't have much knowledge about the SSH protocol and how a cvs
client exchanges with a server.
>Maybe the Windows clients could be bullet-proofed to detect the problem
>and work around it, I don't know. The clients certainly control the
>case of the strings they send to the server, and I think they can ask
>the server what it has in its repository.
Spying the client/server server/client exchanges could give good info.
Maybe a few printf() added....
>I don't really understand the problem since I'm not a Windows programmer
>and I don't know the API or semantics of the filesystem interface.
Fortunately, GNU softwares are written in C, and therefore are very portable,
even under Dirty OS. (DOS :)
Most of the time, when porting to Windows, there's no need to use Windows API.
Most functions are C ANSI, some Unix functions were implemented under
W*n32, some other requires a few hacking.
mkdir() takes only one arg, open() suits for files, not directories, etc...
To "./configure && make" cvs-1.11.2 and 1.11.5 for MSYS, (a POSIX layer
for W*n32) see the very little hack I had to do:
diff -rup -x *.o cvs-1.11.2-orig/lib/savecwd.c cvs-1.11.2-msys/lib/savecwd.c
--- cvs-1.11.2-orig/lib/savecwd.c Mon Jul 10 20:45:04 2000
+++ cvs-1.11.2-msys/lib/savecwd.c Fri Dec 20 00:21:22 2002
@@ -57,7 +57,7 @@ save_cwd (cwd)
if (have_working_fchdir)
{
-#ifdef HAVE_FCHDIR
+#if defined(HAVE_FCHDIR) && !defined(__MSYS__)
cwd->desc = open (".", O_RDONLY);
if (cwd->desc < 0)
{
But, this is OT... Well, I'll try to understand things and who knows,
maybe one day, I will succeed to fix that problem.
At least, as the topic says, I know where the problem occurs :)
Manu.