We are using svn in version-1.3.0 for our repository.
Some files in the repository are using the 'svn:keywors' property,
where especially the keyword 'Id' (and sometines 'Rev') is used.
In some of the files this property was now removed for some internal
Doing a merge in our svn repository now, we came across the following
Merging a file where the 'svn:keywors' attribute was revoked ends up in
when using svn 1.3.0 (state 'CU').
Using svn-1.1.4 succesfully results in state 'UU'.
A simple scenario for getting this problem (The four bash-variables must
be set or replaced to use this code as script):
#Checkout the base
svn co $URL
#Create a directory
svn mkdir test
#Put a file in there
echo -e "#Test\n#$Id$\n#End of test\n\na single line" >> test/file
svn add test/file
svn ps svn:keywords Id test/file
#Commit the dir and it's file
svn ci -m "Initial state"
#Now make a 'branch' by creting a copy of the folder
svn cp test test1
#Let the revision after commit be '$A'
#Change file in both branches
#In 'test' add a line after header
echo -e "#Test\n#$Id$\n#End of test\n#Another line in source-header\n\na
single line" >> test/file
svn ci test -m "Changing source file"
#in 'test1' elsewhere so that there won't be a conflict, revoke Id and
remove it's line from file
echo -e "#Test\n#End of test\n\na single line\nanother line in dest" >>
svn pd svn:keywords test1/file
svn ci test1 -m "Changing destination and revoking Id"
#Let the revision after commit be '$B'
#Both WCs should be up to date now
#OK - now we apply changes of the source file to destination
#Merge from the above marked revisions into a working copy of test1
#This should add the additinal header line to test1
svn merge -r $A:$B $URL/test test1
svn ci test1 -m "Updating destination"
#Up to this point everything was ok - now we sync source and destination
#This should remove the Id line and add the destination line below
svn merge $URL/test $URL/test1 test
svn rm test test1
svn ci -m "Cleaning up."
Using svn 1.3.0 should lead to
Using svn 1.1.4 should lead to
The conflict produced by 1.3.0 looks like that:
$Id: file 2031 2006-03-15 10:35:15Z repadmin $
The rest of the file was successfully merged.
Trying to find a solution without manual interaction, I figured out,
that leaving the line containing the '$Id$' doesn't solve the problem.
Unfortunately I didn't find any solution without downgrading the client yet.
Resolving the problem causes problem on further merges:
Let there be a folder 'test2' copied from 'test' before the changes of
'test1' have been merged.
If you do a merge from 'test' to 'test2' just after 'test1' has merged
and conflicts have been resolved, this folder will have the same
Is this an expected behaviour?
Neumeyerstrasse 48 | D-90411 Nürnberg
T +49 911 2526 249
F +49 911 2526 241
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Thu Mar 16 20:10:45 2006