Hi Bill.

Didn't have any luck with that either (see below).  Does it work for 
you? Any idea what the message about the CVS locks means / how to fix it?

Yeah, I see what you mean re: files in the attic.  I'm curious how 
things looked before I started changing things, to better understand 
what caused this code collision...

-Dan

Here's what I got when I tried to do the -r thing:

[dan@oogie tmp]$ echo $CVSROOT
:ext:[EMAIL PROTECTED]:/home/cvs

[dan@oogie tmp]$ cvs co -r tomcat_4_1_2 jakarta-tomcat-4.0
Protocol error: uncounted data discarded

Bill Barker wrote:

>"-r tomcat_4_1_2" should work.  You could also "add" the files back from the
>Attic, since it's a completely different directory.
>----- Original Message -----
>From: "Dan Sandberg" <[EMAIL PROTECTED]>
>To: "Tomcat Developers List" <[EMAIL PROTECTED]>
>Sent: Monday, July 01, 2002 4:25 PM
>Subject: Re: [PATCH] Re: SSI Servlet has big problems
>
>
>  
>
>>I'm trying to checkout an old version of tomcat with the following
>>    
>>
>command:
>  
>
>>[dan@oogie tmp]$ cvs co -D "4 months ago" jakarta-tomcat-4.0
>>
>>And I'm getting the following error:
>>
>>Core dumped; preserving /tmp/cvs-serv41751 on server.
>>CVS locks may need cleaning up.
>>
>>My version is (on Linux):
>>
>> >[dan@oogie tmp]$ cvs --version
>> >
>> >Concurrent Versions System (CVS) 1.11.1p1 (client/server)
>>
>>I tried the same thing on Solaris, and had the same problem.
>>
>>Any idea?  Am I doing something stupid?
>>
>>-Dan
>>
>>Dan Sandberg wrote:
>>
>>    
>>
>>>Yes, let's merge them together.  How do I get to the code that you
>>>fixed?  Were the test cases in CVS?
>>>
>>>I'd say lets get all the test cases setup, and see where my code fails
>>>your tests.  Then we can use your code wherever functionality is
>>>      
>>>
>missing.
>  
>
>>>I thought I had checked out the head revision.  Did I make a mistake
>>>with the cvs check out command?
>>>
>>>-Dan
>>>
>>>Paul Speed wrote:
>>>
>>>      
>>>
>>>>(Resending from my older address in hopes that it will help avoid
>>>>some confusion.)
>>>>
>>>>Hmmm...
>>>>
>>>>This is what I get for ignoring the list for a while. ;)
>>>>
>>>>Note: I completely rewrote the SSI support in 4.x HEAD and had Bip
>>>>apply the patches (Amy also did some patching) for exactly the same
>>>>reasons you originally mention.  I did this around Oct/Nov 2001.  On
>>>>most of the 4.0 bug reports for SSI (which I agree was a bad
>>>>implementation on that branch) I commented that my changes should
>>>>probably have been back-ported from head.
>>>>
>>>>I even had test cases for all of the SSI commands, including the
>>>>conditionals which I added support for.
>>>>
>>>>My only guess is that you were looking at an older version when finding
>>>>the problem.  My rewrite solved all of these problems and was
>>>>completely compatible with all mod_include commands except for the
>>>>regex stuff.
>>>>
>>>>Of course, now it seems that my version has been completely blown
>>>>away.  Which is unfortunate since that means we lose conditionals...
>>>>and possibly some of the more esoteric nesting behavior that I copied
>>>>from Apache (I haven't tested this yet.)
>>>>
>>>>It's too bad that SSI on head was blown away for changes to an older
>>>>version.  Any chance we can nicely merge the two good versions into
>>>>one more good version?
>>>>
>>>>-Paul Speed
>>>>        
>>>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>    
>>
><mailto:[EMAIL PROTECTED]>
>  
>
>>For additional commands, e-mail:
>>    
>>
><mailto:[EMAIL PROTECTED]>
>  
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>  
>




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to