Re: Proposal: Change repository's UUID over RA layer

[Ramkumar Ramachandra]

Hi Daniel,

Daniel Shahaf writes:
 The implementation should be trivial (over ra_local and ra_svn; probably
 over ra_dav too but I don't know that one as well).  But what about authz
 concerns?
 
 Do you want to allow any authenticated user to change the repository UUID?

No, this doesn't make sense.

 Do you want UUID changing to be disallowed by default (unless the server
 admin took an explicit action)?

Yeah. Maybe something like the pre-revprop-change hook?

-- Ram

Re: Proposal: Change repository's UUID over RA layer

[Daniel Shahaf]

Ramkumar Ramachandra wrote on Fri, Aug 06, 2010 at 13:40:17 +0530:
 Hi Daniel,
 
 Daniel Shahaf writes:
  The implementation should be trivial (over ra_local and ra_svn; probably
  over ra_dav too but I don't know that one as well).  But what about authz
  concerns?
  
  Do you want to allow any authenticated user to change the repository UUID?
 
 No, this doesn't make sense.
 

Right.  So when *would* a UUID change be permitted?  When the hook says yes?
Or do you want to extend the existing (read/write/none) authz schemes?

  Do you want UUID changing to be disallowed by default (unless the server
  admin took an explicit action)?
 
 Yeah. Maybe something like the pre-revprop-change hook?
 

Yes, a pre-uuid-change hook (and disallowing a UUID change unless it exists)
is one option.

But that means the logic lives in libsvn_repos, so you have to think how
'svnadmin setuuid' would interact with it...

Daniel

 -- Ram

Re: [PATCH] new feature, lazy sync via export --skipfilesmatchingsize

[svnusertemp]

Thanks for the explanation about attachments on this list, Julian.  I 
tried to find a way to tell Windows 7 to treat the .patch files more 
as .txt  no luck yet.  I use Eudora as my email client and the OS 
is Windows 7.  If I rename the files to *.patch.txt, then they might 
go through differently.


Meanwhile for anyone interested, the actual patch files are available 
online at the following address, along with a Windows installer for 
the compiled binary of the svn client including the 
patch/feature.  That should make it easy for people to test it (on 
Windows) and then comment more meaningfully on the usefulness.  I'm 
fairly convinced the feature is not needed on Linux.


http://www.href.com/pub/sw/subversion/

I am planning to leave those files online until it is clear whether 
v1.7 with Working Copy Next Generation WCNG makes the whole issue 
moot.  Looking forward to testing that further down the track.


Sorry for the delay in reply, and many thanks to all the developers 
on this list for your work on subversion.


-Ann



At 04:22 PM 7/27/2010, Julian Foad wrote:

This mailing list strips patches that have certain MIME types including
application/octet-stream so I suspect that's what happened - it's not
related to being subscribed.

- Julian

[PATCH] Issue 2333 diff URL1 URL2 not reverse of diff URL2 URL1

[Stephen Butler]

Hi folks,

here's a patch that fixes issue 2333.  When doing a repos-repos diff,
Subversion has always skipped the content of a deleted directory.
All diff tests now pass, except for those that try to diff locally-
added files.

Does anyone have a problem with my changes to the repos_diff layer?
Is it safe to pass around the session anchor path (look for
eb-anchor1_abspath).

It'll be nice to tell users that diff does what it says on the box!

Cheers,
Steve

[[[
Fix issue 2333 diff URL1 URL2 not reverse of diff URL2 URL1.  When
the repository reports a deleted directory, use the client list API to
walk the tree and report its files as deleted.

* subversion/libsvn_client/repos_diff.c
  (edit_baton): Add a boolean field to control whether this workaround
   should be used.  Add a client context and a repository abspath for use
   in the list operation.
  (diff_deleted_tree_cb): New list callback function.
  (delete_entry): Call svn_client_list2 if needed.
  (svn_client__get_diff_editor): Set all the new edit_baton fields.

* subversion/libsvn_client/client.h
  (svn_client__get_diff_editor): Declare args for new edit_baton fields.

* subversion/libsvn_client/diff.c
  (diff_repos_repos_t): Add a repository abspath field.
  (diff_prepare_repos_repos): Calculate the repository abspath.  Pass it
   and the client context to svn_client__get_diff_editor.

* subversion/libsvn_client/merge.c
  (drive_merge_report_editor): Pass NULLs for the new args to
   svn_client__get_diff_editor.  No behavior change.

* subversion/tests/cmdline/diff_tests.py
  (diff_multiple_reverse): Remove a comment that made this test the moral
   equivalent of an XFAIL.
  (diff_renamed_dir): Add more test cases.  Correct the expectations for
   diffs within a moved directory.
  (test_list): Remove XFail from diff_renamed_dir.
]]]



--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194


Fix issue 2333 diff URL1 URL2 not reverse of diff URL2 URL1.  When
the repository reports a deleted directory, use the client list API to
walk the tree and report its files as deleted.

* subversion/libsvn_client/repos_diff.c 
  (edit_baton): Add a boolean field to control whether this workaround
   should be used.  Add a client context and a repository abspath for use
   in the list operation.
  (diff_deleted_tree_cb): New list callback function.
  (delete_entry): Call svn_client_list2 if needed.
  (svn_client__get_diff_editor): Set all the new edit_baton fields.

* subversion/libsvn_client/client.h
  (svn_client__get_diff_editor): Declare args for new edit_baton fields.

* subversion/libsvn_client/diff.c
  (diff_repos_repos_t): Add a repository abspath field.
  (diff_prepare_repos_repos): Calculate the repository abspath.  Pass it
   and the client context to svn_client__get_diff_editor.

* subversion/libsvn_client/merge.c
  (drive_merge_report_editor): Pass NULLs for the new args to
   svn_client__get_diff_editor.  No behavior change.

* subversion/tests/cmdline/diff_tests.py
  (diff_multiple_reverse): Remove a comment that made this test the moral
   equivalent of an XFAIL.
  (diff_renamed_dir): Add more test cases.  Correct the expectations for
   diffs within a moved directory.
  (test_list): Remove XFail from diff_renamed_dir.


Index: subversion/libsvn_client/repos_diff.c
===
--- subversion/libsvn_client/repos_diff.c   (revision 982907)
+++ subversion/libsvn_client/repos_diff.c   (working copy)
@@ -54,6 +54,9 @@ struct edit_baton {
  repository operation. */
   svn_wc_context_t *wc_ctx;
 
+  /* A client context. May be NULL. */
+  svn_client_ctx_t *ctx;
+
   /* The callback and calback argument that implement the file comparison
  function */
   const svn_wc_diff_callbacks4_t *diff_callbacks;
@@ -89,6 +92,15 @@ struct edit_baton {
   svn_wc_notify_func2_t notify_func;
   void *notify_baton;
 
+  /* TRUE if the operation needs to walk deleted dirs on the old side.
+ FALSE otherwise. */
+  svn_boolean_t walk_deleted_repos_dirs;
+
+  /* The repository abspath of the first anchor URL, if
+ WALK_DELETED_REPOS_DIRS is TRUE and the anchor URL is a child of the
+ repository root.  Otherwise NULL. */
+  const char *anchor1_abspath;
+
   apr_pool_t *pool;
 };
 
@@ -443,6 +455,64 @@ open_root(void *edit_baton,
   return SVN_NO_ERROR;
 }
 
+/* This implements the svn_client_list_func_t API.  Part of a workaround
+   for issue 2333. */
+static svn_error_t *
+diff_deleted_tree_cb(void *baton,
+ const char *path,
+ const svn_dirent_t *dirent,
+ const svn_lock_t *lock,
+ const char *abs_path,
+ 

RE: [PATCH] Issue 2333 diff URL1 URL2 not reverse of diff URL2 URL1

[Bert Huijben]

 -Original Message-
 From: Stephen Butler [mailto:sbut...@elego.de]
 Sent: vrijdag 6 augustus 2010 12:21
 To: dev@subversion.apache.org
 Subject: [PATCH] Issue 2333 diff URL1 URL2 not reverse of diff URL2
 URL1
 
 Hi folks,
 
 here's a patch that fixes issue 2333.  When doing a repos-repos diff,
 Subversion has always skipped the content of a deleted directory.
 All diff tests now pass, except for those that try to diff locally-
 added files.
 
 Does anyone have a problem with my changes to the repos_diff layer?
 Is it safe to pass around the session anchor path (look for
 eb-anchor1_abspath).
 
 It'll be nice to tell users that diff does what it says on the box!
 
 Cheers,
 Steve
 
 [[[
 Fix issue 2333 diff URL1 URL2 not reverse of diff URL2 URL1.  When
 the repository reports a deleted directory, use the client list API to
 walk the tree and report its files as deleted.
 
 * subversion/libsvn_client/repos_diff.c
(edit_baton): Add a boolean field to control whether this workaround
 should be used.  Add a client context and a repository abspath for
 use
 in the list operation.
(diff_deleted_tree_cb): New list callback function.
(delete_entry): Call svn_client_list2 if needed.
(svn_client__get_diff_editor): Set all the new edit_baton fields.
 
 * subversion/libsvn_client/client.h
(svn_client__get_diff_editor): Declare args for new edit_baton
 fields.
 
 * subversion/libsvn_client/diff.c
(diff_repos_repos_t): Add a repository abspath field.
(diff_prepare_repos_repos): Calculate the repository abspath.  Pass
 it
 and the client context to svn_client__get_diff_editor.
 
 * subversion/libsvn_client/merge.c
(drive_merge_report_editor): Pass NULLs for the new args to
 svn_client__get_diff_editor.  No behavior change.
 
 * subversion/tests/cmdline/diff_tests.py
(diff_multiple_reverse): Remove a comment that made this test the
 moral
 equivalent of an XFAIL.
(diff_renamed_dir): Add more test cases.  Correct the expectations
 for
 diffs within a moved directory.
(test_list): Remove XFail from diff_renamed_dir.
 ]]]

Review inline.


 Index: subversion/libsvn_client/repos_diff.c
 ===
 --- subversion/libsvn_client/repos_diff.c (revision 982907)
 +++ subversion/libsvn_client/repos_diff.c (working copy)
 @@ -54,6 +54,9 @@ struct edit_baton {
   repository operation. */
svn_wc_context_t *wc_ctx;
  
 +  /* A client context. May be NULL. */
 +  svn_client_ctx_t *ctx;
 +

ctx contains wc_ctx. Not sure if it useful to store both.
(But it is probably easier on the rest of the code)

/* The callback and calback argument that implement the file comparison
   function */
const svn_wc_diff_callbacks4_t *diff_callbacks;
 @@ -89,6 +92,15 @@ struct edit_baton {
svn_wc_notify_func2_t notify_func;
void *notify_baton;
  
 +  /* TRUE if the operation needs to walk deleted dirs on the old side.
 + FALSE otherwise. */
 +  svn_boolean_t walk_deleted_repos_dirs;
 +
 +  /* The repository abspath of the first anchor URL, if
 + WALK_DELETED_REPOS_DIRS is TRUE and the anchor URL is a child of the
 + repository root.  Otherwise NULL. */
 +  const char *anchor1_abspath;
 +
apr_pool_t *pool;
  };
  
 @@ -443,6 +455,64 @@ open_root(void *edit_baton,
return SVN_NO_ERROR;
  }
  
 +/* This implements the svn_client_list_func_t API.  Part of a workaround
 +   for issue 2333. */
 +static svn_error_t *
 +diff_deleted_tree_cb(void *baton,
 + const char *path,
 + const svn_dirent_t *dirent,
 + const svn_lock_t *lock,
 + const char *abs_path,
 + apr_pool_t *pool)
 +{
 +  struct edit_baton *eb = baton;
 +  const char *file_relpath, *file_path;
 +  struct file_baton *b;
 +  const char *mimetype1, *mimetype2;
 +  svn_wc_notify_state_t state = svn_wc_notify_state_inapplicable;
 +  svn_boolean_t tree_conflicted = FALSE;
 +
 +  if (dirent-kind != svn_node_file)
 +return SVN_NO_ERROR;
 +
 +  /* Compare a file being deleted against an empty file */
 + 
 +  /* The client list API provides an absolute repository path, but
 + get_file_from_ra() expects a path relative to the RA session URL. */
 +  file_path = svn_dirent_join(abs_path,
 +  path,
 +  pool);
 +  if (eb-anchor1_abspath)
 +{
 +  file_relpath = svn_dirent_is_child(eb-anchor1_abspath,
 + file_path,
 + pool);
 +}
 +  else
 +{
 +  while (*file_path == '/')
 +file_path++;
 +  file_relpath = file_path;
 +} 
 +  b = make_file_baton(file_relpath, FALSE, eb, pool);
 +  SVN_ERR(get_file_from_ra(b, eb-revision));
 +
 +  SVN_ERR(get_empty_file(b-edit_baton, (b-path_end_revision)));
 +  
 +  get_file_mime_types(mimetype1, mimetype2, b);
 +
 +  

Re: [PATCH] Invoke 'store password' prompt for all commands requiring authentication

[Senthil Kumaran S]

Kannan R wrote:
 On Thursday 29 July 2010 01:38 AM, Hyrum K. Wright wrote:
 Does this need to be fixed for serf too?
 
 serf seems to hold good in this case, it was working fine even at the
 time of submission of this initial patch.

Yes I confirm this. Looks like a problem with neon alone.

Thank You.
-- 
Senthil Kumaran S
http://www.stylesen.org/

Re: svn commit: r982929 - /subversion/trunk/subversion/svnrdump/load_editor.c

[Daniel Shahaf]

artag...@apache.org wrote on Fri, Aug 06, 2010 at 11:05:58 -:
 Author: artagnon
 Date: Fri Aug  6 11:05:58 2010
 New Revision: 982929
 
 URL: http://svn.apache.org/viewvc?rev=982929view=rev
 Log:
 * subversion/svnrdump/load_editor.c
   (apply_textdelta, close_node): Move the call to close_file from
   apply_textdelta to close_node, relying on the fact that
   apply_textdelta will always be called after a file is opened or
   added.

Is that fact true for revisions that have propchanges but no textual changes?

And for empty revisions?  (that contain neither propchanges nor textual
changes; we could create them via bugs at least)

Re: [PATCH] Invoke 'store password' prompt for all commands requiring authentication

[Senthil Kumaran S]

Hi,

Kannan R wrote:
 On Wednesday 07 October 2009 04:17 PM, Kannan wrote:
 Stefan Sperling wrote:
 
 Does this patch fix this case, too?
 
 
 [..]
 
 /me digs from the list of yet-to-be-committed patches.

I ve attached a new patch which fixes this by calling
svn_ra_neon__maybe_store_auth_info() once, instead of the repeated calls as
cmpilato has pointed out. Kannan, can you confirm this solves the issue you
see? If so I shall commit the patch.

[[[
While working on a wc of a repo which needs authentication, 'store
password unencrypted' prompt is getting invoked only for those svn
commands that access the repo URL or that have an URL as argument
(eg. svn ls http://localhost/repo) and not for wc oriented commands
such as `svn ls' or `svn cat -r 5 test.c' which also require
authentication, which is solved here. This also fixes redundant
invokation of the function 'svn_ra_neon__maybe_store_auth_info' at
various places.

* subversion/libsvn_ra_neon/util.c
  (svn_ra_neon__request_create): Store auth credentials if we can.

* subversion/libsvn_ra_neon/session.c
  (svn_ra_neon__do_get_uuid): Remove redundant invocation.

* subversion/libsvn_ra_neon/commit.c
  (commit_close_edit): Remove redundant invocation.

* subversion/libsvn_ra_neon/fetch.c
  (svn_ra_neon__get_latest_revnum, reporter_finish_report): Remove
   redundant invocation.
]]]

Thank You.
-- 
Senthil Kumaran S
http://www.stylesen.org/
Index: subversion/libsvn_ra_neon/util.c
===
--- subversion/libsvn_ra_neon/util.c	(revision 982905)
+++ subversion/libsvn_ra_neon/util.c	(working copy)
@@ -362,6 +362,9 @@
   apr_pool_t *reqpool = svn_pool_create(pool);
   svn_ra_neon__request_t *req = apr_pcalloc(reqpool, sizeof(*req));
 
+  /* If there is auth credentials in this session, store it if we can. */
+  SVN_ERR(svn_ra_neon__maybe_store_auth_info(sess, pool));
+
   /* We never want to send Neon an absolute URL, since that can cause
  problems with some servers (for example, those that may be accessed
  using different server names from different locations, or those that
Index: subversion/libsvn_ra_neon/session.c
===
--- subversion/libsvn_ra_neon/session.c	(revision 982905)
+++ subversion/libsvn_ra_neon/session.c	(working copy)
@@ -1170,7 +1170,6 @@
   SVN_ERR(svn_ra_neon__search_for_starting_props(rsrc, lopped_path,
  ras, ras-url-data,
  pool));
-  SVN_ERR(svn_ra_neon__maybe_store_auth_info(ras, pool));
 
   if (! ras-uuid)
 {
Index: subversion/libsvn_ra_neon/commit.c
===
--- subversion/libsvn_ra_neon/commit.c	(revision 982905)
+++ subversion/libsvn_ra_neon/commit.c	(working copy)
@@ -1355,7 +1355,6 @@
   cc-disable_merge_response,
   pool));
   SVN_ERR(delete_activity(edit_baton, pool));
-  SVN_ERR(svn_ra_neon__maybe_store_auth_info(cc-ras, pool));
 
   if (cc-callback  commit_info-revision != SVN_INVALID_REVNUM)
 SVN_ERR(cc-callback(commit_info, cc-callback_baton, pool));
Index: subversion/libsvn_ra_neon/fetch.c
===
--- subversion/libsvn_ra_neon/fetch.c	(revision 982905)
+++ subversion/libsvn_ra_neon/fetch.c	(working copy)
@@ -,7 +,6 @@
  ras, ras-root.path,
  SVN_INVALID_REVNUM, pool));
 }
-  SVN_ERR(svn_ra_neon__maybe_store_auth_info(ras, pool));
 
   return NULL;
 }
@@ -2440,9 +2439,6 @@
 (SVN_ERR_RA_DAV_REQUEST_FAILED, NULL,
  _(REPORT response handling failed to complete the editor drive));
 }
-
-  /* store auth info if we can. */
-  return svn_ra_neon__maybe_store_auth_info(rb-ras, pool);
 }
 
 static const svn_ra_reporter3_t ra_neon_reporter = {

Re: Proposal: Change repository's UUID over RA layer

[C. Michael Pilato]

On 08/06/2010 04:30 AM, Daniel Shahaf wrote:
 Yes, a pre-uuid-change hook (and disallowing a UUID change unless it exists)
 is one option.
 
 But that means the logic lives in libsvn_repos, so you have to think how
 'svnadmin setuuid' would interact with it...

We just follow the pattern that already exists. By default, 'svnadmin
setuuid' would bypass the hooks. (In generally, I think it is assumed that
anyone who can run 'svnadmin' on a repository directly can also modify its
hooks.) And then we add --use-pre-uuid-change-hook and
--use-post-uuid-change-hook options.

See 'svnadmin setrevprop' / svn_repos_fs_change_rev_prop3() and 'svnadmin
load'  / svn_repos_load_fs3() for prior art.

-- 
C. Michael Pilato cmpil...@collab.net
CollabNet  www.collab.net  Distributed Development On Demand



signature.asc
Description: OpenPGP digital signature

RE: svn commit: r982952 - in /subversion/trunk/subversion/libsvn_ra_neon: commit.c fetch.c session.c util.c

[Bert Huijben]

 -Original Message-
 From: style...@apache.org [mailto:style...@apache.org]
 Sent: vrijdag 6 augustus 2010 15:32
 To: comm...@subversion.apache.org
 Subject: svn commit: r982952 - in
 /subversion/trunk/subversion/libsvn_ra_neon: commit.c fetch.c session.c
 util.c
 
 Author: stylesen
 Date: Fri Aug  6 13:31:37 2010
 New Revision: 982952
 
 URL: http://svn.apache.org/viewvc?rev=982952view=rev
 Log:
 While working on a wc of a repo which needs authentication, 'store
 password unencrypted' prompt is getting invoked only for those svn
 commands that access the repo URL or that have an URL as argument
 (eg. svn ls http://localhost/repo) and not for wc oriented commands
 such as `svn ls' or `svn cat -r 5 test.c' which also require
 authentication, which is solved here. This also fixes redundant
 invokation of the function 'svn_ra_neon__maybe_store_auth_info' at
 various places.

The compilation of this patch breaks in several places and most likely on 
multiple buildbots

 
 Modified: subversion/trunk/subversion/libsvn_ra_neon/fetch.c
 URL:
 http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_neon
 /fetch.c?rev=982952r1=982951r2=982952view=diff
 ===
 ===
 --- subversion/trunk/subversion/libsvn_ra_neon/fetch.c (original)
 +++ subversion/trunk/subversion/libsvn_ra_neon/fetch.c Fri Aug  6
 13:31:37 2010
 @@ -,7 +,6 @@ svn_error_t *svn_ra_neon__get_latest_rev
   ras, ras-root.path,
   SVN_INVALID_REVNUM,
 pool));
  }
 -  SVN_ERR(svn_ra_neon__maybe_store_auth_info(ras, pool));
 
return NULL;
  }
 @@ -2440,9 +2439,6 @@ static svn_error_t * reporter_finish_rep
  (SVN_ERR_RA_DAV_REQUEST_FAILED, NULL,
   _(REPORT response handling failed to complete the editor
 drive));
  }
 -
 -  /* store auth info if we can. */
 -  return svn_ra_neon__maybe_store_auth_info(rb-ras, pool);
  }

This leaves a function without a return statement.


 @@ -362,6 +362,9 @@ svn_ra_neon__request_create(svn_ra_neon_
apr_pool_t *reqpool = svn_pool_create(pool);
svn_ra_neon__request_t *req = apr_pcalloc(reqpool, sizeof(*req));
 
 +  /* If there is auth credentials in this session, store it if we can.
 */
 +  SVN_ERR(svn_ra_neon__maybe_store_auth_info(sess, pool));
 +

This function doesn't return svn_error_t *, so you can't return errors here.

Bert 

Re: Proposal: Change repository's UUID over RA layer

[Greg Stein]

Back up here.

Why would an admin install a hook to allow changing a UUID? Why would
a UUID be allowed to change over time? If a UUID is supposed to be
changed, then why wouldn't that admin just do it himself? Why does
this have to be allowed remotely?

I'm sorry, but this whole feature just seems misguided. The UUID is
supposed to be stable and unchanging. We use it to determine what
repository we're talking to. It isn't supposed to change from one day
to the next.

-g

On Fri, Aug 6, 2010 at 09:02, C. Michael Pilato cmpil...@collab.net wrote:
 On 08/06/2010 04:30 AM, Daniel Shahaf wrote:
 Yes, a pre-uuid-change hook (and disallowing a UUID change unless it exists)
 is one option.

 But that means the logic lives in libsvn_repos, so you have to think how
 'svnadmin setuuid' would interact with it...

 We just follow the pattern that already exists. By default, 'svnadmin
 setuuid' would bypass the hooks. (In generally, I think it is assumed that
 anyone who can run 'svnadmin' on a repository directly can also modify its
 hooks.) And then we add --use-pre-uuid-change-hook and
 --use-post-uuid-change-hook options.

 See 'svnadmin setrevprop' / svn_repos_fs_change_rev_prop3() and 'svnadmin
 load'  / svn_repos_load_fs3() for prior art.

 --
 C. Michael Pilato cmpil...@collab.net
 CollabNet      www.collab.net      Distributed Development On Demand

Re: Proposal: Change repository's UUID over RA layer

[Branko Čibej]

I have to agree. While it may make sense to be able create a dumpfile of
a remote repository, I'm not so sure that /loading/ a dumpfile remotely
is sensible. And it's the load that potentially requires a UUID change.

-- Brane

On 06.08.2010 16:03, Greg Stein wrote:
 Back up here.

 Why would an admin install a hook to allow changing a UUID? Why would
 a UUID be allowed to change over time? If a UUID is supposed to be
 changed, then why wouldn't that admin just do it himself? Why does
 this have to be allowed remotely?

 I'm sorry, but this whole feature just seems misguided. The UUID is
 supposed to be stable and unchanging. We use it to determine what
 repository we're talking to. It isn't supposed to change from one day
 to the next.

 -g

 On Fri, Aug 6, 2010 at 09:02, C. Michael Pilato cmpil...@collab.net wrote:
   
 On 08/06/2010 04:30 AM, Daniel Shahaf wrote:
 
 Yes, a pre-uuid-change hook (and disallowing a UUID change unless it exists)
 is one option.

 But that means the logic lives in libsvn_repos, so you have to think how
 'svnadmin setuuid' would interact with it...
   
 We just follow the pattern that already exists. By default, 'svnadmin
 setuuid' would bypass the hooks. (In generally, I think it is assumed that
 anyone who can run 'svnadmin' on a repository directly can also modify its
 hooks.) And then we add --use-pre-uuid-change-hook and
 --use-post-uuid-change-hook options.

 See 'svnadmin setrevprop' / svn_repos_fs_change_rev_prop3() and 'svnadmin
 load'  / svn_repos_load_fs3() for prior art.

 --
 C. Michael Pilato cmpil...@collab.net
 CollabNet  www.collab.net  Distributed Development On Demand
 

