Re: loginfo log message problem on windows tkcvs

[Derek Price]

Robert Feller wrote:

>--- Derek Price <address@hidden> wrote:
>  
>
>>Robert Feller wrote:
>>
>>    
>>
>>>The problem comes when I try to commit from
>>>TkCVS on Windows.  Apparently nothing is getting
>>>passed to STDIN in this case.
>>>      
>>>
>
>  
>
>>What is your $CVSROOT?  Are you accessing your
>>repository via some
>>shared network drive rather than going through a
>>central CVS server? 
>>This is not recommended.  It sounds like the command
>>in your
>>CVSROOT/loginfo file doesn't mean the same thing on
>>Windows as it does
>>on UNIX, which really isn't a big suprise.
>>    
>>
>
>Hi Derek,
>
>This problem is solved now -- it was due to a
>Window/Cygwin mismatch between my cvs.exe and Tcl/Tk
>libraries.  Once I compiled them both on Cygwin, my
>problem went away.
>  
>

Which gives your CVS executable UNIX semantics on Windows and works as
expected.

>My repository is on a network appliance server (NAS)
>that is accessible from both Windows and UNIX. 
>Previously, I had my repository on UNIX, and used ssh
>to access it from Windows.  I switched to NAS due to
>the lousy performance I had previously on Windows
>(each cvs command had to go through ssh).  Are you
>saying my current setup is not recommended?
>  
>

Yes, I am.  All sorts of problems crop up when accessing CVS
repositories on network shares, ranging from broken directory locking,
which can lead to lost data and corrupt repository archives, to
corruption due to incompatible network files system clients and servers
causing corrupt archives which aren't noticed until you cannot retrieve
old versions of your project.

I'm not saying that it is impossible to get this to work right.  I
expect some people have managed, but I am saying you should expect all
sorts of problems may crop up if you don't already know what you are
getting into and haven't tested your current setup extensively.

It is probable that most major damage can be avoided by frequently
backing up your repository to tape, but keep in mind that a corrupt
archive can appear to work indefinitely, with corruption not becoming
noticeable until someone tries to retrieve an old version of the
project.  In such a case, you might have to retrieve a years-old backup
to reconstruct broken files.  *This* problem can be mitigated by running
something like the contrib/validate_repo script distributed with CVS
once a week to look for signs of corruption.

Of course, if the problem turns out to be with locking, the risk of
overwriting someone else's changes increases quickly with the number of
developers and using the network share may become too much of a pain in
the neck even the second or third time someone does this without noticing.

Regards,

Derek

-- 
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:address@hidden>