[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Merging the wc-replacements branch

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2005-10-10 15:02:16 CEST

Ivan Zhakov and I have been working to get the wc-replacements branch
in shape the last month. (Thanks Zhakov!) Now that it's nearing
completion, I want to announce my/our plan.

The plan.
I have a last commit sitting in my working copy, which I plan to
commit tonight (fixing 'svn cp' with a symlink target). After that, I
want to let the branch sit until wednesday evening (my evening ==
CET), and merge the branch back to trunk.

[Fortunately, much of the development work has been done on Windows,
meaning that the expected slew of Windows breakage problems hopefully
has been avoided.]

What was the problem, again?
Our current working copy code (ie in trunk) breaks working copies when
it tries to version a replacement of a versioned {file,directory} with
another one which also has a versioning history. The last part
('which also has a versioning history') is important, since
replacements with non-versioned items works - at least for files -
without problems.

Technically, the problem was that there is 1 text-base file, but a
replacement of a versioned file with another versioned one, needs 2
text-bases: 1 for the replaced file in order to be able to revert, the
other for the replacing file, in order to 'svn diff' and send diffs to
the server on commit. The same goes for file-properties (in his case
for prop-bases).

The current working copy model will never be able to model inter
node-type replacements (file->directory vice versa), so this is not
part of the scope of the branch.

What was the purpose of the branch?
The purpose of the branch was to fix this broken behaviour. The
current broken behaviour was triggered with these svn commands:
- commit
- copy
- merge
- revert

With the fix chosen, 'svn rm' also had to be modified. ('svn rm
--force' of a 'R'eplaced file should result in a 'D'eleted file.)

What was the solution chosen?
The solution is to add a 'revert-base' extra text/prop-base file,
which can be used to revert the file to its clean state before the
replacement took place.

For directories, this is only an issue for the properties files, since
that's the only part of a directory which is actually replaced:
directories marked for deletion aren't deleted until the commit is

Branch status?
- All tests are running without failures on both Windows and Linux.
- The TODO document is to be updated (also due tonight).
- One more fix to be applied: 'svn cp <symlink target>'
- Tests have been extended to test the new functionality through merge,
  copy, commit and revert tests
- All 5 of the above commands have been extended to support this fixed behaviour

Please, review!


Received on Mon Oct 10 15:04:19 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.