info-cvs
[Top][All Lists]
Advanced

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

Re: Question


From: Pierre Asselin
Subject: Re: Question
Date: Sun, 26 Sep 2004 15:51:09 +0000 (UTC)
User-agent: tin/1.6.1-20030810 ("Mingulay") (UNIX) (NetBSD/1.5.4_ALPHA (i386))

Gleidson S? Barreto <address@hidden> wrote:

> 1-To take place the transfer of the files stored in
> the repository q they were modified for your work
> area, through a sicroniza??o operation. Like this,
> would to be in fact that sicroniza??o operation? 

I'm not sure what you mean, but...  Synchronization in both direction
has to be requested explicitly, by running a command.  "cvs update" to
receive changes made by others, and "cvs commit" to send changes made
by you.


> 2-CVS counts with a mechanism capable to control the
> simultaneous accesses and the parallel modifications,
> guaranteeing like this the integrity of the
> modifications and atomicity of the operations. Would 
> be in fact that atomicity of operations? 

If I remember correctly, commits are atomic within any one directory
but are not atomic across entire hierarchies.  Commits are certainly
atomic on a file by file basis, so you do not get corrupted files.

The lack of atomicity occurs when a developers performs an update
(receive) while another developer performs a commit (send).  The
receiving developer may get an inconsistent snapshot with some files
just before their commit and some other files just after the commit.
The workaround is to repeat the update.  It would be a little
difficult to notice in practice, because when working on an active
project one has to update many times every day.  Also, the trunk
tends to be somewhat unstable since it is being actively modified.


> 3-CVS possesses mechanism capable to identify and to
> solve conflicts. However those identified conflicts
> are merely textual, not existing any analysis of the
> logical consistence. Here I didn't understand the
> expression textual conflicts very well. 

A "textual" conflict occurs when two people modified lines at overlapping
locations in a file, or at nearly overlapping locations (~3 lines
apart or so).  These conflicts have to be resolved manually.

Modifications in distant parts of the file are accepted uncritically.
You are correct that this could introduce logical errors in the merged
file;  the amazing thing is that it almost never does, because of the
way people write software.

In any case, cvs always gives you backup copies of the two conflicting
versions of the file.

-- 
pa at panix dot com


reply via email to

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