Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

On 25.06.2015 18:11, Evgeny Kotkov wrote: > Branko Čibej writes: > >> Go ahead; I won't be able to for the next few days. Please remember to >> remove the new error code, too, if we won't be using it any more. > With a bit of trial and error, I was able to come up with a complete and > tested solu

Re: svn commit: r1682265 - /subversion/trunk/subversion/libsvn_fs_fs/util.c

On 24 June 2015 at 10:41, Branko Čibej wrote: > On 23.06.2015 19:29, Ivan Zhakov wrote: >> >> I've prepared a patch that fixes svn_io_file_rename() to consistently >> return error for cross volume renames on Windows using platform >> specific code. See svn-rename-no-copy-allowed-v1.patch.txt. >> R

Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

Evgeny Kotkov writes: > See the attached patch. Please note that the patch is not a continuation of > what I posted in my last e-mail (verify-fixup-squashed-v1.patch.txt), but > from my point of view is better and should address the raised concerns, such > as having a non-trivial compatibility w

Re: Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1

Branko Čibej writes: > Go ahead; I won't be able to for the next few days. Please remember to > remove the new error code, too, if we won't be using it any more. With a bit of trial and error, I was able to come up with a complete and tested solution that I find suitable in terms of the API desi

svn-mergeinfo-normalizer ideas

Hi, I'm dealing with one remaining case svn-mergeinfo-normalizer normalize doesn't seem to be able to handle yet. Would it be possible to add support for this? Case: Eliminate incorrect mergeinfos of pre-branch-revisions. Looking at the following output: Trying to elide mergeinfo from path

Re: inconsistency between mergeinfo records

Hi, as promised, answering the remaining questions now: [...] If you have any time requirements/considerations on your side which would require/benefit from earlier feedback, pls let me know. Right now, we are all working towards the 1.9 RC. Feedback in May or June would be nice. The

multiple conflicts per path (was: Re: svn commit: r1687489 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/resolved.c svn/cl-conflicts.c svn/cl-conflicts.h svn/conflict-callbacks

On Thu, Jun 25, 2015 at 12:59:16PM +, Bert Huijben wrote: > I think it would help future conflict resolve code if we call the conflict > resolver only once per conflicted path. This would allow providing all > conflict details ( | ) to a user, which can then really > apply resolve operations

Re: inconsistency between mergeinfo records

Hi Stefan, If you have a working build environment for Subversion, you might have a look at this branch: https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer It provides a new tool that you might find useful: ./tools/client-sid

RE: svn commit: r1687456 - in /subversion/trunk/subversion:include/svn_client.h svn/conflict-callbacks.c

Does this simplification properly handle binary files that can't be automatically merged? (Hard to tell by looking at these patches from my phone :-)) Bert -Original Message- From: "s...@apache.org" Sent: ‎25-‎6-‎2015 11:20 To: "comm...@subversion.apache.org" Subject: svn commit: r168

Re: mergeinfo-normalizer issue with irrelevant ranges

Hi On Wed, Jun 24, 2015 at 4:58 PM, Stefan Hett > wrote: Hi, hope it's ok to discuss this on this list rather than the users list (since the tool is not part of a released version): I'm looking at the following output from mergeinfo-normalizer analyse