Subversion Error During Update
While attempting update the trunk of https://github.com/EllisLab/CodeIgniter I received the following error. --- Subversion Exception! --- Subversion encountered a serious problem. Please take the time to report this on the Subversion mailing list with as much information as possible about what you were trying to do. But please first search the mailing list archives for the error message to avoid reporting the same problem repeatedly. You can find the mailing list archives at http://subversion.apache.org/mailing-lists.html Subversion reported the following (you can copy the content of this dialog to the clipboard using Ctrl-C): In file 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\update_editor.c' line 1550: assertion failed (action == svn_wc_conflict_action_delete) --- OK --- This email and any attachments are only for use by the intended recipient(s) and may contain legally privileged, confidential, proprietary or otherwise private information. Any unauthorized use, reproduction, dissemination, distribution or other disclosure of the contents of this e-mail or its attachments is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete the original. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature unless a specific statement to the contrary is included in this message.
JavaHL logMessages only one callback
I am trying to find change history and thought that using logMessage will provide the information. I am using a call as descibre below: pegRevision = Revision.HEAD, ranges = [RevisionRange(Revision.HEAD, Revision.START)] stopOnCopy = false discoverPath = true includeMergedRevisions = true props = [REV_LOG, REV_DATE, REV_AUTHOR] limit = -1 May callback function is only called once with the last commit information. I tried: stopOnCopy true and false limt -1, 0, 1000 includeMergedRevisions = true and false ranges with RevisionRange(Revision.START, Revision.HEAD) I never receive more than one callback. Then I tried something different: determine maxRev after previous list operation. ranges = RevisionRange(maxRev + "-0") and now I get all the versions. It seems as if the RevisionRange(Revision.HEAD, Revision.START) is not being treated as expected. Am I misunderstanding the RevisionRange class? Corneil du Plessis
Re: JavaHL logMessages only one callback
On 19.08.2015 10:48, corneil.duples...@gmail.com wrote: > I am trying to find change history and thought that using logMessage will > provide the information. > > I am using a call as descibre below: > > pegRevision = Revision.HEAD, > ranges = [RevisionRange(Revision.HEAD, Revision.START)] > stopOnCopy = false > discoverPath = true > includeMergedRevisions = true > props = [REV_LOG, REV_DATE, REV_AUTHOR] > limit = -1 > > May callback function is only called once with the last commit information. > > I tried: > stopOnCopy true and false > limt -1, 0, 1000 > includeMergedRevisions = true and false > ranges with RevisionRange(Revision.START, Revision.HEAD) > > I never receive more than one callback. I really wish you'd shown actual code, not some description of code ... it's easier to understand. > Then I tried something different: > > determine maxRev after previous list operation. > > ranges = RevisionRange(maxRev + "-0") > > and now I get all the versions. > > It seems as if the RevisionRange(Revision.HEAD, Revision.START) is not > being treated as expected. Actually, it is, but Revision.START is really badly documented ... it's the same as Revision.UNSPECIFIED and it's only useful in some limited contexts. You could try using RevisionRange(Revision.HEAD, Revision.getInstance(0)) -- Brane
Re: Subversion Error During Update
Hello, James Trainor wrote: > While attempting update the trunk of https://github.com/EllisLab/CodeIgniter > I received the following error. > > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.8.8\ext\subversion\subversion\libsvn_wc\update_editor.c' > line 1550: assertion failed (action == svn_wc_conflict_action_delete) Update to the lastest (compatible) TortoiseSVN 1.8.12 (linking Subversion 1.8.14): https://sourceforge.net/projects/tortoisesvn/files/1.8.12/Application/ and try again. Andreas
Re: JavaHL logMessages only one callback
Thanks, the following worked and only difference was the order of the callbacks. RevisionRange(Revision.getInstance(0), Revision.HEAD) RevisionRange(Revision.HEAD, Revision.getInstance(0)) Corneil du Plessis about.me/corneil On 19 August 2015 at 11:04, Branko Čibej wrote: > > On 19.08.2015 10:48, corneil.duples...@gmail.com wrote: > > I am trying to find change history and thought that using logMessage will > > provide the information. > > > > I am using a call as descibre below: > > > > pegRevision = Revision.HEAD, > > ranges = [RevisionRange(Revision.HEAD, Revision.START)] > > stopOnCopy = false > > discoverPath = true > > includeMergedRevisions = true > > props = [REV_LOG, REV_DATE, REV_AUTHOR] > > limit = -1 > > > > May callback function is only called once with the last commit information. > > > > I tried: > > stopOnCopy true and false > > limt -1, 0, 1000 > > includeMergedRevisions = true and false > > ranges with RevisionRange(Revision.START, Revision.HEAD) > > > > I never receive more than one callback. > > I really wish you'd shown actual code, not some description of code ... > it's easier to understand. > > > > Then I tried something different: > > > > determine maxRev after previous list operation. > > > > ranges = RevisionRange(maxRev + "-0") > > > > and now I get all the versions. > > > > It seems as if the RevisionRange(Revision.HEAD, Revision.START) is not > > being treated as expected. > > > Actually, it is, but Revision.START is really badly documented ... it's > the same as Revision.UNSPECIFIED and it's only useful in some limited > contexts. > > You could try using RevisionRange(Revision.HEAD, Revision.getInstance(0)) > > -- Brane
Re: JavaHL logMessages only one callback
On Wed, Aug 19, 2015 at 11:18 AM, corneil.duples...@gmail.com < corneil.duples...@gmail.com> wrote: > Thanks, the following worked and only difference was the order of the > callbacks. > > RevisionRange(Revision.getInstance(0), Revision.HEAD) > RevisionRange(Revision.HEAD, Revision.getInstance(0)) > > You want to do the latter if possible. The server can process -r HEAD:0 significantly faster than it can process -r 0:HEAD -- Thanks Mark Phippard http://markphip.blogspot.com/
Two-step merge ok, one-step merge conflicts
Hi folks. I faced the following problem. The command svn merge -r 3:4 -r 4:5 ^^/trunk works smoothly while command svn merge -r 3:5 ^^/trunk results in a text conflict. This seems like a buggy behavior (since the two merges are equivalent). I reproduced it in a simple situation when trunk contains only a single file. Here is a list of revisions: r1. Initial directory structure (trunk and branches). r2. Add file trunk/foo. r3. Create branch branches/test from trunk. r4. Set svn:eol-style to native on trunk/foo. r5. Modify text in trunk/foo. After that I checkout branches/test and try to perform the merge (which only sets svn:eol-style on trunk/foo and modifies its content). Then I get the aforementioned conflict. I performed the test with the following Subversion version: svn, version 1.9.0 (r1692801) compiled Aug 3 2015, 21:00:08 on x86-microsoft-windows I attach the script (cmd batch file) which creates local repository and performs all the preparation to demonstrate the problem (please remove the .txt extension to run it). My guess is that svn:eol-style change is the root of the problem. Could please somebody explain the behavior or confirm that this is a bug? @echo off cd %~dp0% if exist test_svn ( echo ERROR: test_svn already exists. Please remove it first exit /b 1 ) echo *** Creating directory test_svn mkdir test_svn cd test_svn echo *** Creating repo svnadmin create repo rem A trick to get normal svn URL with forward slashes set repo_path=file://%~p0%/test_svn/repo set repo_path=%repo_path:\=/% echo *** Repository address is %repo_path% echo *** Creating initial directory structure (trunk and branches) svn co %repo_path% full_repo cd full_repo md trunk md branches svn add trunk branches svn ci -m "initial tree" cd .. echo *** Checking out trunk and creating simple file foo svn co %repo_path%/trunk trunk cd trunk echo Simple file > foo svn add foo svn ci -m "added foo" echo *** Creating branch test svn copy . ^^/branches/test -m "create branch" echo *** Setting svn:eol-style=native on trunk/foo svn propset svn:eol-style native foo svn ci -m "set property" echo *** Modifying trunk/foo echo Modification >> foo svn ci -m "modified foo" echo *** Checking out branches/test cd .. svn co %repo_path%/branches/test cd test echo. echo. echo Now while in test_svn/test directory: echo. echo 1. Try echo^> svn merge -r 3:5 ^^/trunk echoand you get a conflict echo 2. Revert (svn revert -R .) and try echo^> svn merge -r 3:4 -r 4:5 ^^/trunk echoand you do not get any conflicts
RE: Two-step merge ok, one-step merge conflicts
> -Original Message- > From: Timur Khanipov [mailto:khani...@gmail.com] > Sent: Wednesday, August 19, 2015 1:20 PM > To: users@subversion.apache.org > Cc: Иван Коптелов > Subject: Two-step merge ok, one-step merge conflicts > > Hi folks. > > I faced the following problem. The command > svn merge -r 3:4 -r 4:5 ^^/trunk > works smoothly while command > svn merge -r 3:5 ^^/trunk > results in a text conflict. This seems like a buggy behavior (since the two > merges are equivalent). Same behavior in 1.8.10 (r1615264) on windows. However, if you change the svn:eol-style to "CRLF", them "merge -r 3:5" works without a conflict. It looks like "native" with the "merge -r 3:5" causes a conflict because of eol changes to the file in the middle of the merge process? Also note, that with "native" the merge conflict appears to be with the EOLs and not with the text change you made.
Is it safe to redirect from HTTP to HTTPS in case of svn:externals?
Hi, I'm implementing publicly accessible mod_davn_svn in addition to some internally used svnserve. Some of my repos use svn:externals where we used to defined "//internal.example.org/...", my publicly available entry point is "https://external.example.org";. For the public "internal.example.org" is resolved as "external.example.org", so checking out a repo from HTTPS with svn:externals used would result in a request to "https://internal.example.org"; and produce certificate verification failures in the client because of mismatching domain names and such. So I thought of simply changing the svn:externals definition to "http://internal.example.org"; which I can then redirect to "https://external.example.org"; on my public server. In my tests that seemed to work properly and the important part is that the locally created working copy for svn:externals only contained HTTPS-URLs. So am I correct that my approach is safe regarding that no user passwords or such are going unencrypted over the wire if only the first request doesn't contain such passwords and will always only be the redirect? Any other problems which I might overlook currently? Thanks! Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
RE: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?
> -Original Message- > From: Thorsten Schöning [mailto:tschoen...@am-soft.de] > Sent: woensdag 19 augustus 2015 21:50 > To: users@subversion.apache.org > Subject: Is it safe to redirect from HTTP to HTTPS in case of svn:externals? > > Hi, > > I'm implementing publicly accessible mod_davn_svn in addition to some > internally used svnserve. Some of my repos use svn:externals where we > used to defined "//internal.example.org/...", my publicly available > entry point is "https://external.example.org";. For the public > "internal.example.org" is resolved as "external.example.org", so > checking out a repo from HTTPS with svn:externals used would result in > a request to "https://internal.example.org"; and produce certificate > verification failures in the client because of mismatching domain > names and such. > > So I thought of simply changing the svn:externals definition to > "http://internal.example.org"; which I can then redirect to > "https://external.example.org"; on my public server. In my tests that > seemed to work properly and the important part is that the locally > created working copy for svn:externals only contained HTTPS-URLs. > > So am I correct that my approach is safe regarding that no user > passwords or such are going unencrypted over the wire if only the > first request doesn't contain such passwords and will always only be > the redirect? Any other problems which I might overlook currently? The key Subversion uses to store passwords is different between http and https, so a password used for https won't be used for http. There are other options to specify your externals; see 'svn help propset' [[ The URL may be a full URL or a relative URL starting with one of: ../ to the parent directory of the extracted external ^/ to the repository root /to the server root // to the URL scheme ^/../ to a sibling repository beneath the same SVNParentPath location ]] Bert
Re: Is it safe to redirect from HTTP to HTTPS in case of svn:externals?
Guten Tag Bert Huijben, am Mittwoch, 19. August 2015 um 22:06 schrieben Sie: > The key Subversion uses to store passwords is different between > http and https, so a password used for https won't be used for http. It's bit late for me, so: This is good thing in my setup, right? :-) > There are other options to specify your externals; see 'svn help propset' I know, but my example was simplified, my repos are still mainly hosted by different svnserve instances, so that URIs and Ports differ and such. I couldn't find anything better in the newer syntax for svn:externals dealing with what I have currently... Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
