[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Thanks For Info: CVS Import Bug Resolved

From: Oproescu Bogdan (KTXA 3)
Subject: Thanks For Info: CVS Import Bug Resolved
Date: Thu, 1 Sep 2005 17:03:26 +0200

   Hello Derek, 

   Thanks for your prompt reply below: I will regularly 
   check the Binary Downloads page on www.cvshome.org 
   and wait for these builds. Maybe someone updating 
   this page can also send me an email when these 
   new binaries are created and added here. 

   Thanks and Cheers, Bogdan 

   Bogdan Oproescu   

   Technology & Services
   Advanced Middleware &
   Development Environments KTXA 3 
   Postfach 600
   CH-8070 Z├╝rich
   Tel.: +41 1 334 6846
   Fax.:+41 1 332 8024
   E-Mail: bogdan.oproescu@credit-suisse.ch
   Internet: http://www.credit-suisse.ch/de/index.html

-----Original Message-----
From: Derek Price [mailto:derek@ximbiot.com] 
Sent: Thursday, September 01, 2005 4:48 PM
To: Oproescu Bogdan (KTXA 3)
Cc: lawrence.jones@ugs.com; bug-cvs@nongnu.org; berndj@prism.co.za
Subject: Re: Next Steps: CVS Import Bug Resolved

Oproescu Bogdan (KTXA 3) wrote:

>   1. When can we download both binaries for the 
>   new CVS Release for the: 
>       1. CVS Client on Windows XP, and: 
>       2. CVS Server on Solaris 8.0? 
>   I have looked briefly on the Download CVS Binaries 
>   page on www.cvshome.org and I see that the latest 
>   builds are from April 18, 2005, by Derek Price. 
>   So, approximately when do you estimate you can 
>   post these new binaries on these pages? 

Those binary builds are generally posted soon after a CVS release.  As
for the 1.11.21 & 1.12.13 release schedule, I don't believe there are
current plans.  Releases generally happen either immediately after a
major security fix goes in or when somebody on the dev team decides
either there are enough changes or enough time has passed to justify a
new release.

>   2. For my curiosity, please tell me how your 
>   solution works: is it an entire directory lock, 
>   as Derek mentioned earlier, or have you implemented 
>   directory-at-a-time locking for this fix? 

Larry implemented directory-at-a-time locking, which will fix the
problem.  It would be nice to see promotable locks on feature  for the
entire set of directories being committed, as happens with commit, but
this won't affect the data-loss issue.



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

reply via email to

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