Re: Proposal: Change repository's UUID over RA layer

[Ramkumar Ramachandra]

Hi Greg,

Greg Stein writes:
 Why would an admin install a hook to allow changing a UUID? Why would
 a UUID be allowed to change over time? If a UUID is supposed to be
 changed, then why wouldn't that admin just do it himself? Why does
 this have to be allowed remotely?

Agreed- this feature has a very narrow usecase. Anyway, since I
started the thread, let me explain the motivation for this feature. It
derives from `svnrdump` -- Anybody without administrative priviliges
can actually mirror a complete Subversion repository using `svnrdump
dump | svnrdump load` quite efficiently. Let's say some sponsor wants
to provide a mirroring service- with the proposed feature the person
will simply have to create a blank repository and enable
pre-revprop-change/ pre-uuid-change on and wait for someone to load
the content into that repository. After the intial mirroring is done,
he can always turn off the pre-uuid-change. It's probably a
dangerous feature, and I don't know if it's worth the trouble.

-- Ram

Re: Proposal: Change repository's UUID over RA layer

[Hyrum K. Wright]

On Fri, Aug 6, 2010 at 9:24 AM, Greg Stein gst...@gmail.com wrote:
 On Fri, Aug 6, 2010 at 10:15, Ramkumar Ramachandra artag...@gmail.com wrote:
 Hi Greg,

 Greg Stein writes:
 Why would an admin install a hook to allow changing a UUID? Why would
 a UUID be allowed to change over time? If a UUID is supposed to be
 changed, then why wouldn't that admin just do it himself? Why does
 this have to be allowed remotely?

 Agreed- this feature has a very narrow usecase. Anyway, since I
 started the thread, let me explain the motivation for this feature. It
 derives from `svnrdump` -- Anybody without administrative priviliges
 can actually mirror a complete Subversion repository using `svnrdump
 dump | svnrdump load` quite efficiently. Let's say some sponsor wants
 to provide a mirroring service- with the proposed feature the person
 will simply have to create a blank repository and enable
 pre-revprop-change/ pre-uuid-change on and wait for someone to load
 the content into that repository. After the intial mirroring is done,
 he can always turn off the pre-uuid-change. It's probably a
 dangerous feature, and I don't know if it's worth the trouble.

 I disagree that the UUID should be mirrored. You're loading a *NEW*
 repository. Thus, it should not have the same UUID as the original.
 The original continues to exist. Having two repositories with the same
 UUID is just wrong. That is contrary to the entire design principle..

