bug-cvs
[Top][All Lists]
Advanced

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

Re: Next Steps: CVS Import Bug - Solution Determination


From: Derek Price
Subject: Re: Next Steps: CVS Import Bug - Solution Determination
Date: Fri, 12 Aug 2005 13:58:42 -0400
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Oproescu Bogdan (KTXA 3) wrote:

> 
>
>   Hi Lawrence and all, 
>
>   Thanks for your message below. For your information, I tried parallel  
>   CVS Tags on the SAME Module and Repository pairs on our CVS Central Server, 
>   and that works correctly. I can reproduce File Corruption on CVS in only 
>   the following cases: 
>
>   1. Parallel "cvs import" and "cvs import" of SAME Module & Repository, and: 
>
>   2. Parallel "cvs import" and "cvs tag" on SAME Module & Repository. 
>
>   From our discussion so far, it seems the culprit is "cvs import", 
>   because it's currently non-locking, and if this were fixed, I am 
>   quite sure that the parallel "cvs import" and "cvs tag" would 
>   also work correctly. 
>
>   So, maybe your idea that you don't need to lock the entire directory tree 
>   for "cvs import" like you do for "cvs commit" is a good one. Maybe then the 
>   directory-at-a-time locking like for "cvs tag" will be sufficient to ensure 
>   the File Corruption Issue doesn't repeat itself.
>

As I think I made clear in the email I just sent, yes, Larry is correct:
directory-at-a-time locking should solve the import corruption problem. 
I believe locking the whole tree is The Right Thing (tm) to do, however,
since it more closely mimics atomic writes.

>In this case, can Derek's 
>   solution below be implemented in just one pass? ie. lock directory, import 
>   directory, release lock on directory.
>

Yes.

Regards,

Derek

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






reply via email to

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