Checkout Tools
  • last updated 4 hours ago
Constraints: committers
Constraints: files
Constraints: dates

Changeset 1833935 is being indexed.

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,


(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


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 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.

Stricter verification of update behaviour in update_dir_external_exclude test.

* subversion/tests/cmdline/

(update_dir_external_exclude): Verify that externals are fetched into test

working copy during update operation.

* STATUS: Vote for r1830882.

* STATUS: Nominate r1833621.

Since on Windows Subversion does not handle symlinks, never check for reparse points.

* subversion/libsvn_subr/io.c

(io_check_path): ignore the 'resolve_symlinks' flag on Windows via #ifdef

Add a fuzzing test for svn_txdelta_parse_svndiff(). No issue found so far.

* build.conf: Add afl-svndiff

* subversion/tests/afl/afl-svndiff.c: New.

* subversion/tests/afl/afl-svndiff-testcase/: New.

* subversion/tests/afl/afl-svndiff-testcase/test1: New.

* subversion/tests/afl/afl-svndiff-testcase/test2: New.

* subversion/tests/afl/afl-svndiff-testcase/test3: New.

    • ?
    • ?
    • ?
  1. /trunk/subversion/tests/afl/afl-svndiff-testcase
    • ?
Add a couple more testcases for afl-x509. No further issues found.

* subversion/tests/afl/afl-x509-testcase/test2: New.

* subversion/tests/afl/afl-x509-testcase/test3: New.

* subversion/tests/cmdline/

(list_shelves): Don't check ordering, as shelf timestamps may not differ.

Merge r1816365 from trunk:

* r1816365

Duplicate proxy_password to the correct member of the new session, instead of

overwriting proxy_username.


Incorrect proxy settings can block user's access to the repo


+1: jamessan, stsp, philip

Change binary data tests to use varying file lengths.

This should make the tests work even though sleep_for_timestamps is disabled.

* STATUS: Vote for external pruning fix.
* STATUS: Vote/approve serf proxy password fix.
* subversion/tests/cmdline/

(unshelve_with_merge): Add a doc-string.

Shelving: Sleep for timestamps after 'unshelve'.

This should fix test failures we've been seeing particulary on a MacOSX buildbot

(as apparently an HFS+ filesystem has a coarse 1s timestamp resolution).

Found by: philip

* subversion/libsvn_client/shelf.c

(svn_client_shelf_apply): Sleep for timestamps.

Revert r1833512 (change binary data tests to use varying file lengths).