[Top][All Lists]

[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:

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)
+#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 :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]