Agreed.  *Universally Unique* Identifier.

-Hyrum

Re: Proposal: Change repository's UUID over RA layer

[Greg Hudson]

When I've mirrored repositories with the intent of keeping them in sync,
I've typically given them the same UUID.  I don't know if that has much
impact in practice, since I think working copies tend to stick to one of
the mirrors (either the RW master or the RO slave).

The philosophical question here isn't whether the ID is universally
unique but what it's identifying.  Is it identifying the repository
content or the the container in which the content is held?

Re: svn commit: r979282 - in /subversion/trunk/subversion/svnrdump: dump_editor.c dump_editor.h load_editor.c load_editor.h svnrdump.c

[Ramkumar Ramachandra]

Hi Kamesh and Philip,

Philip Martin writes:
 Kamesh Jayachandran kam...@collab.net writes:
 
  On 07/26/2010 07:25 PM, artag...@apache.org wrote:
  Author: artagnon
  Date: Mon Jul 26 13:55:25 2010
  New Revision: 979282
 
  URL: http://svn.apache.org/viewvc?rev=979282view=rev
  Log:
  svnrdump: Add an a no-op load editor
 
  * subversion/svnrdump/svnrdump.c
 (load_revisions): New function to fetch and drive the load
 editor. Currently just fetches the load editor.
 (load_cmd): Call load_revisions with the appropriate arguments.
 
  * subversion/svnrdump/load_editor.c
 (get_load_editor): Add a no-op load editor.
 
 
  Please name this function 'get_load_editor' as 'svnrdump__get_load_editor'.
 
 You also need to #include load_editor.h in load_editor.c to make the
 prototype visible (possibly instead of dump_editor.h?)

