Wilfredo Sánchez <wsanchez@wsanchez.net> (wsanchez)


Found Patch Suggested
r879084, r878074 r874658, r873642, r864761, r864760, r860355, r860073, r859160, r859159, r857693, r842914 r857760, r857693

r879084 | stsp | 2009-08-31 18:05:01 -0500 (Mon, 31 Aug 2009)

On the 1.6.x-r38000 branch:
Merge the originally proposed (and vetoed) r38000 group from trunk:
r38000, r38006, r38099, r38100, and r38181.
More merges to follow.

Here is a log message for this merge, formed by manually combining the log
messages of those five changes.

===

Fix a tree-conflict error when merge tries to replace a file.

Given a local edit (or an edit on the target branch) is present on a node,
then any add or delete that the merge tries to apply is a tree-conflict.
If a node was first deleted after merge-left and added again before
merge-right, merge issued *_deleted() and then *_added(),
and each tried to add a separate tree-conflict. Fix this.

Before adding a tree-conflict with an incoming add, look whether the
same node already has a tree-conflict with an incoming delete.
If it has, choose one of the tree-conflicts to remain.

In the special case where the *local* conflict cause is an edit
and the node kinds match, remove any tree-conflicts from the node and
merge normally.

This is in effect persistent, in the way that merge will now even
replace a tree-conflict that was already there before the merge in
question started. This is a side-effect, but it does in fact make
sense when applying the same merge range piecemeal.

Mailinglist thread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359772
Subject: multiple tree-conflicts during merge -- was: Re: Error reading spooled REPORT request response
Date: 2009-06-05 19:14

Found by: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>

* subversion/libsvn_client/merge.c
  (tree_conflict): Split the making of the tree-conflict struct into...
  (make_tree_conflict): ...this new function.
  (tree_conflict_on_add):
    New function, special case of tree_conflict(). Implement the fix.
  (merge_file_added, merge_dir_added): Use tree_conflict_on_add().

* subversion/libsvn_client/repos_diff.c
  (add_directory, close_file): Skip notify on tree-conflicts during a replace.
    Add comment and some whitespace.

* subversion/tests/cmdline/merge_tests.py
  (merge_replace_causes_tree_conflict): New test.
  (test_list): Add it.


r878074 | neels | 2009-06-11 14:31:59 -0500 (Thu, 11 Jun 2009)

Fix a tree-conflict error when merge tries to replace a file.

Given a local edit (or an edit on the target branch) is present on a node,
then any add or delete that the merge tries to apply is a tree-conflict.

If a node was first deleted after merge-left and added again before
merge-right, merge issued *_deleted() and then *_added(),
and each tried to add a separate tree-conflict. Fix this.

Before adding a tree-conflict with an incoming add, look whether the
same node already has a tree-conflict with an incoming delete.
If it has, choose one of the tree-conflicts to remain.

In the special case where the *local* conflict cause is an edit
and the node kinds match, remove any tree-conflicts from the node and
merge normally.

This is in effect persistent, in the way that merge will now even
replace a tree-conflict that was already there before the merge in
question started. This is a side-effect, but it does in fact make
sense when applying the same merge range piecemeal.

Later note: this also needs r38006 to work properly.

Mailinglist thread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359772Subject: multiple tree-conflicts during merge -- was: Re: Error reading
spooled REPORT request response
Date: 2009-06-05 19:14

* subversion/libsvn_client/merge.c
  (tree_conflict): Split the making of the tree-conflict struct into...
  (make_tree_conflict): ...this new function.
  (tree_conflict_on_add):
    New function, special case of tree_conflict(). Implement the fix.
  (merge_file_added): Use tree_conflict_on_add().

Found by: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>



r874658 | wsanchez | 2008-12-05 12:55:54 -0600 (Fri, 05 Dec 2008)

* contrib/hook-scripts/enforcer/enforcer: Add proper handling for
  multiple simultaneous property changes.

Found by: Ken MacInnis <ken.macinnis@gmail.com>


r873642 | kfogel | 2008-10-08 23:12:16 -0500 (Wed, 08 Oct 2008)

* contrib/hook-scripts/enforcer/enforcer: Adjust for the r27808
    svnlook output changes.

Patch by: wsanchez
Found by: Panu Outinen <panu@vertex.fi>


