Re: Summary of Subversion tree-conflicts meeting

Would it help to take specific scenarios and map out the sort of
change that we might want to do? It seems like it could help
determine the scope of the effort. The one concern I had after our
meeting was that we focused a lot on the moment the problem occurs,
and what we could do to identify it, and not a lot on how this will
effect the workflow after the problem occurs.

Let me take one of the simpler scenarios and illustrate what I mean.
I think we might want to do this for more scenarios later.

Scenario: User has made local modifications to a file. Another user
has committed a rename of the file in the repository.

What happens today: User runs update. The new file name is added to
their working copy. Subversion wants to delete the old file name, but
since there are local modifications it instead just makes the file
unversioned. It is reported as a 'D'elete and 'A'dd in the console
output.

What should ideally happen: Subversion should move the local file to
the new name, and then update based on the repository file. The old
file would be deleted and the new named file would likely appear
modified when svn st is run.

What should "next best" happen: The 'D'elete file should be marked as
a 'C'onflict or some new designation. The original pristine version
of the file should be maintained so that the user can run svn diff to
create a patch and apply it to the moved file.

svn revert would remove the conflict and the pristine version, and
possibly delete the local file too.
svn add should remove the conflct, mark the file as scheduled add, and
replace the pristine copy.
svn resolved should probably report an error that it cannot do
anything. Maybe indicate that svn add or revert should be run.

svn commit would fail until the conflict is removed.

Not sure what should happen if svn update/switch/merge are run and
they want to do something with a file in this new state.

This is complicated. Hopefully once we work through a couple of these
scenarios it will always just be the same solution replaying over and
over.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org