Sorry about the late response- there was a huge amount of development
and API changes over the last week. I'm sure you'll agree that it's
quite unpleasant to type svnrdump___get_load_editor into gdb
everytime during development. Ofcourse, when everything starts working
and the API becomes more stable, I'll expose all re-usable
functionality. Thank you for understanding.

Also, please mark me on the TO or CC when specifically addressing my
commits- I have to handle massive volumes of email everyday, and I
sometimes miss email on which I'm not marked.

Thanks again.

-- Ram

Re: svn commit: r979282 - in /subversion/trunk/subversion/svnrdump: dump_editor.c dump_editor.h load_editor.c load_editor.h svnrdump.c

[Hyrum K. Wright]

On Fri, Aug 6, 2010 at 10:30 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
 Hi Kamesh and Philip,

 Philip Martin writes:
 Kamesh Jayachandran kam...@collab.net writes:

  On 07/26/2010 07:25 PM, artag...@apache.org wrote:
  Author: artagnon
  Date: Mon Jul 26 13:55:25 2010
  New Revision: 979282
 
  URL: http://svn.apache.org/viewvc?rev=979282view=rev
  Log:
  svnrdump: Add an a no-op load editor
 
  * subversion/svnrdump/svnrdump.c
     (load_revisions): New function to fetch and drive the load
     editor. Currently just fetches the load editor.
     (load_cmd): Call load_revisions with the appropriate arguments.
 
  * subversion/svnrdump/load_editor.c
     (get_load_editor): Add a no-op load editor.
 
 
  Please name this function 'get_load_editor' as 'svnrdump__get_load_editor'.

 You also need to #include load_editor.h in load_editor.c to make the
 prototype visible (possibly instead of dump_editor.h?)

 Sorry about the late response- there was a huge amount of development
 and API changes over the last week. I'm sure you'll agree that it's
 quite unpleasant to type svnrdump___get_load_editor into gdb
 everytime during development. Ofcourse, when everything starts working
 and the API becomes more stable, I'll expose all re-usable
 functionality. Thank you for understanding.

