Erik Huelsmann <ehuels@gmail.com> writes:
> 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.
Thank you!
(This is exactly the mail I've been waiting for... :-) ).
> 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.
Wednesday evening should be right after the first 1.3 RC tarball,
which would work out well.
> [Fortunately, much of the development work has been done on Windows,
> meaning that the expected slew of Windows breakage problems hopefully
> has been avoided.]
This is good news indeed.
> 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.
*nod* I see this is done using a new ".svn-revert" suffix.
> 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
> finalized.
>
>
> 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!
I will try to do so before Wednesday; if I can't manage that, I will
at least review it when it merges! Thanks for the explanation.
It's an impressive body of work over there. My hat goes off to you
and zhakov.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 23:11:12 2005