To note, CVS is a little more intelligent about this than people assume
(given the mentions of checks like md5).
*sets up an example repository*
[root(2)@dreadnought exampd]# cvs -d
:pserver:bob@cvs.saurik.com:/cvs/bob co -d bob1 bob
cvs server: Updating bob1
[root(2)@dreadnought exampd]# cvs -d
:pserver:bob@cvs.saurik.com:/cvs/bob co -d bob2 bob
cvs server: Updating bob2
[root(2)@dreadnought exampd]# cd bob1
[root(2)@dreadnought bob1]# echo "hello
> there
> today
> and
> tomorrow" > file1
[root(2)@dreadnought bob1]# cvs add file1
cvs server: scheduling file `file1' for addition
cvs server: use 'cvs commit' to add this file permanently
[root(2)@dreadnought bob1]# cvs commit -m "file1 is god"
cvs commit: Examining .
RCS file: /cvs/bob/bob/file1,v
done
Checking in file1;
/cvs/bob/bob/file1,v <-- file1
initial revision: 1.1
done
[root(2)@dreadnought bob1]# cd ../bob2
[root(2)@dreadnought bob2]# cvs update -dPA
cvs server: Updating .
U file1
[root(2)@dreadnought bob2]# sed -e "s/today/forever/" < file1 > file2 &&
mv file2 file1
mv: overwrite `file1'? y
[root(2)@dreadnought bob2]# cvs commit -m "my file1 is the true god"
cvs commit: Examining .
Checking in file1;
/cvs/bob/bob/file1,v <-- file1
new revision: 1.2; previous revision: 1.1
done
[root(2)@dreadnought bob2]# cd ../bob1
[root(2)@dreadnought bob1]# sed -e "s/today/yesterday/" < file1 > file2
&& mv file2 file1
mv: overwrite `file1'? y
[root(2)@dreadnought bob1]# cvs update -dPA
cvs server: Updating .
RCS file: /cvs/bob/bob/file1,v
retrieving revision 1.1
retrieving revision 1.2
Merging differences between 1.1 and 1.2 into file1
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in file1
C file1
[root(2)@dreadnought bob1]# # orders some pizza
[root(2)@dreadnought bob1]# sed -e "s/tomorrow/never/" < file1 > file2
&& mv file2 file1
mv: overwrite `file1'? y
[root(2)@dreadnought bob1]# cvs commit -m "file1 kicks ass"
cvs commit: Examining .
cvs server: warning: file `file1' seems to still contain conflict
indicators
Checking in file1;
/cvs/bob/bob/file1,v <-- file1
new revision: 1.3; previous revision: 1.2
done
[root(2)@dreadnought bob1]#
OK, well, it could have been more intelligent in how it told me that :).
I could go through the process and make that a cvs update at the end to
make it more impressive, but I'm too lazy, hehe. The idea is that CVS
is actually looking for the conflict indicators rather than just
assuming that, as the file changed, it isn't conflicted. When you do an
update (instead of a commit, which you should be doing before the commit
anyway), this would be evident as a large line amidst a sea of small,
short ones (*sigh*...) and you'd notice that you shouldn't commit the
files yet.
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
-----Original Message-----
From: Daniel Berlin [mailto:dan@dberlin.org]
Sent: Wednesday, February 20, 2002 12:35 AM
To: Karl Fogel
Cc: dev@subversion.tigris.org
Subject: Re: conflicts, history, and the Principle Of Least Surprise
On 20 Feb 2002, Karl Fogel wrote:
>
> The conflict time is recorded in .svn/entries. At commit time, we
> error if the working file has not been modified since the conflict.
> Otherwise, we allow the commit, and automatically remove the other
> three files (which are just sitting in the working directory with
> intuitive extensions).
Time == bad
md5 == good.
Use md5 to detect the difference.
Record the md5 of the conflicted version.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:09 2006