I don't think that easy of typing into the debugger should be a
primary qualification for API naming conventions...

-Hyrum

Re: Proposal: Change repository's UUID over RA layer

[Daniel Shahaf]

Greg Hudson wrote on Fri, Aug 06, 2010 at 10:49:27 -0400:
 The philosophical question here isn't whether the ID is universally
 unique but what it's identifying.  Is it identifying the repository
 content or the the container in which the content is held?

The former, if I remember correctly a discussion I participated in (on this
list) a few years ago.

And even so, we might decide that the admin should setuuid out-of-band of
the RA layer.  It it isn't unreasonable, given that it's an operation needed
exactly once over the lifetime of any repository^Wcontainer instance.

Daniel
(possibly the discussion was even before I became a committer)

Re: svn commit: r979282 - in /subversion/trunk/subversion/svnrdump: dump_editor.c dump_editor.h load_editor.c load_editor.h svnrdump.c

[Ramkumar Ramachandra]

Hi Hyrum,

Hyrum K. Wright writes:
 I don't think that easy of typing into the debugger should be a
 primary qualification for API naming conventions...

Hehe, ofcourse. I just meant to say that I'll save the formal naming
until I get past the point where the program can go a few seconds
without segfaulting :)

-- Ram

Re: svn commit: r979282 - in /subversion/trunk/subversion/svnrdump: dump_editor.c dump_editor.h load_editor.c load_editor.h svnrdump.c

[Daniel Shahaf]

I don't see a reason not to adhere to the naming conventions from the start.

It's easier to write correct code once than to write buggy code and then
correct it...  (this theme is strong on my mind after reading through Bert's
commit diffs last night)

Ramkumar Ramachandra wrote on Fri, Aug 06, 2010 at 22:30:34 +0530:
 Hi Hyrum,
 
 Hyrum K. Wright writes:
  I don't think that easy of typing into the debugger should be a
  primary qualification for API naming conventions...
 
 Hehe, ofcourse. I just meant to say that I'll save the formal naming
 until I get past the point where the program can go a few seconds
 without segfaulting :)
 
 -- Ram

Re: Proposal: Change repository's UUID over RA layer

[Justin Erenkrantz]

On Fri, Aug 6, 2010 at 7:34 AM, Branko Čibej br...@xbc.nu wrote:
 Ahem. You guys have forgotten about Justin's RW-master/RO-slave
 replication hack, which *requires* the slave repositories to have the
 same UUID as the master. And that 'svnadmin load' has both --ignore-uuid
 and --force-uuid.

