RE: regarding tree-conflicts work
From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: Fri, 16 May 2008 23:10:55 +0530
>Hi Kamesh. It would be great to have you helping.
>Is there any reason not to move this conversation to the public dev list? It might help to awaken some interest from other people. If you agree, >I'll copy this reply to dev_at_s.t.o.
Yes I CCed dev_at_s.t.o now.
>> Do you maintain kind of TODO file somewhere?
>As Stefan mentioned, there are issues in the tracker. I converted the tagging from using "tree-conflicts" in the URL field to using >"tree-conflicts" in the Keywords field.
>At the top of my personal to-do list are:
> * Fix the failing non-tree-conflict tests on the tree-conflicts branch.
> * [Main task] Directory conflicts. In parallel, I want to both "fix" the most important individual cases that aren't yet handled, and also design a cleaner way to handle all the cases in some consistent manner, perhaps using a "conflict resolver callback" idea.
> * Resolve the problem that prevents the "double-delete" branch being completed - Issue #3156.
>And then some other tasks:
> * Investigate Alexander Kitaev's "1.5.x bug: property that have to be deleted by update remains in the working copy after update"
> * Issue #1962 "merge of non-empty subdir committed incorrectly". Needs design. Eric H had some thoughts, a test, and a reverted fix attempt.
> * "svn resolve" should force you to specify which conflict in a directory you are resolving, and not just resolve all of them.
> * Merge into conflicted directories - how to allow it for a bit of manual merging that may be needed in order to resolve conflicts within a >larger merge.
> * Re-vamp the use cases: state the minimum acceptable behaviour; state all the cases that we plan to make work (esp. directory clashes). We >should get Phillips to correct/clarify/update their own use cases, and we should write our own ones too.
> * Turn some of the use cases into acceptance tests.
>If you want to tackle any of these, that would be great.
>> I could see some tests failing, I am yet to go closer to fix
>Thanks. This would be very useful. I started to look at them but the first two or three I looked at were more difficult than I expected. Some of >them probably are broken due to bugs in the tree conflicts code (perhaps including accidentally interfering with non-conflict cases), and others >will need updating to expect a "conflict" result where they didn't expect it before.
I will focus on making the testsuite pass and pickup few items from the above list.
Thanks
|
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.