Here are the messages that have been received prior to 7/11/09 12:15 AM:
Topic (messages 46,975 through 47,097):
r38410 - trunk/subversion/libsvn_auth_gnome_keyring
47,095 by : Gavin Baumanis <gavinb_at_thespidernet.com> sent on : Sat, 11 Jul 2009 15:23:08 +1000
[RFC] *Greatly*improve merge performance...]
47,056 by : David Glasser <glasser_at_davidglasser.net> sent on : Fri, 10 Jul 2009 11:23:50 -0700
47,021 by : Geoff Rowell <geoff.rowell_at_varolii.com> sent on : Fri, 10 Jul 2009 11:09:36 -0400
include libsvn_subr
46,985 by : Julian Foad <julianfoad_at_btopenworld.com> sent on : Fri, 10 Jul 2009 11:59:43 +0100
46,981 by : Senthil Kumaran S <senthil_at_collab.net> sent on : Fri, 10 Jul 2009 15:47:42 +0530
[Issue 3436] New - Short option for --ignore-externals (-i ?)
47,097 by : Edmund Wong <ed_at_kdtc.net> sent on : Sat, 11 Jul 2009 14:57:02 +0800
r38386 - trunk/build/ac-macros
46,983 by : Julian Foad <julianfoad_at_btopenworld.com> sent on : Fri, 10 Jul 2009 11:37:45 +0100
Mismatched backwards compat callbacks in libsvn_wc]
47,093 by : Gavin Baumanis <gavinb_at_thespidernet.com> sent on : Sat, 11 Jul 2009 11:49:29 +1000
Mismatched backwards compat callbacks in libsvn_wc
47,084 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 21:36:15 +0100
[RFC] *Greatly* improve merge performance, but break(?) edge cases
47,026 by : Paul Burba <ptburba_at_gmail.com> sent on : Fri, 10 Jul 2009 12:01:39 -0400
47,007 by : Geoff Rowell <geoff.rowell_at_varolii.com> sent on : Fri, 10 Jul 2009 09:50:03 -0400
47,005 by : "C. Michael Pilato" <cmpilato_at_collab.net> sent on : Fri, 10 Jul 2009 09:45:03 -0400
47,003 by : Stefan Sperling <stsp_at_elego.de> sent on : Fri, 10 Jul 2009 14:31:38 +0100
46,998 by : Greg Troxel <gdt_at_ir.bbn.com> sent on : Fri, 10 Jul 2009 07:52:12 -0400
46,975 by : Julian Foad <julianfoad_at_btopenworld.com> sent on : Fri, 10 Jul 2009 10:22:57 +0100
[PATCH] Give the svn_wc_diff_callbacks*_t wrappers more descriptive names [Was: Mismatched backwards compat callbacks in libsvn_wc]
47,078 by : =?UTF-8?B?0KDQvtC80LDQvSDQlNC+0L3Rh9C10L3QutC+?= <DXDragon_at_yandex.ru> sent on : Sat, 11 Jul 2009 00:08:47 +0400
include libsvn_delta
46,982 by : Julian Foad <julianfoad_at_btopenworld.com> sent on : Fri, 10 Jul 2009 11:35:18 +0100
Report mergeinfo-only changes less verbosely [was: [RFC] *Greatly* improve merge performance...]
47,014 by : Julian Foad <julianfoad_at_btopenworld.com> sent on : Fri, 10 Jul 2009 15:31:47 +0100
+----------------------------------------------------------------------+
| ETAS Mail Security - http://intranet.etasgroup.com/encryption |
+----------------------------------------------------------------------+
| - The message was not encrypted and not digitally signed |
+----------------------------------------------------------------------+
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370622
attached mail follows:
attached mail follows:
Роман Донченко <DXDragon_at_yandex.ru> писал в своём письме Fri, 03 Jul 2009
01:06:23 +0400:
> [[[
> Give the svn_wc_diff_callbacks*_t wrappers more descriptive names.
>
> * subversion/libsvn_wc/deprecated.c: rename callbacks*_wrapper_baton to
> diff_callbacks*_wrapper_baton, callbacks*_wrapper to
> diff_callbacks*_wrapper and the wrapper functions to
> wrap_?to*_<basename>.
> ]]]
Ping. This patch submission has received no comments.
(Yeah, it's not my job to say that... but it's still true. ;=])
Thank you for helping us help you help us all,
Roman.
attached mail follows:
On Fri, Jul 10, 2009 at 8:09 AM, Geoff Rowell<geoff.rowell_at_varolii.com> wrote:
> Julian Foad wrote:
>> Geoff Rowell wrote:
>> > Aside from performance, I wouldn't have such a problem with
> distributed
>> > mergeinfo if it didn't tend to alarm my users. They try to merge a
> few
>> > files and Subversion reports a massive number of changes.
>> >
>> > A serious review of where and when mergeinfo property changes are
>> > reported is needed.
>>
>> We talked once about hiding mergeinfo-only changes from the user, and
>> that was rightly rejected. Did we talk about "sidelining" or
>> "summarising" their display?
>>
>> It seems clear now, with hindsight and lots of mergeinfo, that UIs,
> both
>> our "svn" CLI and GUIs like TortoiseSvn, should help the user to see
> the
>> significant changes without the clutter of mergeinfo-only changes.
>>
>> "svn status" could by default summarize all the mergeinfo-only changes
>> in one line at the end:
>>
>> [[[
>> $ svn status
>> M myfile
>> M dir/myfile2
>> 43 items with changes to mergeinfo are also present but not shown.
>> ]]]
>>
>> "svn commit" when generating a log message could list them separately:
>>
>> [[[
>>
>> --This line, and those below, will be ignored--
>>
>> M myfile
>> MM dir/myfile2
>>
>> The following items have only mergeinfo changes:
>> M .
>> M file1
>> M dir
>> M dir/file4
>> M dir/file5
>> M dir/file6
>> ...
>> M dir/file43
>> ]]]
>>
>> This would require modifications to the "status" and "commit"
>> notification methods, of course. And there are command-line
>> compatibility questions, but it's not a big deal to decide on a
> solution
>> to those.
>>
>> Worth doing?
>>
>> Where are the other places that should have this
> separation/summarising?
>>
>
> I'd also suggest modifying the output of "svn log -v".
That was my first thought as well. That does ~require a repository
format change, though.
--dave
--
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
attached mail follows:
Thanks all for your time and thoughts.
Julian - re other solutions, I agree. In pursuing this particular
path I was trying to find a solution that could be backported to 1.6.
Other solutions to this and other general merge problems are
definitely being considered:
http://svn.collab.net/repos/svn/branches/subtree-mergeinfo/notes/subtree-mergeinfo/solutions-whiteboard.txt.
Re everyone's concern about correctness: I do agree that sacrificing
correctness on the alter of performance is wrong. However, I'm not
sure the current behavior actually is correct. My wording here was
poorly chosen:
> The only problem is that this patch changes the behavior of merge when
> a subtree with explicit mergeinfo has different history, e.g. a
> subtree is deleted and replaced with a copy from a different branch or
> from the same branch but at a different point in it's history. In
> these cases revisions might be included or excluded for merging
> differently than if we ask the repos for the actual implicit mergeinfo
> (what we do today).
I didn't mean that with the patch might be inconsistent in its
behavior, I meant that it will differ from our current behavior (which
is inconsistent).
As I pointed out in issue #3443, currently implicit subtree mergeinfo
which differs from the root of the merge target's implicit mergeinfo
is *only* considered *if* the subtree has explicit mergeinfo. It is
quite possible for a subtree's implicit mergeinfo to differ but for
the subtree to not have explicit mergeinfo, in which case the implicit
mergeinfo difference is completely ignored. Put another way, the
current trunk/1.6 behavior is inconsistent in this situation. So no
matter how we define the correct behavior, at least some of the time,
merge presently does the wrong thing in this "edge" case.
My change would make every subtree's implicit mergeinfo a function of
the merge target's implicit mergeinfo. A subtree's implicit mergeinfo
would not potentially change, as it effectively does today, depending
on whether the subtree has explicit mergeinfo or not. (/me wonders if
anyone actually follows this)
So the patch brings consistency...
...but maybe it makes things consistently wrong. As I rethink this,
I'm hard pressed to say if this is better or worse than how things
work today (ignoring the performance gains).
TODAY - If a subtree has no explicit mergeinfo and differing implicit
mergeinfo, the difference is ignored. If a subtree has explicit
mergeinfo and differing implicit mergeinfo, the difference is
accounted for. This means that merging into a target with
semantically equivalent subtree mergeinfo can produce different
results.
MY PATCH - If a subtree has differing implicit mergeinfo this
difference is always ignored, regardless of whether the subtree has
explicit mergeinfo or not.
So the real question becomes: Should we consider differences in a
subtree's implicit mergeinfo when calculating what needs to be merged?
If the answer is yes, then my patch is wrong as it would take us from
sometimes wrong, to always wrong. If the answer is no, then it makes
things always right.
Beware the easy "yes" and keep in mind that a subtree may *easily*
have differing implicit mergeinfo but have no explicit mergeinfo.
That means every path under a merge target potentially has differing
implicit mergeinfo and we need to detect this*
Paul
* That said, the answer probably is "yes" and this whole avenue is a
dead end (ending at a cliff edge above a river of lava).
attached mail follows:
Julian Foad wrote:
> Geoff Rowell wrote:
> > Aside from performance, I wouldn't have such a problem with
distributed
> > mergeinfo if it didn't tend to alarm my users. They try to merge a
few
> > files and Subversion reports a massive number of changes.
> >
> > A serious review of where and when mergeinfo property changes are
> > reported is needed.
>
> We talked once about hiding mergeinfo-only changes from the user, and
> that was rightly rejected. Did we talk about "sidelining" or
> "summarising" their display?
>
> It seems clear now, with hindsight and lots of mergeinfo, that UIs,
both
> our "svn" CLI and GUIs like TortoiseSvn, should help the user to see
the
> significant changes without the clutter of mergeinfo-only changes.
>
> "svn status" could by default summarize all the mergeinfo-only changes
> in one line at the end:
>
> [[[
> $ svn status
> M myfile
> M dir/myfile2
> 43 items with changes to mergeinfo are also present but not shown.
> ]]]
>
> "svn commit" when generating a log message could list them separately:
>
> [[[
>
> --This line, and those below, will be ignored--
>
> M myfile
> MM dir/myfile2
>
> The following items have only mergeinfo changes:
> M .
> M file1
> M dir
> M dir/file4
> M dir/file5
> M dir/file6
> ...
> M dir/file43
> ]]]
>
> This would require modifications to the "status" and "commit"
> notification methods, of course. And there are command-line
> compatibility questions, but it's not a big deal to decide on a
solution
> to those.
>
> Worth doing?
>
> Where are the other places that should have this
separation/summarising?
>
I'd also suggest modifying the output of "svn log -v".
-Geoff
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.
attached mail follows:
Geoff Rowell wrote:
> Aside from performance, I wouldn't have such a problem with distributed
> mergeinfo if it didn't tend to alarm my users. They try to merge a few
> files and Subversion reports a massive number of changes.
>
> A serious review of where and when mergeinfo property changes are
> reported is needed.
We talked once about hiding mergeinfo-only changes from the user, and
that was rightly rejected. Did we talk about "sidelining" or
"summarising" their display?
It seems clear now, with hindsight and lots of mergeinfo, that UIs, both
our "svn" CLI and GUIs like TortoiseSvn, should help the user to see the
significant changes without the clutter of mergeinfo-only changes.
"svn status" could by default summarize all the mergeinfo-only changes
in one line at the end:
[[[
$ svn status
M myfile
M dir/myfile2
43 items with changes to mergeinfo are also present but not shown.
]]]
"svn commit" when generating a log message could list them separately:
[[[
--This line, and those below, will be ignored--
M myfile
MM dir/myfile2
The following items have only mergeinfo changes:
M .
M file1
M dir
M dir/file4
M dir/file5
M dir/file6
...
M dir/file43
]]]
This would require modifications to the "status" and "commit"
notification methods, of course. And there are command-line
compatibility questions, but it's not a big deal to decide on a solution
to those.
Worth doing?
Where are the other places that should have this separation/summarising?
- Julian
attached mail follows:
On Fri, Jul 10, 2009 at 9:32 AM, Stefan Sperling wrote:
> Since in the end of the day, all Trumerge is doing is using
Subversion's
> merge feature in a way that is possible and technically correct.
Albeit
> this use case has not been envisioned by the designers of the
merge-tracking
> feature. But the fact that what Trumerge does is technically correct
is
> quite important once you look at things in a larger perspective and
put
> merge-tracking and tree-conflict detection next to each other and ask
> yourself if those two features are 100% compatible at the design
level.
> Because eventually, we hope to bring Subversion's tree-conflict
detection
> on par with trumerge (or make it even better). And if we can't do that
> without causing even more performance problems for Subversion, well,
> people won't like it because Subversion will become really unusable.
>
> I'd rather hope that trumerge can be changed to not require subtree
> mergeinfo on every file though, as this thread seems to indicate that
> fixing the subtree mergeinfo problem at the merge-tracking design
> level is hard without harming merge correctness.
>
Aside from performance, I wouldn't have such a problem with distributed
mergeinfo if it didn't tend to alarm my users. They try to merge a few
files and Subversion reports a massive number of changes.
A serious review of where and when mergeinfo property changes are
reported is needed.
-Geoff
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.
attached mail follows:
Stefan Sperling wrote:
> Paul, I don't think that taking the risk of merging incorrect changes
> into subtress, or not merging changes into them which should be merged,
> is a good answer to the performance problem...
> I think we should rather look into minimising network round trips and
> see how much that helps.
I agree. For obvious reasons, I'm sympathetic to the performance issues
that plague TruMerge's user base, but I can't endorse sacrificing
correctness for (mere) speed.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
attached mail follows:
attached mail follows:
Julian Foad <julianfoad_at_btopenworld.com> writes:
> So basically, IF I understood you correctly and IF the behaviour today
> is definitely correct and the proposed behaviour definitely wrong, then
> I am not in favour of such a change. I value the ability to hit "merge"
> and trust the tool to do its job more than I value the ability to hit
> "merge" and have the result quickly but then have to worry about whether
> it did what I expected.
+1
Also, in my world I essentially have a rule against subtree mergeinfo -
we have TTB points for each module, and all tagging/branching/merging is
supposed to be at those points. So while I value correctness in all
cases, I am only concerned about efficiency for reasonable use cases.
Is there an example somewhere on the web about a use case where large
amounts of subtree mergeinfo really makes sense?
attached mail follows:
On Fri, 2009-07-10 at 15:47 +0530, Senthil Kumaran S wrote:
> Julian Foad wrote:
> > Author: julianfoad
> > Date: Thu Jul 9 05:26:08 2009
> > New Revision: 38381
> ...
> > +/** Return the key of the hash table entry indexed by @a hi. */
> > +const void *svn_apr_hash_index_key(const apr_hash_index_t *hi);
>
> Should "hi" be 'const' here? Since "hi" does not get modified by calling
> 'apr_hash_this'.
The argument is a pointer to the hash index structure. Neither the hash
index structure nor the pointer variable 'hi' get modified. I used
"const" on the pointer's target so that the caller can be sure the
function won't modify the pointed-to data.
When Greg said "I'd suggest changing the HI parameter to a const [...]",
I am confident that this is what he meant.
It sounds like you are asking about the argument "hi" itself. A C
function can never change the caller's copy of the argument because
arguments are always passed by value, so there is never any point in
making the argument itself "const".
So this is fine:
void foo(const char *s)
{
/* skip the first character of the string */
s++; /* doesn't affect the caller */
...
}
and this is silly:
void foo(const char *const s)
{
/* within the function body, formal parameter 's' is constant */
}
because it clutters the interface while making no difference to the
caller and having only a minor effect on the implementation.
> > +/** Return the key length of the hash table entry indexed by @a hi. */
> > +apr_ssize_t svn_apr_hash_index_klen(const apr_hash_index_t *hi);
>
> Same here.
>
> > +/** Return the value of the hash table entry indexed by @a hi. */
> > +void *svn_apr_hash_index_val(const apr_hash_index_t *hi);
>
> Same here.
>
> Thank You.
Thanks for the thought.
- Julian
attached mail follows:
Arfrever Frehtes Taifersar Arahesis wrote:
> Author: arfrever
> Date: Thu Jul 9 09:59:57 2009
> New Revision: 38386
>
> Log:
> Follow-up to r38377:
> Rename SVN_REMOVE_REDUNDANT_LIB_DIRS to SVN_REMOVE_STANDARD_LIB_DIRS.
>
> * build/ac-macros/svn-macros.m4
> (SVN_REMOVE_REDUNDANT_LIB_DIRS): Rename to ...
> (SVN_REMOVE_STANDARD_LIB_DIRS): ... this. Improve doc string.
Thanks. That is much better.
Please also mention the functional change here.
- Julian
> * build/ac-macros/apr.m4
> (SVN_LIB_APR):
> * build/ac-macros/aprutil.m4
> (SVN_LIB_APRUTIL):
> * build/ac-macros/gssapi.m4
> (SVN_LIB_RA_SERF_GSSAPI):
> * build/ac-macros/kwallet.m4
> (SVN_LIB_KWALLET):
> * build/ac-macros/sasl.m4
> (SVN_LIB_SASL):
> * build/ac-macros/sqlite.m4
> (SVN_SQLITE_DIR_CONFIG):
> * build/ac-macros/zlib.m4
> (SVN_LIB_Z): Update.
>
> Suggested by: julianfoad
> stsp
>
> Modified:
> trunk/build/ac-macros/apr.m4
> trunk/build/ac-macros/aprutil.m4
> trunk/build/ac-macros/gssapi.m4
> trunk/build/ac-macros/kwallet.m4
> trunk/build/ac-macros/sasl.m4
> trunk/build/ac-macros/sqlite.m4
> trunk/build/ac-macros/svn-macros.m4
> trunk/build/ac-macros/zlib.m4
>
> Modified: trunk/build/ac-macros/apr.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/apr.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/apr.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/apr.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -63,7 +63,7 @@ AC_DEFUN(SVN_LIB_APR,
> if test $? -ne 0; then
> AC_MSG_ERROR([apr-config --ldflags failed])
> fi
> - LDFLAGS="$LDFLAGS `SVN_REMOVE_REDUNDANT_LIB_DIRS($apr_ldflags)`"
> + LDFLAGS="$LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS($apr_ldflags)`"
>
> SVN_APR_INCLUDES="`$apr_config --includes`"
> if test $? -ne 0; then
> @@ -86,7 +86,7 @@ AC_DEFUN(SVN_LIB_APR,
> AC_MSG_ERROR([apr-config --link-ld failed])
> fi
> fi
> - SVN_APR_LIBS="`SVN_REMOVE_REDUNDANT_LIB_DIRS($SVN_APR_LIBS)`"
> + SVN_APR_LIBS="`SVN_REMOVE_STANDARD_LIB_DIRS($SVN_APR_LIBS)`"
>
> SVN_APR_SHLIB_PATH_VAR="`$apr_config --shlib-path-var`"
> if test $? -ne 0; then
>
> Modified: trunk/build/ac-macros/aprutil.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/aprutil.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/aprutil.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/aprutil.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -66,7 +66,7 @@ AC_DEFUN(SVN_LIB_APRUTIL,
> if test $? -ne 0; then
> AC_MSG_ERROR([apu-config --ldflags failed])
> fi
> - LDFLAGS="$LDFLAGS `SVN_REMOVE_REDUNDANT_LIB_DIRS($apu_ldflags)`"
> + LDFLAGS="$LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS($apu_ldflags)`"
>
> SVN_APRUTIL_INCLUDES="`$apu_config --includes`"
> if test $? -ne 0; then
> @@ -89,7 +89,7 @@ AC_DEFUN(SVN_LIB_APRUTIL,
> AC_MSG_ERROR([apu-config --link-ld failed])
> fi
> fi
> - SVN_APRUTIL_LIBS="`SVN_REMOVE_REDUNDANT_LIB_DIRS($SVN_APRUTIL_LIBS)`"
> + SVN_APRUTIL_LIBS="`SVN_REMOVE_STANDARD_LIB_DIRS($SVN_APRUTIL_LIBS)`"
>
> AC_SUBST(SVN_APRUTIL_INCLUDES)
> AC_SUBST(SVN_APRUTIL_LIBS)
>
> Modified: trunk/build/ac-macros/gssapi.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/gssapi.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/gssapi.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/gssapi.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -36,7 +36,7 @@ AC_DEFUN(SVN_LIB_RA_SERF_GSSAPI,
> CFLAGS=""
> SVN_GSSAPI_INCLUDES="`$KRB5_CONFIG --cflags`"
> SVN_GSSAPI_LIBS="`$KRB5_CONFIG --libs gssapi`"
> - SVN_GSSAPI_LIBS="`SVN_REMOVE_REDUNDANT_LIB_DIRS($SVN_GSSAPI_LIBS)`"
> + SVN_GSSAPI_LIBS="`SVN_REMOVE_STANDARD_LIB_DIRS($SVN_GSSAPI_LIBS)`"
> CPPFLAGS="$CPPFLAGS $SVN_GSSAPI_INCLUDES"
> CFLAGS="$old_CFLAGS"
> LIBS="$LIBS $SVN_GSSAPI_LIBS"
>
> Modified: trunk/build/ac-macros/kwallet.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/kwallet.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/kwallet.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/kwallet.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -52,7 +52,7 @@ AC_DEFUN(SVN_LIB_KWALLET,
> LIBS="$LIBS $SVN_KWALLET_LIBS"
> qt_lib_dirs="`$PKG_CONFIG --libs-only-L QtCore QtDBus QtGui`"
> kde_lib_suffix="`$KDE4_CONFIG --libsuffix`"
> - LDFLAGS="$old_LDFLAGS `SVN_REMOVE_REDUNDANT_LIB_DIRS($qt_lib_dirs -L$kde_dir/lib$kde_lib_suffix)`"
> + LDFLAGS="$old_LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS($qt_lib_dirs -L$kde_dir/lib$kde_lib_suffix)`"
> AC_LANG(C++)
> AC_LINK_IFELSE([
> #include <kwallet.h>
>
> Modified: trunk/build/ac-macros/sasl.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/sasl.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/sasl.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/sasl.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -49,7 +49,7 @@ AC_DEFUN(SVN_LIB_SASL,
> if test "$svn_lib_sasl" = "no"; then
> SVN_SASL_INCLUDES="-I${with_sasl}/include"
> CPPFLAGS="$CPPFLAGS $SVN_SASL_INCLUDES"
> - LDFLAGS="$LDFLAGS `SVN_REMOVE_REDUNDANT_LIB_DIRS(-L${with_sasl}/lib)`"
> + LDFLAGS="$LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS(-L${with_sasl}/lib)`"
>
> AC_CHECK_HEADER(sasl/sasl.h,
> [AC_CHECK_HEADER(sasl/saslutil.h,
>
> Modified: trunk/build/ac-macros/sqlite.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/sqlite.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/sqlite.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/sqlite.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -142,7 +142,7 @@ SQLITE_VERSION_OKAY
> SVN_SQLITE_LIBS="-lsqlite3"
> else
> SVN_SQLITE_INCLUDES="-I$sqlite_dir/include"
> - SVN_SQLITE_LIBS="`SVN_REMOVE_REDUNDANT_LIB_DIRS(-L$sqlite_dir/lib -lsqlite3)`"
> + SVN_SQLITE_LIBS="`SVN_REMOVE_STANDARD_LIB_DIRS(-L$sqlite_dir/lib -lsqlite3)`"
> fi
> ])], [AC_MSG_RESULT([unsupported SQLite version])])
> ])
>
> Modified: trunk/build/ac-macros/svn-macros.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/svn-macros.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/svn-macros.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/svn-macros.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -153,10 +153,16 @@ AC_DEFUN(SVN_MAYBE_ADD_TO_CFLAGS,
> fi
> ])
>
> -dnl SVN_REMOVE_REDUNDANT_LIB_DIRS
> +dnl SVN_REMOVE_STANDARD_LIB_DIRS(OPTIONS)
> dnl
> -dnl Remove redundant library directories (e.g. /usr/lib).
> -AC_DEFUN([SVN_REMOVE_REDUNDANT_LIB_DIRS],
> +dnl Remove standard library search directories.
> +dnl OPTIONS is a list of compiler/linker options.
> +dnl This macro prints input options except -L options whose arguments are
> +dnl standard library search directories (e.g. /usr/lib).
> +dnl
> +dnl This macro is used to avoid linking against Subversion libraries
> +dnl potentially placed in standard library search directories.
> +AC_DEFUN([SVN_REMOVE_STANDARD_LIB_DIRS],
> [
> input_flags="$1"
> output_flags=""
> @@ -164,7 +170,7 @@ AC_DEFUN([SVN_REMOVE_REDUNDANT_LIB_DIRS]
> for flag in $input_flags; do
> filter="no"
> for dir in $filtered_dirs; do
> - if test "$flag" = "-L$dir"; then
> + if test "$flag" = "-L$dir" || test "$flag" = "-L$dir/"; then
> filter="yes"
> break
> fi
>
> Modified: trunk/build/ac-macros/zlib.m4
> URL: http://svn.collab.net/viewvc/svn/trunk/build/ac-macros/zlib.m4?pathrev=38386&r1=38385&r2=38386
> ==============================================================================
> --- trunk/build/ac-macros/zlib.m4 Thu Jul 9 08:38:08 2009 (r38385)
> +++ trunk/build/ac-macros/zlib.m4 Thu Jul 9 09:59:57 2009 (r38386)
> @@ -41,7 +41,7 @@ AC_DEFUN(SVN_LIB_Z,
> if test "$zlib_found" = "yes"; then
> SVN_ZLIB_PREFIX="$zlib_prefix"
> SVN_ZLIB_INCLUDES="-I$zlib_prefix/include"
> - LDFLAGS="$LDFLAGS `SVN_REMOVE_REDUNDANT_LIB_DIRS(-L$zlib_prefix/lib)`"
> + LDFLAGS="$LDFLAGS `SVN_REMOVE_STANDARD_LIB_DIRS(-L$zlib_prefix/lib)`"
> fi
>
> SVN_ZLIB_LIBS="-lz"
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=2369450
attached mail follows:
On Thu, 2009-07-09 at 15:53 -0700, Neels Janosch Hofmeyr wrote:
> Author: neels
> Date: Thu Jul 9 15:53:33 2009
> New Revision: 38394
>
> Log:
> Enable an atomic replace in editor v2.
>
> * subversion/include/svn_editor.h
> (svn_editor_add_directory_t, svn_editor_add_directory,
> svn_editor_add_file_t, svn_editor_add_file,
> svn_editor_add_symlink_t, svn_editor_add_symlink,
> svn_editor_add_absent_t, svn_editor_add_absent):
> Add parameter REPLACES_REV.
Where is this parameter documented?
- Julian
> * subversion/libsvn_delta/editor.c
> (svn_editor_add_directory,
> svn_editor_add_file,
> svn_editor_add_symlink,
> svn_editor_add_absent):
> Add parameter REPLACES_REV and pass to callbacks.
attached mail follows:
Julian Foad wrote:
> Author: julianfoad
> Date: Thu Jul 9 05:26:08 2009
> New Revision: 38381
...
> +/** Return the key of the hash table entry indexed by @a hi. */
> +const void *svn_apr_hash_index_key(const apr_hash_index_t *hi);
Should "hi" be 'const' here? Since "hi" does not get modified by calling
'apr_hash_this'.
> +/** Return the key length of the hash table entry indexed by @a hi. */
> +apr_ssize_t svn_apr_hash_index_klen(const apr_hash_index_t *hi);
Same here.
> +/** Return the value of the hash table entry indexed by @a hi. */
> +void *svn_apr_hash_index_val(const apr_hash_index_t *hi);
Same here.
Thank You.
--
Senthil Kumaran S
http://www.stylesen.org/
attached mail follows:
Paul Burba wrote:
> A thinly veiled plea for some eyes on issue #3443...
[...]
> 1) Are the cases where subtrees in a merge target have different
> implicit mergeinfo than the rest of the target common use cases or
> highly contrived edge cases?. I think the latter is true, certainly
> the vanilla release and feature branch models aren't affected, but am
> I missing something obvious? I've spent so much time close to this
> that I might be missing the forest for the trees.
>
> 2) Assuming subtrees with differing implicit mergeinfo are edge cases,
> is there any reason *not* to make the changes suggested by the patch
> in issue #3443?
Hi Paul.
I can't answer (1) with empirical evidence. All I can do is offer my
perspective. Please forgive me if I'm labouring my point in this long
email.
Before you read on, be aware that I am not 100% sure that the behaviour
change you propose is actually a change from correctness to
incorrectness, but it sounds like it is so that's what I am assuming.
We are in a position where we fully support a certain limited kind of
merging scenario, and we also claim that Subversion can to some extent
cope with a much wider range of scenarios, and we hope to improve this.
When a tool does a complex job (merging) and is used in a complex
setting (software development, typically), users need to understand as
best they can what it does, and then apply it over and over. Because
they had to choose from the set of available version control systems,
none of which completely fulfills all of their needs, they are
inevitably using Subversion in some capacity that is a stretch for its
suitability in one way or another. Some of them are stretching the merge
capabilities and not able to stick to the most basic and fully supported
merging scenarios.
We tell them it has this complex but describable behaviour. If we then
tell them that in another scenario, with similar recent history but
different ancient history, it may omit parts of the merge (without even
telling the user that anything is amiss), then the user will rightly
lose confidence, or will go ahead and use it and then be bitterly
disappointed one day when they discover the problem. We can say, "You
liked it because it did the merges quickly." And they may reply, "It was
working fine, and then we used it in a an obviously similar scenario and
apparently it didn't work, so now we have to recall and fix our product.
We know that it has limitations, but we've discovered you did this
deliberately. Thanks a bunch."
When a software tool doesn't behave predictably and consistently, it
frustrates efforts to integrate it into a larger system. I would say
building GUIs around Subversion is such a case.
I think there is an equally important point on the Subversion
development side, too. From my point of view as a Subversion developer,
I think designing WHAT it does - the behaviour - is the more complex
task, and implementing that behaviour, though time consuming and still
complex, is the more accessible task.
If we design and implement the right behaviour, but it is slow, a new
developer can look at it and find ways to implement that same behaviour
more efficiently. (For example, pipelining the network requests to
eliminate the multiple-turnaround delay.) In our line of work, almost
any algorithm that executes slowly can be speeded up immensely by a
better implementation. That may be a complex task to many of us, but
there are a reasonable number of people who step up to do such tasks. It
is a self-contained task, with regression tests already in place, and
the roll-out brings only goodness to the users.
If we knowingly implement something that is not the correct behaviour,
then it is a much harder task for anyone later to redesign the correct
behaviour while also having to contemplate the effects on the user base
of making such a change. It is not sufficient to leave a comment in the
source saying, "The correct behavior would be X. Here, we knowingly do
Y." Changing the behaviour requires not just changing the source but
also testing, writing new tests, understanding old tests, and managing
users' experiences with the upgrade. And the re-implementation of X
would surely be as difficult as it was the first time around.
The definition of an "edge case" is that which we don't see happening
very often or which can easily be avoided. The trouble with dismissing
"edge cases" is that (a) although rare as an average across the
experience we have encountered so far, when a user hits one it often
becomes common for that user; and (b) when an edge case occurs in one
sub-set of a set of complex behaviours, as the combinations multiply up,
a whole large class of scenarios becomes unusable or unreliable.
The fact that the current regression tests don't catch the shortcomings
is just a result of their simplicity and we can be sure that real users
will run into problems. Haven't you spent, um, a *bit* of time fixing
"edge cases" that turned out to be actually rather important even if
they are still uncommon on average?
You have not found a way to speed it up immensely while keeping the
behaviour, but I think you should put this proposal out as a kick-off
point for other people to tackle that problem, and you should not feel
you have to implement something fast even at the expense of correctness.
All the foregoing assumes that the current behaviour w.r.t. sub-trees is
"correct" and skipping them is "wrong". That is a definition we could
consider changing. One alternative to keeping the "correct" behaviour is
to explicitly not support arbitrary merges with mixed sub-tree
mergeinfo. I can't see us choosing that option but maybe the line of
thought will lead somewhere.
Or maybe there are opportunities for higher level redesign of the
mergeinfo storage scheme that would make the implementation easier. For
example, if we were to rearrange the mergeinfo so that it explicitly
holds some info about "implicit" mergeinfo as well, maybe that could
enable major optimisations to be made in the look-up algorithms. (That's
not a thought-out proposal, just a top-of-of-my-head example.)
So basically, IF I understood you correctly and IF the behaviour today
is definitely correct and the proposed behaviour definitely wrong, then
I am not in favour of such a change. I value the ability to hit "merge"
and trust the tool to do its job more than I value the ability to hit
"merge" and have the result quickly but then have to worry about whether
it did what I expected.
Regards,
- Julian
attached mail follows:
Olivier FAURAX wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3436
> Issue #|3436
> Summary|Short option for --ignore-externals (-i ?)
> Component|subversion
> Version|all
> Platform|All
> URL|
> OS/Version|All
> Status|NEW
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|ENHANCEMENT
> Priority|P5
> Subcomponent|cmdline client
> Assigned to|issues_at_subversion
> Reported by|ofaurax_neotion
>
>
>
>
>
>
> ------- Additional comments from ofaurax_neotion_at_tigris.org Wed Jun 24 01:31:46 -0700 2009 -------
> Hello,
>
> When working with big or lots of external repositories, "svn up" or "svn st" are
> much more fast with "--ignore-externals".
> However, the option is longer than the command itself (!), which is boring when
> working in command line.
>
> Is it possible to add a short option for --ignore-externals, for example -i or -I ?
>
Does anyone have any objections about this issue? If not, how about
objections about me taking this? If not, is there policy as to which
character to use? (My tendency is towards '-i'.)
Edmund
attached mail follows:
Just out of curiosity,
Am I wrong is the new text in this patch, the same as the deletions?
Gavin.
On 11/07/2009, at 1:46 PM, Arfrever Frehtes Taifersar Arahesis wrote:
> Author: arfrever
> Date: Fri Jul 10 20:46:13 2009
> New Revision: 38410
>
> Log:
> * subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
> (simple_gnome_keyring_first_creds, simple_gnome_keyring_save_creds,
> ssl_client_cert_pw_gnome_keyring_first_creds,
> ssl_client_cert_pw_gnome_keyring_save_creds): Fix some messages.
>
> Modified:
> trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
>
> Modified: trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c
> URL: http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c?pathrev=38410&r1=38409&r2=38410
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c Fri
> Jul 10 14:41:48 2009 (r38409)
> +++ trunk/subversion/libsvn_auth_gnome_keyring/gnome_keyring.c Fri
> Jul 10 20:46:13 2009 (r38410)
> @@ -411,7 +411,7 @@ simple_gnome_keyring_first_creds(void **
> {
> return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
> _("GNOME Keyring is locked and "
> - " we are non-interactive"));
> + "we are non-interactive"));
> }
> else
> {
> @@ -470,7 +470,7 @@ simple_gnome_keyring_save_creds(svn_bool
> {
> return svn_error_create(SVN_ERR_AUTHN_CREDS_NOT_SAVED, NULL,
> _("GNOME Keyring is locked and "
> - " we are non-interactive"));
> + "we are non-interactive"));
> }
> else
> {
> @@ -566,7 +566,7 @@ ssl_client_cert_pw_gnome_keyring_first_c
> {
> return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
> _("GNOME Keyring is locked and "
> - " we are non-interactive"));
> + "we are non-interactive"));
> }
> else
> {
> @@ -626,7 +626,7 @@ ssl_client_cert_pw_gnome_keyring_save_cr
> {
> return svn_error_create(SVN_ERR_AUTHN_CREDS_UNAVAILABLE, NULL,
> _("GNOME Keyring is locked and "
> - " we are non-interactive"));
> + "we are non-interactive"));
> }
> else
> {
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=495&dsMessageId=2370607
Gavin Baumanis
P: +61 438 545 586
E: gavinb_at_thespidernet.com
attached mail follows:
Hi Roman,
Absolutely nothing wrong with "pinging" your own patch.
Gavin.
On 11/07/2009, at 6:08 AM, Роман Донченко wrote:
> Роман Донченко <DXDragon_at_yandex.ru> писал в
> своём письме Fri, 03 Jul 2009
> 01:06:23 +0400:
>
>> [[[
>> Give the svn_wc_diff_callbacks*_t wrappers more descriptive names.
>>
>> * subversion/libsvn_wc/deprecated.c: rename
>> callbacks*_wrapper_baton to
>> diff_callbacks*_wrapper_baton, callbacks*_wrapper to
>> diff_callbacks*_wrapper and the wrapper functions to
>> wrap_?to*_<basename>.
>> ]]]
>
> Ping. This patch submission has received no comments.
>
> (Yeah, it's not my job to say that... but it's still true. ;=])
>
> Thank you for helping us help you help us all,
> Roman.
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2370140
Received on 2009-07-11 09:16:01 CEST