When doing any master/slave initial configuration, doing a local
'svnadmin setuuid' should be sufficient.  IOW, I don't see that use
case as driving this need.  -- justin

Bikeshed: configuration override order

[Hyrum K. Wright]

I'm doing some more thinking about repository-dictated configuration,
and one of the things I'd like some discussion on is the order of
configuration overrides.  The consensus is that the repository can not
be sure that it's dictated configuration is received and respected by
the client, so it should treat whatever config it sends as purely
suggestive.  We currently have several (implemented or proposed)
sources for configuration information, and I think they should be
searched in the following order:

 * Client site-wide configuration (/etc/subversion)
 * Client user-specific configuration (~/subversion, 'svn --config-dir')
 * Repository-dictated configuration (as described above)
 * Explicit configuration supplied by the client application
   ('svn --config-option', or Eclipse configuration options)

Not every location contains every bit of config, of course, but in the
case of conflicts, the most recent encountered value sticks.  In other
words, a client could override repository-dictated configuration
options by using 'svn --config-option', or the (as yet unimplemented)
equivalent facility for other API consumers.

Thoughts?

-Hyrum

RE: Bikeshed: configuration override order

[Bob Archer]

  * Client site-wide configuration (/etc/subversion)
  * Client user-specific configuration (~/subversion, 'svn --config-
 dir')
  * Repository-dictated configuration (as described above)
  * Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)
 
 Not every location contains every bit of config, of course, but in
 the
 case of conflicts, the most recent encountered value sticks.  In
 other
 words, a client could override repository-dictated configuration
 options by using 'svn --config-option', or the (as yet
 unimplemented)
 equivalent facility for other API consumers.
 
 Thoughts?

Hmm... so you are saying that repository settings will override locally 
configured settings but not CLI specified settings? Why? That seems a bit 
backward to me. I would expect:

