Re: svn commit: r950127 - in /subversion/trunk/subversion/libsvn_wc: adm_ops.c adm_ops.h update_editor.c

On Tue, Jun 1, 2010 at 11:50, wrote: >... > +++ subversion/trunk/subversion/libsvn_wc/adm_ops.c Tue Jun  1 15:50:55 2010 >... > +  if (new_repos_relpath != NULL) >     { > -      modify_flags |= SVN_WC__ENTRY_MODIFY_URL; > -      tmp_entry.url = new_url; > +      const char *new_url = svn_path_ur

Re: USE_DB_PROPS define

On Fri, Jun 4, 2010 at 16:36, Hyrum K. Wright wrote: > On Thu, Jun 3, 2010 at 4:06 PM, Greg Stein wrote: >> On Wed, May 26, 2010 at 15:44, Hyrum K. Wright >> wrote: >> > To anybody concerned: >> > We currently use the USE_DB_PROPS define to filter out the experimental >> > use >> > of exclusive

Re: USE_DB_PROPS define

On Thu, Jun 3, 2010 at 4:06 PM, Greg Stein wrote: > On Wed, May 26, 2010 at 15:44, Hyrum K. Wright > wrote: > > To anybody concerned: > > We currently use the USE_DB_PROPS define to filter out the experimental > use > > of exclusive in-db-properties. Since that will be implemented in format > 1

Re: Segfault in the Ruby bindings

This might be related to r948540. Bert adjusted how status->entry is filled in. Maybe some kind of lifetime issue? On Fri, Jun 4, 2010 at 15:28, Hyrum K. Wright wrote: > Some of you may have noticed that there is a failing ruby bindings test. > I've done a little bit of digging, but haven't had a

Segfault in the Ruby bindings

Some of you may have noticed that there is a failing ruby bindings test. I've done a little bit of digging, but haven't had a chance to get too far. The following stack trace shows where the problem is: test_merge(SvnClientTest): Program received signal SIGSEGV, Segmentation fault. __strlen_sse2 (

Re: svn commit: r937524 - in /subversion/trunk/subversion: libsvn_wc/props.c tests/cmdline/prop_tests.py tests/cmdline/svntest/sandbox.py

On Fri, Jun 4, 2010 at 2:00 PM, Greg Stein wrote: > On Fri, May 21, 2010 at 10:53, Paul Burba wrote: >> On Thu, May 20, 2010 at 4:59 PM, Greg Stein wrote: >>> Thanks for the ping. >>> >>> The patch looks good except for the incoming-delete case. >> >> Hi Greg, >> >> Which flavor of that case? In

Re: svn commit: r937524 - in /subversion/trunk/subversion: libsvn_wc/props.c tests/cmdline/prop_tests.py tests/cmdline/svntest/sandbox.py

On Fri, May 21, 2010 at 10:53, Paul Burba wrote: > On Thu, May 20, 2010 at 4:59 PM, Greg Stein wrote: >> Thanks for the ping. >> >> The patch looks good except for the incoming-delete case. > > Hi Greg, > > Which flavor of that case? Incoming delete on a local delete of the > same property with t

Re: wc-to-wc copies and wc-ng

On Fri, Jun 4, 2010 at 10:18, Philip Martin wrote: > Greg Stein writes: > >> (*) and if the work items cannot succeed, then we have problems. I >> could imagine the process is killed during the wq run, some source >> files are torched, and then the destination is cleaned up (ie. wq is >> run agai

Re: Are we going to use svn_wc__db_kind_symlink?

The intent would be to migrate svn:special nodes into kind_symlink for storage and use throughout wc, and then back to svn:special at the "edge". It's a much more sane way to handle symlinks. (especially if you've ever looked at the svn_subst.h handling for this stuff!) Will we get it done for 1.7

Are we going to use svn_wc__db_kind_symlink?

As far as I can tell we are not yet using svn_wc__db_kind_symlink for versioned symlinks, they are still stored as svn_wc__db_kind_file. Is this going to change at some point? -- Philip

Re: wc-to-wc copies and wc-ng

Greg Stein writes: > (*) and if the work items cannot succeed, then we have problems. I > could imagine the process is killed during the wq run, some source > files are torched, and then the destination is cleaned up (ie. wq is > run again). Without the source files, then we'd have problem > comp