Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode
Note that the commit logic in libsvn_client uses exactly the same driver pattern, but even in a more extreme way: it opens all nodes before closing the first file that will receive content changes. Serf was only the first driver to do it this way in the other direction. Bert Sent from Windows Mail From: Branko Čibej Sent: Saturday, July 6, 2013 2:34 AM To: users@subversion.apache.org Cc: Subversion Development; g...@vger.kernel.org [Copying dev@ because it's related to a known issue that we document more loudly.] On 06.07.2013 00:51, David Rothenberger wrote: I cannot reproduce this problem using command-line tools, but I was able to do a trace of git-svn when it is failing and it looks to me that the problem is in the order in which the SVN::Delta::Editor (svn_delta_editor_t) function are being called. The order I see is: 1. open_root 2. open_directory 3. add_file 4. apply_textdelta 5. add_file 6. apply_textdelta The git-svn code is expecting a close_file call before the add_file call in #5. It appears to me that the svn_delta_editor_t API [1] requires this close_file call. It looks to me like this is Issue #2932 [2]. Indeed it is. And it is actually documented here: https://svn.apache.org/repos/asf/subversion/trunk/notes/api-errata/1.7/ra001.txt and mentioned here: http://subversion.apache.org/docs/release-notes/1.7.html#svnrdump In other words, this is a limitation of the Serf-based backend that has been around since Subversion 1.4. I'm aware that it isn't documented as well as it should be, but the bulk-mode workaround exists in part as a workaround for that, effectively disabling the more efficient HTTPv2 protocol. In the meantime, it might be a good idea to relax the restrictions in git-svn to account for the way the HTTPv2 protocol works. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Cost and Installation
On 07/04/2013 04:49 PM, Nico Kadel-Garcia wrote: It's an open source project. That means you can install it free, with your own engineer's time, pretty easily. The term "open source" only means that the source code is made available. Subversion's licensing is way better than that. Subversion is distributed under a free software license, which not only grants the right to access the source code (i.e., it's open source) but it also grants everyone the right to freely distribute it and also modify it as they may see fit. The second bit is the bit which is really important. http://subversion.apache.org/faq.html#collab -- Zé
Parallel checkout within checkout
Hi, I am trying to find out if some new behavior we see with version 1.7 is considered a bug (I would). What we try to do is assembling a larger piece of software from tens or hundreds of repositories. In that, checkouts might also live within checkouts of other svn repositories. We usually checkout these in parallel, but because the contained checkout isn't using a subdirectory name that would be part of the containing repository, this wasn't a problem in the past. However, version 1.7 seems to change this. Trying to checkout the contained repository while the containing repository isn't finished yet (parallel checkout) produces errors like svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted My theory is that the checkout of the contained repository tries to look into .svn of the containing repository, and finds it 'currently used'. This was not the case for versions <1.7, maybe because these didn't use a 'central' .svn directory. I would now argue that this is a regression, since svn <1.7 worked fine in this scenario, while >=1.7 doesn't. Ways to reproduce: 1. svn co some_repo 2. interrupt during checkout (control-Z) 3. cd into new (partial) checkout 4. svn co some_other_repo thanks, Frank Loeffler signature.asc Description: Digital signature
Re: Some sync merges no more allowed with 1.8 client ?
Eric Estievenart wrote on Fri, Jul 05, 2013 at 19:28:30 +0200:
> svn: E205000: Try 'svn help merge' for more information
> svn: E205000: Source and target must be different but related branches
> svn: E205000: Source and target have no common ancestor:
> 'svn://myserver/app/v1@head' and '.@unspecified'
> (Whereas the sync merge worked flawlessly with all 1.7 clients, with proper
> merge tracking).
I believe '--ignore-ancestry' is supposed to override this particular check.
The code has changed on 1.8.x@HEAD since 1.8.0[1], so 1.8.1 will behave
differently. (It will probably just issue a different error message,
since [1] claims that it didn't change the checks being done.)
Daniel
[1]
% $svn mergeinfo --show-revs=eligible
^/subversion/{branches/1.8.x,tags/1.8.0}/subversion/svn/merge-cmd.c --log
r1495282 | svn-role | 2013-06-21 04:00:42 + (Fri, 21 Jun 2013) | 14 lines
Merge r1493424 from trunk:
* r1493424
Remove unnecessary check for branches ancestry from
command line client. All required checks are already performed in
libsvn_client.
Justification:
There is no reason to command line and third-party use different
codepath for ancestory checks. Simple performance fix.
Votes:
+1: ivan, rhuijben, julianfoad
+0: danielsh (note: svn_client__youngest_common_ancestor can be striken;
no callers left)
