subversion

Checkout Tools
  • last updated 1 hour ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates

Changeset 1834175 is being indexed.

* STATUS: Propose HTTP v1 protocol fix.
On 1.9.x-r1833465 branch: merge r1833465 and adjust call to dav_svn__new_error.

Create 1.9.x-r1833465 branch.
* STATUS: Vote for conflict resolver search limit fix.
* STATUS: Propose HTTP v1 protocol fix.
* publish/roadmap.html

(features-most-wanted): Remove "Repository-dictated Configuration" as

it is basically done. See the referenced issue #1974 which I have just

closed.

Shelving: re-enable a test, following sleep-for-timestamps fix.

* subversion/tests/cmdline/shelf_tests.py

(shelve_binary_file_mod): Remove '@Skip' decoration.

* publish/roadmap.html

(upcoming-releases): Fill in a few deliverables/notes.

Publish our new 6-month standard and 2-year LTS release schedule.

* publish/index.html,

publish/news.html

Add a brief news item.

* publish/roadmap.html

Document the scheme and add the next few releases to the table.

Remove a pre-release warning that seems to have been missed in the sync merge

at r1829318.

* staging/docs/release-notes/1.10.html

(compatibility): Remove a pre-release warning.

Allow "svn x-shelf-log" from outside the working copy.

* subversion/svn/shelf-cmd.c

(svn_cl__shelf_log): Accept path arguments, supply default '.' path.

* subversion/svn/svn.c

(svn_cl__cmd_table): Update help text.

Shelving: Handle no-such-version scenarios better.

* subversion/libsvn_client/shelf.c

(svn_client_shelf_set_current_version): Don't try to open version 0.

(svn_client_shelf_version_open): Throw an error on trying to open

a non-existent version, as is already documented.

* subversion/svn/shelf-cmd.c

(get_newest_version_existing): New.

(shelf_restore,

shelf_diff): Use it, thus throwing a suitable error on a non-existent version.

(shelves_list): Write "no versions" explicitly when it is so.

(shelf_list_by_paths): Don't try to read from shelves with no versions.

Allow "svn x-shelf-drop" from outside the working copy.

* subversion/svn/shelf-cmd.c

(svn_cl__shelf_drop): Accept path arguments, supply default '.' path.

* subversion/svn/svn.c

(svn_cl__cmd_table): Update help text.

* subversion/svn/shelf-cmd.c

(svn_cl__shelf_list): Rename subpool and use it properly.

Allow "svn x-shelf-list" from outside the working copy.

* subversion/svn/shelf-cmd.c

(svn_cl__shelf_list): Accept path arguments, supply default '.' path.

* subversion/svn/svn.c

(svn_cl__cmd_table): Update help text.

Rename svn_wc__find_repos_node_in_wc() to svn_wc__db_find_repos_node_in_wc().

This namespace is more appropriate for wc_db code, and we might eventually

want to expose a similar libsvn_wc inteface which libsvn_client can use.

No functional change.

* subversion/libsvn_wc/conflicts.c

(svn_wc__guess_incoming_move_target_nodes): Update caller.

* subversion/libsvn_wc/wc_db.c,

subversion/libsvn_wc/wc_db.h

(svn_wc__find_repos_node_in_wc): Rename to ...

(svn_wc__db_find_repos_node_in_wc): ... this.

* STATUS: Nominate issue #4744 fix.

Fix issue #4744, "assertion failed (start_rev > end_rev)".

Do not attempt to fetch conflict details in the conflict scenario described

in issue #4744, where merge-left and merge-right URLs differ and their peg

revisions are the same. The 'merge directories' resolution option does not

handle this case yet (and is no longer offered in this case since r1833897).

However, the 'replace + merge' option works as expected.

For now this is good enough, and certainly better than an assertion failure.

Making the 'merge directories' option work is left for future work.

* subversion/libsvn_client/conflicts.c

(conflict_tree_get_details_incoming_add): Don't return details in case

merge-left/right URLs do not match and/or old_rev == new_rev.

* subversion/tests/libsvn_client/conflicts-test.c

