Re: Move tracking and NODES.moved_to/moved_here

2011-12-08 Thread Philip Martin
Julian Foad writes: >> Now consider a further merge, it will produce a tree conflict it it >> attempts to modify X/Y, the modifications should go into X/Z.  If we >> record the Y->Z move then merge can avoid the tree conflict. > > Precisely -- agreed. Another example, see move_on_move, the new t

Re: svn_client_delete4 can segfault

2011-12-08 Thread Philip Martin
Stefan Küng writes: > from a few crash reports sent in for TSVN I was finally able to pin > down the problem: > > in libsvn_client\delete.c, line 240 there's a call > repos_relpath = svn_uri__is_child(repos_root, uri, pool); > > but that can return NULL. > further below then that repos_relpath is

[PATCH] Split up the reintegrate merge API: first find what to do, then do it

2011-12-08 Thread Julian Foad
The current 'reintegrate' merge consists conceptually of two stages:   * Determine what the equivalent two-URL merge is.   * Do the two-URL merge. as well as checking that the target WC is clean and the source and target are ancestrally related. My gut feeling tells me that the libsvn_client

Re: [PATCH] Split up the reintegrate merge API: first find what to do, then do it

2011-12-08 Thread Julian Foad
A comment about taking out a WC write lock. This implementation preserves the current behaviour of taking out a WC write lock aroung the whole reintegrate merge procedure, and does so by using SVN_WC__CALL_WITH_WRITE_LOCK within 'svn'.  That's a bit of a layering violation; if we want 'svn' to

Re: [PATCH] Split up the reintegrate merge API: first find what to do, then do it

2011-12-08 Thread Daniel Shahaf
At a high level, agreed that explicitly exposing more details of reintegrate's semantics would be a good thing. However, I'm not convinced that having three separate APIs as you suggest is a good idea. Are they generally reusable, or do they only make sense when called in sequence, one after the

Re: [PATCH] Split up the reintegrate merge API: first find what to do, then do it

2011-12-08 Thread Daniel Shahaf
Julian Foad wrote on Thu, Dec 08, 2011 at 12:28:23 +: > A comment about taking out a WC write lock. > > This implementation preserves the current behaviour of taking out a WC > write lock aroung the whole reintegrate merge procedure, and does so > by using SVN_WC__CALL_WITH_WRITE_LOCK within '

Re: [PATCH] Split up the reintegrate merge API: first find what to do, then do it

2011-12-08 Thread Julian Foad
Hi Daniel.  Thanks for the feedback and encouragement. Daniel Shahaf wrote: > At a high level, agreed that explicitly exposing more details of > reintegrate's semantics would be a good thing. > > However, I'm not convinced that having three separate APIs as you > suggest is a good idea.  Are th

Re: svn commit: r1211199 - Fix issue #4057 "don't record non-inheritable mergeinfo ..."

2011-12-08 Thread Julian Foad
Paul Burba wrote: > Yes that's what I meant.  But it's a moot point now: In fixing another > issue #4057 bug (see r1211647) I moved this function's code inline to > its only caller.  I also tried to improve the comments there to better > explain what is going on.  Let me know if that doesn't clear

Re: svn commit: r1211908 - /subversion/branches/1.7.x/STATUS

2011-12-08 Thread Hyrum K Wright
Did you mean to remove philip's votes? -Hyrum On Thu, Dec 8, 2011 at 8:26 AM, wrote: > Author: rhuijben > Date: Thu Dec  8 14:26:56 2011 > New Revision: 1211908 > > URL: http://svn.apache.org/viewvc?rev=1211908&view=rev > Log: > * STATUS: Fix text. > > Modified: >    subversion/branches/1.7.x/S

RE: svn commit: r1211908 - /subversion/branches/1.7.x/STATUS

2011-12-08 Thread Bert Huijben
> -Original Message- > From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com] > Sent: donderdag 8 december 2011 15:29 > To: dev@subversion.apache.org > Cc: comm...@subversion.apache.org > Subject: Re: svn commit: r1211908 - /subversion/branches/1.7.x/STATUS > > Did you mean to remove ph

Re: svn commit: r1211199 - in /subversion/trunk/subversion: libsvn_client/merge.c tests/cmdline/merge_tests.py tests/cmdline/mergeinfo_tests.py

2011-12-08 Thread Paul Burba
On Wed, Dec 7, 2011 at 6:45 PM, Philip Martin wrote: > pbu...@apache.org writes: > >> Author: pburba >> Date: Tue Dec  6 22:04:22 2011 >> New Revision: 1211199 >> >> URL: http://svn.apache.org/viewvc?rev=1211199&view=rev >> Log: >> Fix issue #4057 "don't record non-inheritable mergeinfo in shallow

Re: svn commit: r1211199 - in /subversion/trunk/subversion: libsvn_client/merge.c tests/cmdline/merge_tests.py tests/cmdline/mergeinfo_tests.py

2011-12-08 Thread Paul Burba
On Thu, Dec 8, 2011 at 10:08 AM, Paul Burba wrote: > On Wed, Dec 7, 2011 at 6:45 PM, Philip Martin > wrote: >> pbu...@apache.org writes: >> >>> Author: pburba >>> Date: Tue Dec  6 22:04:22 2011 >>> New Revision: 1211199 >>> >>> URL: http://svn.apache.org/viewvc?rev=1211199&view=rev >>> Log: >>> F

Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for Python and Ruby?

2011-12-08 Thread Shane Turner
Looks like the problem is still there: $ grep SVN_VER_REVISION subversion-{1.7.1,1.7.2,nightly}/subversion/include/svn_version.h subversion-1.7.1/subversion/include/svn_version.h:#define SVN_VER_REVISION 1186859 subversion-1.7.2/subversion/include/svn_version.h:#define SVN_VER_REVISION 0 s

Re: Looks like wrong value for SVN_VER_REVISION in SWIG bindings for Python and Ruby?

2011-12-08 Thread Daniel Shahaf
Thanks for checking, Shane. I note that you checked r1211287, which is prior to my yesterday's fix (r1211582), so the bogus values are expected. Shane Turner wrote on Thu, Dec 08, 2011 at 14:39:03 -0400: > Looks like the problem is still there: > > $ grep SVN_VER_REVISION > subversion-{1.7.1,1.7