Wilfredo Sánchez <wsanchez@wsanchez.net> (wsanchez)
| Found |
Patch |
Suggested |
|
r879084,
r878074 |
r874658,
r873642,
r864761,
r864760,
r860355,
r860073,
r859160,
r859159,
r857693,
r842914 |
r857760,
r857693 |
r842914 | fitz | 2002-08-01 04:01:22 +0000 (Thu, 01 Aug 2002)
* PORTING: Fix to the Update
Patch by: Wilfredo Sánchez <wsanchez@mit.edu>
r857693 | mbk | 2005-12-04 02:16:04 +0000 (Sun, 04 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.
r857760 | dlr | 2005-12-08 02:08:56 +0000 (Thu, 08 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>
r859159 | wsanchez | 2006-03-29 21:37:03 +0000 (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.
r859160 | wsanchez | 2006-03-29 21:48:00 +0000 (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.
r860073 | wsanchez | 2006-06-08 01:38:18 +0000 (Thu, 08 Jun 2006)
* contrib/client-side/svn-resolve:
Change expected file names to match what svn currently generates.
r860355 | wsanchez | 2006-06-28 16:56:20 +0000 (Wed, 28 Jun 2006)
Add some notes, and make some corrections to reflect the published RFC.
r864760 | wsanchez | 2007-04-20 19:51:24 +0000 (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.
r864761 | wsanchez | 2007-04-20 19:54:21 +0000 (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.
r873642 | kfogel | 2008-10-09 04:12:16 +0000 (Thu, 09 Oct 2008)
* contrib/hook-scripts/enforcer/enforcer: Adjust for the r27808
svnlook output changes.
Patch by: wsanchez
Found by: Panu Outinen <panu@vertex.fi>
r874658 | wsanchez | 2008-12-05 18:55:54 +0000 (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>
r878074 | neels | 2009-06-11 19:31:59 +0000 (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>
r879084 | stsp | 2009-08-31 23:05:01 +0000 (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.