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