* Repository-dictated configuration (as described above)
* Client site-wide configuration (/etc/subversion)
* Client user-specific configuration (~/subversion, 'svn --config-
dir')
* Explicit configuration supplied by the client application
   ('svn --config-option', or Eclipse configuration options)

Can these settings be path specific in the repository? What happens if I have 
checked-out a sub-path... I'm not sure if you plan on implementing this as a 
config file a user can check into svn or as properties like the keyword stuff 
or were you thinking that these is info that will be passed from the server to 
the client when requested?

One other option, an idea that ASP.Net uses for its config settings is the 
ability to specify at what level a setting can be overridden.

BOb
 

Re: Proposal: Change repository's UUID over RA layer

[Branko Čibej]

On 06.08.2010 19:26, Justin Erenkrantz wrote:
 On Fri, Aug 6, 2010 at 7:34 AM, Branko Čibej br...@xbc.nu wrote:
   
 Ahem. You guys have forgotten about Justin's RW-master/RO-slave
 replication hack, which *requires* the slave repositories to have the
 same UUID as the master. And that 'svnadmin load' has both --ignore-uuid
 and --force-uuid.
 
 When doing any master/slave initial configuration, doing a local
 'svnadmin setuuid' should be sufficient.  IOW, I don't see that use
 case as driving this need.  -- justin
   

Exatly. And while that's being done locally, one might just as well do
the whole 'svnadmin load' which can implicitly set the UUID. Which means
we don't need an 'svnadmin setuuid' since loading a dump is pretty much
the only time one might reasonably want to change the repository UUID, IMHO.

-- Brane

Re: Bikeshed: configuration override order

[Hyrum K. Wright]

On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson ghud...@mit.edu wrote:
 On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
 I'm doing some more thinking about repository-dictated configuration,

 I get nervous when I see people talk about repository-dictated
 configuration as an extension of the general configuration framework.

 There are a lot of things a repository should not be able to configure
 for trust reasons--in particular, what commands the client runs.  When
 you check out material from a repository, you are not handing over the
 keys to your machine or account, just retrieving content.  In fact, I
 think there are only a few specific configuration variables which a
 repository should be able to influence, such as mime-type recognition.

Agree with the general point, but it raises another point: which
values are acceptable for overriding?  Are they hardcoded or
configurable (if configurable, that kinda defeats the point, since
they'd have to be configured locally)?  White list?  Black list?

Would a hard-coded list be something that depends on application
(corporate vs. open source vs. some other deployment)?

-Hyrum

Re: Bikeshed: configuration override order

[Stefan Küng]

On 06.08.2010 19:50, Hyrum K. Wright wrote:

I'm doing some more thinking about repository-dictated configuration,
and one of the things I'd like some discussion on is the order of
configuration overrides.  The consensus is that the repository can not
be sure that it's dictated configuration is received and respected by
the client, so it should treat whatever config it sends as purely
suggestive.  We currently have several (implemented or proposed)
sources for configuration information, and I think they should be
searched in the following order:

  * Client site-wide configuration (/etc/subversion)
  * Client user-specific configuration (~/subversion, 'svn --config-dir')
  * Repository-dictated configuration (as described above)
  * Explicit configuration supplied by the client application
('svn --config-option', or Eclipse configuration options)

Not every location contains every bit of config, of course, but in the
case of conflicts, the most recent encountered value sticks.  In other
words, a client could override repository-dictated configuration
options by using 'svn --config-option', or the (as yet unimplemented)
equivalent facility for other API consumers.


I think that repository-dictated configurations should override client 
configs. This is what I think most corporations would expect.
Maybe there could be two client configs: one used as a default if no 
corresponding repo-dictated config is available, and then one to 
explicitly override the repo-dictated config.


Something like this:

   * Client site-wide configuration (/etc/subversion)
   * Client user-specific configuration (~/subversion, 'svn --config-dir')
   * Explicit configuration supplied by the client application
 ('svn --config-option', or Eclipse configuration options)
   * Repository-dictated configuration (as described above)
   * forced configuration by the client (e.g., svn --override-repo-config)

Stefan

--
   ___
  oo  // \\  De Chelonian Mobile
 (_,\/ \_/ \ TortoiseSVN
   \ \_/_\_/The coolest Interface to (Sub)Version Control
   /_/   \_\ http://tortoisesvn.net

Re: Bikeshed: configuration override order

[Hyrum K. Wright]

On Fri, Aug 6, 2010 at 1:08 PM, C. Michael Pilato cmpil...@collab.net wrote:
 On 08/06/2010 01:50 PM, Hyrum K. Wright wrote:
 I'm doing some more thinking about repository-dictated configuration,
 and one of the things I'd like some discussion on is the order of
 configuration overrides.  The consensus is that the repository can not
 be sure that it's dictated configuration is received and respected by
 the client, so it should treat whatever config it sends as purely
 suggestive.  We currently have several (implemented or proposed)
 sources for configuration information, and I think they should be
 searched in the following order:

  * Client site-wide configuration (/etc/subversion)
  * Client user-specific configuration (~/subversion, 'svn --config-dir')
  * Repository-dictated configuration (as described above)
  * Explicit configuration supplied by the client application
    ('svn --config-option', or Eclipse configuration options)

 Not every location contains every bit of config, of course, but in the
 case of conflicts, the most recent encountered value sticks.  In other
 words, a client could override repository-dictated configuration
 options by using 'svn --config-option', or the (as yet unimplemented)
 equivalent facility for other API consumers.

 Thoughts?

 It seems to me like, if we search the list above in the order presented (as
 you suggest), we pretty much get the worst possible scenario.  Maybe it's a
 wording thing, though.  (I'm thinking search-and-stop-on-first-find ...
 maybe you mean overlay/overwrite configurations in this order, then search
 the merged results?)

I mean the latter: read a config, overwrite any previous values,
repeat.  This is how the current system is set up today, I believe (it
uses apr hashes to store the configuration, and just blindly sets the
values it finds, leading the most recent found to be the functional
value).

 Whatever you meant, the corporate customers I've spoken with understand
 that, so long as they are using open source Subversion clients, anyone can
 theoretically modify their client to change its behavior.  But on the
 assumption that that is a rare case, they want Subversion to try to treat
 the repos-dictated config as more than merely suggestive.  In other words,
 they want to be able to reasonably expect that in order to get behavior that
 opposes the repos-dictated configuration, the user *must* have modified
 their client or used a client that doesn't honor Subversion's design in this
 respect.

 In the past, I've proposed the idea of two repos-dictated configuration
 sets:  one that has the ultimately authority and cannot be overridden
 without library changes, one that sits in about the slot you've described 
 above.

I dunno.  I think that may be a bit too complex for a first pass, and
I think that adding a requirement to hack the library doesn't really
add any value, other than obfuscation.  The obfuscated approach may
fool some people, but if they really want to override, they are going
to do it.  I'd rather accomplish that via the parsing order than
hacking the library (having to specify 'svn --config-option', seems
like a reasonable barrier).

I just wrote that and then read Greg Hudson's mail elsethread, which
makes me wonder if we need three piles:
 * always override from server
 * possibly override from server
 * never override from server

-Hyrum

RE: Bikeshed: configuration override order

[Bob Archer]

 On Fri, Aug 6, 2010 at 1:13 PM, Greg Hudson ghud...@mit.edu
 wrote:
  On Fri, 2010-08-06 at 13:50 -0400, Hyrum K. Wright wrote:
  I'm doing some more thinking about repository-dictated
 configuration,
 
  I get nervous when I see people talk about repository-dictated
  configuration as an extension of the general configuration
 framework.
 
  There are a lot of things a repository should not be able to
 configure
  for trust reasons--in particular, what commands the client runs.
  When
  you check out material from a repository, you are not handing
 over the
  keys to your machine or account, just retrieving content.  In
 fact, I
  think there are only a few specific configuration variables which
 a
  repository should be able to influence, such as mime-type
 recognition.
 
 Agree with the general point, but it raises another point: which
 values are acceptable for overriding?  Are they hardcoded or
 configurable (if configurable, that kinda defeats the point, since
 they'd have to be configured locally)?  White list?  Black list?
 
 Would a hard-coded list be something that depends on application
 (corporate vs. open source vs. some other deployment)?
 
 -Hyrum

As I said in a previous email, you might want to consider looking at the 
asp.net configuration and how that is done. They have a configuration hierarchy 
and inheritence. You can specify the scope of the configuration items and also 
you can restrict inheritence on certain items.

http://msdn.microsoft.com/en-us/library/ms178685.aspx

Of course, since svn is open source... it would be possible to create a client 
that would ignore inheritance restrictions with a few // characters in the 
source code. I guess an enterprise client would want to compile there own 
client and sign it and only allow signed clients to access the repository or 
something to mitigate that kind of stuff.

But really why do people want this. I think it is so some settings like 
auto-props and other things that need to be set for a specific project will 
take place without having to distribute a config or send an email with make 
sure you add this to your config type of warning from a pre-commit hook that 
notices certain properties are missing for certain file types.

BOb

[PATCH] Revert to using zlib-provided compress bound

[Michael Spang]

We have a local definition of zlib's compressBound which is not in
sync with recent versions of zlib. This may cause a Compression of
svndiff data failed message from the Subversion server when the
buffer provided to zlib is not large enough.

This reverts to using the zlib-provided version, since the old version
of zlib that was missing this function should be quite rare these
days.
---
 subversion/libsvn_delta/svndiff.c |7 +--
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/subversion/libsvn_delta/svndiff.c 
b/subversion/libsvn_delta/svndiff.c
index bf6afa9..c0187b5 100644
--- a/subversion/libsvn_delta/svndiff.c
+++ b/subversion/libsvn_delta/svndiff.c
@@ -31,11 +31,6 @@
 #include svn_private_config.h
 #include zlib.h
 
-/* This macro is taken from zlib, and was originally the function
-   compressBound.  It shouldn't ever change, but once every millenium,
-   it may be useful for someone to make sure. */
-#define svnCompressBound(LEN) ((LEN) + ((LEN)  12) + ((LEN)  14) + 11)
-
 /* For svndiff1, address/instruction/new data under this size will not
be compressed using zlib as a secondary compressor.  */
 #define MIN_COMPRESS_SIZE 512
@@ -152,7 +147,7 @@ zlib_encode(const char *data, apr_size_t len, 
svn_stringbuf_t *out)
 }
   else
 {
-  svn_stringbuf_ensure(out, svnCompressBound(len) + intlen);
+  svn_stringbuf_ensure(out, compressBound(len) + intlen);
   endlen = out-blocksize;
 
   if (compress2((unsigned char *)out-data + intlen, endlen,
-- 
1.7.1

svn_wc_translated_file3

[Stefan Küng]

Hi,

Just noticed that the API svn_wc_translated_file3() has been removed in 
r963632:


Message:
Remove the public libsvn_wc file and stream translation APIs (while 
leaving their deprecated predecessors).  These APIs are not consumed by 
the client. See: http://svn.haxx.se/dev/archive-2010-07/0100.shtml



While I can understand the reasons for removing it, I still need some 
way to get done what this API did: get a file representing the WC BASE 
in a translated format. Sure I could use the stream API but that way I 
will always have to read from the stream and write it to a file. The 
removed API was very fast if no translation was necessary because it 
simply returned the existing BASE file path.


As for what I need that API in TSVN: to do a quick diff between WC and 
BASE of files. For example, every time a user doubleclicks on a modified 
file in the commit dialog, TSVN calls that API to get the BASE file.


As for using svn_wc_translated_file2(), that one requires an 
svn_wc_adm_access_t as a parameter which I can only get using deprecated 
APIs.


Suggestions on what I should do?

Stefan

--
   ___
  oo  // \\  De Chelonian Mobile
 (_,\/ \_/ \ TortoiseSVN
   \ \_/_\_/The coolest Interface to (Sub)Version Control
   /_/   \_\ http://tortoisesvn.net

Re: Bikeshed: configuration override order

[Stefan Sperling]

On Fri, Aug 06, 2010 at 02:28:11PM -0400, Bob Archer wrote:
 But really why do people want this. I think it is so some settings like 
 auto-props and other things that need to be set for a specific project will 
 take place without having to distribute a config or send an email with make 
 sure you add this to your config type of warning from a pre-commit hook that 
 notices certain properties are missing for certain file types.
 

Auto-props are one killer app.
Another one is save-plaintext-passwords = no.

It's documented in trunk/notes/feedback/cmpilato-user-calls:

   * Server-side control of client-side behaviors:  Admins want to know
 that every Subversion user has the same configuration for simple
 things like auto-props rules, and want to be able to control
 things like our store-plaintext-passwords toggles remotely in a
 way that's not easily override-able.


Looking at the current set of variables we have in ~/.subversion/config,
there are a few that set up Subversion to behave according to a user's
individual preference, and don't affect other users:

editor-cmd, diff-cmd, diff3-cmd, merge-tool-cmd, diff-extensions, ssh,
no-unlock, interactive-conflicts

But we also have these which should probably be configured similar
for all users working on the same project anyway:

global-ignores, log-encoding, use-commit-times, mime-types-file,
preserved-conflict-file-exts, enable-auto-props

I haven't looked at the 'servers' file.

I'm not against adding a repository-configuration feature if we really
need it. But before thinking about implementation details of this feature,
such as how one type of configuration setting can override another, we
should clearly define the use cases that require repository-dictated
configuration. And ask ourselves and our users whether repository-dictated
configuration is really the best way of solving these problem. And try to
come up with alternative ways of solving them. Why do we have settings
in the individual client config that all users would want to share anyway?

For instance, regarding auto-props I'm not really sure I understand why
users have to set them in the config in the first place. It makes this
feature quite inconvenient to use in my opinion. At least I've never
been bothered enough to enable it for every-day use. It would be much
nicer if Subversion simply set properties like svn:eol-style up according
to the project's convention, leaving me with the possibility to override
the default before commit.

So maybe having auto-props in the config is part of the problem? What about
having an svn:auto-props property at the parent directory, specifying
autoconf settings for its direct children?
Too inconvenient to set up due to lack of recursive property support?
Would 'svn propset -R' do to configure auto-props for an entire subtree
like '/trunk'? Once those properties were set up and configured, users
could mostly forget about auto-props unless the default auto-props need
to be changed. Not whenever they start working on a different client
computer, as they do today.

So maybe defining additional properties in the svn: namespace that allow
project-wide configuration of Subversion's behaviour would make sense.
svn:global-ignores, svn:log-encoding, svn:use-commit-times,
svn:mime-types-file, svn:preserved-conflict-file-exts, svn:auto-props
The only question left then is about how these properties would be scoped,
i.e. where do you set them and what do they affect.

The store-plaintext-passwords could also be addressed with a configuration
switch that turned off plaintext password storage at compile time. Then
you have to compile your own client to use the feature.
Or we just flip the default from 'ask' to 'no', and let users who really
want their passwords saved in plaintext take an extra step to enable the
behaviour. I think the current default behaviour (prompting) is good
middle-ground, but it's possible that in some environments administrators
really do not want users to have a choice in the matter by default.
Yet users who really want to be disobedient and save their passwords in
plaintext will always be able to do so somehow, no matter what we do.
We can't solve a social problem.

Depending on how admins manage user software, they might be able to install
a system-wide configuration file on their user's machines that tells all
Subversion clients to say 'no' by default.
This is done on OpenBSD when Subversion is installed from the OS-provided
binary package, for instance:
  $ cat /etc/subversion/servers
  # $OpenBSD: servers,v 1.1 2009/08/25 10:26:20 stsp Exp $
  
  [global]
  store-plaintext-passwords=no
  $ 

Stefan

Re: [PATCH] Revert to using zlib-provided compress bound

[Peter Samuelson]

[Michael Spang]
 This reverts to using the zlib-provided version, since the old version
 of zlib that was missing this function should be quite rare these
 days.

Maybe I'm just old ... but I bet there's still some zlib 1.1.4
out there.  Maybe do the following instead?  (Untested.)

[[[
* subversion/libsvn_delta/svndiff.c
  (svnCompressBound): Use zlib compressBound() if available.
]]]

Index: libsvn_delta/svndiff.c
===
--- subversion/libsvn_delta/svndiff.c  (revisione 980368)
+++ subversion/libsvn_delta/svndiff.c  (copia locale)
@@ -31,10 +31,12 @@
 #include svn_private_config.h
 #include zlib.h

-/* This macro is taken from zlib, and was originally the function
-   compressBound.  It shouldn't ever change, but once every millenium,
-   it may be useful for someone to make sure. */
+/* The zlib compressBound function was not exported until 1.2.0. */
+#if ZLIB_VERNUM = 0x1200
+#define svnCompressBound(LEN) compressBound(LEN)
+#else
 #define svnCompressBound(LEN) ((LEN) + ((LEN)  12) + ((LEN)  14) + 11)
+#endif

 /* For svndiff1, address/instruction/new data under this size will not
be compressed using zlib as a secondary compressor.  */

Re: [PATCH] Revert to using zlib-provided compress bound

[Hyrum K. Wright]

On Fri, Aug 6, 2010 at 3:51 PM, Peter Samuelson pe...@p12n.org wrote:

 [Michael Spang]
 This reverts to using the zlib-provided version, since the old version
 of zlib that was missing this function should be quite rare these
 days.

 Maybe I'm just old ... but I bet there's still some zlib 1.1.4
 out there.  Maybe do the following instead?  (Untested.)

You're not old...you just run Debian. ;)

/me ducks.


 [[[
 * subversion/libsvn_delta/svndiff.c
  (svnCompressBound): Use zlib compressBound() if available.
 ]]]

 Index: libsvn_delta/svndiff.c
 ===
 --- subversion/libsvn_delta/svndiff.c      (revisione 980368)
 +++ subversion/libsvn_delta/svndiff.c      (copia locale)
 @@ -31,10 +31,12 @@
  #include svn_private_config.h
  #include zlib.h

 -/* This macro is taken from zlib, and was originally the function
 -   compressBound.  It shouldn't ever change, but once every millenium,
 -   it may be useful for someone to make sure. */
 +/* The zlib compressBound function was not exported until 1.2.0. */
 +#if ZLIB_VERNUM = 0x1200
 +#define svnCompressBound(LEN) compressBound(LEN)
 +#else
  #define svnCompressBound(LEN) ((LEN) + ((LEN)  12) + ((LEN)  14) + 11)
 +#endif

  /* For svndiff1, address/instruction/new data under this size will not
    be compressed using zlib as a secondary compressor.  */