(test_merge_two_added_dirs_assertion_failure): Resolve by replace + merge

and update test expectations accordingly.

Follow-up to r1833897:

* subversion/tests/libsvn_client/conflicts-test.c

(create_wc_with_dir_add_vs_dir_add_merge_conflict): Update test

expections here as well.

In case of a merge operation, the 'merge added directories' resolution

option requires tree conflict details. Do not offer this option unless

details have been fetched.

Otherwise, the user will see an error when choosing the option:

svn: warning: W155027: Conflict resolution option '14' requires details for tree conflict at 'PATH' to be fetched from the repository

* subversion/libsvn_client/conflicts.c

(configure_option_incoming_added_dir_merge): Do not add the option in case

this is a merge operation and details are not yet available.

* subversion/tests/libsvn_client/conflicts-test.c

(test_merge_two_added_dirs_assertion_failure): Update test expections,

and while here remove a redundant entry from an expected options list.

Add a test for issue #4744, "assertion failed (start_rev > end_rev)"

* subversion/tests/libsvn_client/conflicts-test.c

(create_wc_with_added_dir_conflict_across_branches,

test_merge_two_added_dirs_assertion_failure): New test which triggers the

assertion failure.

(test_funcs): Add new test (currently XFAIL).

* STATUS: Vote for r1833621.

* STATUS: Nominate issue #4739 fix.

Follow-up to r1833864:

* subversion/libsvn_client/conflicts.c

(verify_local_state_for_incoming_delete): Compare local_change to the

correct type of enum. No functional change because the enum values

svn_wc_conflict_action_edit and svn_wc_conflict_reason_edited happen

to match.

Found by: svn-warnings buildbot

Fix issue #4739, "Accept incoming deletion option doing nothing for

a locally deleted file"

The consistency check for copied state applies only to "local edit vs

incoming delete" conflicts. Only run the check in that particular case.

* subversion/libsvn_client/conflicts.c

(ensure_local_edit_vs_incoming_deletion_copied_state): New helper function,

extraced from the function below for better readibility.

(verify_local_state_for_incoming_delete): Only check the local copied state

if the local change involved in the conflict was an edit.

* subversion/tests/libsvn_client/conflicts-test.c

(test_funcs): test_update_incoming_delete_locally_deleted_file now passes.

Avoid potential (start_rev > end_rev) assertion failure in conflict resolver.

* subversion/libsvn_client/conflicts.c

(conflict_tree_get_details_incoming_delete): Make sure the end_rev

parameter provided to find_revision_for_suspected_deletion() is

greater than the start revision.

* STATUS: Add r1833842 to issue #4740 fix.

Follow-up to r1833836:

* subversion/libsvn_client/conflicts.c

(conflict_tree_get_details_local_missing): Ensure start_rev > end_rev

when calling find_revision_for_suspected_deletion(). The code I moved

up in r1833836 was bounds-checking end_rev against related_peg_rev,

but the start_rev is parent_pegrev in this case.

Restore a bounds check against related_peg_rev which was present

before r1833836 and is needed for find_moves_in_natural_history().

Problem caught by merge_tree_conflict_tests.py 2: "merge should

not die if a target file is absent"

* STATUS: Nominate r1833836 (issue #4740)

Fix issue #4740 "conflict resolver searches too far back with file edit vs move"

In case of the reproduction script attached to issue #4740, traversal now

stops at r2 instead of going back all the way back to r1. In real-life cases

this change should avoid scanning back through all of history, which is a

very expensive operation on repositories with a large amount of revisions.

* subversion/libsvn_client/conflicts.c

(conflict_tree_get_details_local_missing): Try to limit history traversal of

the find_revision_for_suspected_deletion() helper function to a youngest

common ancestor, instead of hard-coding the end revision to zero.

Only traverse all of history as a fallback in case no YCA could be found.

The YCA was already calculated later in this function, but it was only used

to limit another traversal which attempts to find moves on the other side

of the merge, in case no deleted revision can be determined for the victim.

Calculating the same YCA earlier allows us to limit the history traversal

process which looks for a revision which deleted the victim, too.