r864761 | wsanchez | 2007-04-20 14:54:21 -0500 (Fri, 20 Apr 2007)

* contrib/hook-scripts/enforcer/enforcer.conf:
  Add a check which fails a commit if an "x-no-commit" property is set
  on a file, which is useful if you want to be able to prevent a file
  from being committed accidentally.

Contributed by: Benjamin Holt.


r864760 | wsanchez | 2007-04-20 14:51:24 -0500 (Fri, 20 Apr 2007)

* contrib/hook-scripts/enforcer:
  Drain diff_out using iteration, not read(), since mixing the two is
  not allowed in python 2.5.


r860355 | wsanchez | 2006-06-28 11:56:20 -0500 (Wed, 28 Jun 2006)

Add some notes, and make some corrections to reflect the published RFC.


r860073 | wsanchez | 2006-06-07 20:38:18 -0500 (Wed, 07 Jun 2006)

* contrib/client-side/svn-resolve:
  Change expected file names to match what svn currently generates.


r859160 | wsanchez | 2006-03-29 15:48:00 -0600 (Wed, 29 Mar 2006)

* contrib/hook-scripts/enforcer:
  Add enforcer, a pre-commit hook script that lets you viciously and
  brutally enforce code guidelines on committed files.


r859159 | wsanchez | 2006-03-29 15:37:03 -0600 (Wed, 29 Mar 2006)

* contrib/client-side/svn-viewdiff,
  contrib/client-side/svn-resolve:
  Add two new scripts, to facilitate use of OS X's FileMerge
  application with Subversion.


r857760 | dlr | 2005-12-07 20:08:56 -0600 (Wed, 07 Dec 2005)

* subversion/libsvn_subr/simple_providers.c
  Add in-line comments about several known issues with OS X Keychain
  support, including lack of TTY prompting, prompting even when
  SecKeychainSetUserInteractionAllowed(FALSE) was called, and a
  concurrency-related race condition with that same API.


Patch by: me
          mbk
Suggested by: me
              Wilfredo Sánchez <wsanchez@apache.org>


r857693 | mbk | 2005-12-03 20:16:04 -0600 (Sat, 03 Dec 2005)

On Mac OS, use KeyChain services to store password (Issue 2339).

Note: SecKeychainSetUserInteractionAllowed (FALSE) does not appear to
actually prevent all user interaction.  Specifically, if the executable
changes (for example, if it is rebuilt), the system prompts the user
to okay the use of the new executable.

I'm not sure if I'm doing something wrong, or if this is a genuine bug
in the KeyChain implementation itself.

Suggested by: Wilfredo Sánchez <wsanchez@wsanchez.net>
Patch by: Ken Allan <k.allan@au.darkbluesea.com>
          Wilfredo Sánchez <wsanchez@wsanchez.net>
          me
Review by: djames


* Makefile.in:
  Add SVN_KEYCHAIN_LIBS, an autoconf substituted variable.
  Add SVN_KEYCHAIN_INCLUDES to INCLUDES.

* build.conf:
  Define keychain, an external lib, using the SVN_KEYCHAIN_LIBS variable.
  Add keychain to the libs for the svn exe.

* configure.in:
  Add --enable-keychain/--disable-keychain configury.  Default to enabled,
  if the appropriate OS and version are detected.

* subversion/include/svn_auth.h:
  (svn_auth_get_keychain_simple_provider): New prototype.

* subversion/libsvn_subr/cmdline.c:
  #include "svn_auth.h"
  (svn_cmdline_setup_auth_baton): Add keychain provider to list,
   and though not strictly required, increase the initial array size
   accordingly.

* subversion/libsvn_subr/simple_providers.c:
  #include "svn_private_config.h"
  (SVN_AUTH__KEYCHAIN_PASSWORD_TYPE): New password-type macro.
  Conditionally #include <Security/Security.h>
  (keychain_password_set, keychain_password_get, keychain_simple_first_creds,
   keychain_simple_save_creds, svn_auth_get_keychain_simple_provider): New
   functions.
  (keychain_simple_provider): New svn_auth_provider_t instance.


r842914 | fitz | 2002-07-31 23:01:22 -0500 (Wed, 31 Jul 2002)

* PORTING: Fix to the Update

Patch by: Wilfredo Sánchez <wsanchez@mit.edu>