We've managed to review and merge several items in STATUS, but if folks
would take another look at stuff in the next few days, that'd be great
(we'll roll 1.6.12 on Wednesday, probably).
-Hyrum
On Tue, Jun 8, 2010 at 11:15 PM, Hyrum K. Wright <
hyrum_wri...@mail.utexas.edu> wrote:
> That sounds
On Fri, Jun 11, 2010 at 6:54 PM, wrote:
> Author: rhuijben
> Date: Fri Jun 11 16:54:04 2010
> New Revision: 953765
>
> URL: http://svn.apache.org/viewvc?rev=953765&view=rev
> Log:
> Replace two entry stub write operations that reset the stub to only
> an unmodified base node with a temporary wc_d
On Fri, Jun 11, 2010 at 11:51, Greg Stein wrote:
> On Fri, Jun 11, 2010 at 09:35, wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_wc/wc_db.c Fri Jun 11 13:35:24 2010
>>...
>> @@ -4856,11 +4857,31 @@ svn_wc__db_global_relocate(svn_wc__db_t
>> &rb.repos_relpat
On Fri, Jun 11, 2010 at 09:35, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/wc_db.c Fri Jun 11 13:35:24 2010
>...
> @@ -4856,11 +4857,31 @@ svn_wc__db_global_relocate(svn_wc__db_t
> &rb.repos_relpath, &old_repos_root_url,
>
On 04/23/2010 11:24 PM, Stefan Sperling wrote:
On Fri, Apr 23, 2010 at 12:46:44PM -0400, C. Michael Pilato wrote:
As I noted, the check needs to happen inside the client API. The question
becomes "Do we patch svn_client_addX() and svn_client_statusX() and
svn_client_updateX() and ..." or is
Julian Foad writes:
> Ah, you added that svn_opt__eat_peg_revisions() forwarding function
> specifically to support this? Now I understand where you're coming
> from.
You may not have realised, but svn_opt__eat_peg_revisions didn't have
a visible prototype outside the library source file. Noth
On Fri, 2010-06-11 at 11:19 +0100, Philip Martin wrote:
> Greg Stein writes:
>
> > svn_wc_private.h has seen massive changes in 1.7. A 1.6 libsvn_client
> > will not function against 1.7 libraries at all.
>
> It depends what you mean by "at all".
>
> svn up up -r953427 ../src
> ./config.nice --
Greg Stein writes:
> svn_wc_private.h has seen massive changes in 1.7. A 1.6 libsvn_client
> will not function against 1.7 libraries at all.
It depends what you mean by "at all".
svn up up -r953427 ../src
./config.nice --disable-full-version-match
make -j3
for i in subversion/libsvn_*/.libs/lib
On Fri, Jun 11, 2010 at 05:54, Julian Foad wrote:
> Greg Stein wrote:
>> svn_wc_private.h has seen massive changes in 1.7. A 1.6 libsvn_client
>> will not function against 1.7 libraries at all.
>
> Yup, but just to clarify, here I'm not talking about mixing one version
> of libsvn_client versus th
Greg Stein wrote:
> svn_wc_private.h has seen massive changes in 1.7. A 1.6 libsvn_client
> will not function against 1.7 libraries at all.
Yup, but just to clarify, here I'm not talking about mixing one version
of libsvn_client versus the other libs, but rather the client executable
as in "subver
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: vrijdag 11 juni 2010 11:36
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r953617 - in
> /subversion/trunk/subversion/libsvn_wc: merge.c props.c wc-queries.sql
> wc_db.c wc_db.h workqueue.c
On Fri, Jun 11, 2010 at 05:35, Philip Martin wrote:
>...
> This SQL stuff is all a bit new to me. Why do you choose to have
> distinct insert and update queries rather than an insert or replace
> query? Should there be a transaction to combine the SELECT query with
There could be an ACTUAL_NODE
On Fri, Jun 11, 2010 at 05:32, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/log.c Fri Jun 11 09:32:06 2010
>...
> - /* ### this code has a limited set of modifications. enforce it. */
> - SVN_ERR_ASSERT((modify_flags & ~(0
> - /* from props.c */
> -
rhuij...@apache.org writes:
> Author: rhuijben
> Date: Fri Jun 11 09:11:14 2010
> New Revision: 953617
> +svn_error_t *
> +svn_wc__db_temp_op_set_text_conflict_marker_files(svn_wc__db_t *db,
> + const char *local_abspath,
> +
svn_wc_private.h has seen massive changes in 1.7. A 1.6 libsvn_client
will not function against 1.7 libraries at all.
We said a while back that the svn executables and libraries should be
upgraded/downgraded/patched as a group. These internal dependencies
will (thus) remain in sync across the link
On Fri, Jun 11, 2010 at 05:11, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_wc/merge.c Fri Jun 11 09:11:14 2010
>...
> @@ -727,18 +726,16 @@ preserve_pre_merge_files(svn_skel_t **wo
> target_abspath, result_pool));
> *work_items = svn_wc__wq_merge
A question on removing a private API.
In v1.6.5 (r878898) we added the API "svn_opt__eat_peg_revisions()" and
called it from the command-line client. This means 1.6.(>=5) 'svn' is
not compatible with 1.6.(<5) libraries.
What we should have done is to make it a private function within the
client
On Fri, 2010-06-11 at 09:53 +0100, Philip Martin wrote:
> Alexander Thomas writes:
>
> > Yes SUNWuiu8 is the one that comes default with Solaris10 and 646/ASCII
> > conversion to UTF-8 works fine. But for other reasons I should continue
> > using gnu-libiconv.
>
> http://www.mail-archive.com/inf
Alexander Thomas writes:
> Yes SUNWuiu8 is the one that comes default with Solaris10 and 646/ASCII
> conversion to UTF-8 works fine. But for other reasons I should continue
> using gnu-libiconv.
http://www.mail-archive.com/info-gnu%40gnu.org/msg00690.html
Are you using 1.13? It added support fo
On Fri, 2010-06-11 at 08:17 +0100, Philip Martin wrote:
> Alexander Thomas writes:
>
> > Code snippet produced "646".
> >
> > "iconv -f 646 -t UTF-8 /dev/null" returned
> > "iconv: conversion from `646' is not supported"
>
> Google suggests you need to install SUNWuiu8 for 646 to work.
>
> You
"Bert Huijben" writes:
> STMT_INSERT_ACTUAL_NODE does an insert or replace, which might be invalid in
> this case.
Do you mean because copy should not replace an ACTUAL node? I suppose
that's true.
One of the things I am still struggling with is what checking should
happen and where. For exam
julianf...@apache.org writes:
> Author: julianfoad
> Date: Thu Jun 10 19:49:22 2010
> New Revision: 953428
> * subversion/libsvn_subr/opt.c
> (svn_opt__eat_peg_revisions): Remove this wrapper, as compatibility for
> 1.6 for svn executable is not required.
Why is this not required?
We abus
Alexander Thomas writes:
> Code snippet produced "646".
>
> "iconv -f 646 -t UTF-8 /dev/null" returned
> "iconv: conversion from `646' is not supported"
Google suggests you need to install SUNWuiu8 for 646 to work.
You could try setting the environment variable LANG=C, or some other
locale of
23 matches
Mail list logo
