Re: Blocker: svn 1.8 assertion failed

[Arrigo . Zanette]

Hi Daniel, 

svn (1.8) --version: 

* ra_svn : Module for accessing a repository using the svn network 
protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using 
serf.
  - handles 'http' scheme
  - handles 'https' scheme

svn (1.7) --version:

* ra_neon : Module for accessing a repository via WebDAV protocol using 
Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network 
protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using 
serf.
  - handles 'http' scheme
  - handles 'https' scheme




From:
Daniel Shahaf 
To:
arrigo.zane...@exorint.it, users@subversion.apache.org, 
Date:
20/06/2013 20:41
Subject:
Re: Blocker: svn 1.8 assertion failed



Stefan Sperling wrote on Thu, Jun 20, 2013 at 16:22:23 +0200:
> On Thu, Jun 20, 2013 at 03:29:00PM +0200, arrigo.zane...@exorint.it 
wrote:
> > The problem is related to SVN itself. Tried also wandisco svn 
> > distribution: same error.
> 
> Thanks. In this case this is probably a problem with the new default
> HTTP client access layer which uses serf.
> See 
http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
> 
> Can you please try the following:
> 
>  - Check out from the same repository URL using a 1.7 client
>with the following option to enable serf in 1.7:
>  svn checkout --config-option 'servers:global:http-library=serf'
> 

Does 'svn --version' say "serf" anywhere?  Otherwise this would use neon.

Re: Blocker: svn 1.8 assertion failed

[Arrigo . Zanette]

Hi Philip,
are you saying that chunked trasfer encoding support is required for svn 
1.8 to work? Is there any way to workaround the requirement client-side?

Thanks,
Arrigo



From:
Philip Martin 
To:
arrigo.zane...@exorint.it, 
Cc:
Stefan Sperling , users@subversion.apache.org
Date:
20/06/2013 20:00
Subject:
Re: Blocker: svn 1.8 assertion failed



arrigo.zane...@exorint.it writes:

> As to your second request, my provider supports only HTTP. Btw, you can 
> try by your own:
>
> svn checkout http://testzanza.unfuddle.com/svn/testzanza_test/

That's another instance of nginx on the server not supporting chunked
transfer encoding:

HTTP/1.1 411 Length Required
Server: nginx/1.2.4
Date: Thu, 20 Jun 2013 17:57:15 GMT
Content-Type: text/html
Content-Length: 180
Connection: close

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com

Re: Subversion Exception! line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM)

[Thomas Harold]

On 6/20/2013 11:55 PM, Sandeepan Kundu wrote:


Tried going back to 1.7, but it is telling project is in higher version :((

how to use now, my development is getting affected!!!


I suggest renaming your old (upgraded to 1.8) working copy out of the 
way, doing a fresh checkout using 1.7 into a fresh working copy folder, 
then copying over changed files from the upgraded 1.8 working copy which 
isn't working.


Naturally, making a backup of the borked working copy is strongly 
suggested if you had uncommitted changes.

Subversion Exception! line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM)

[Sandeepan Kundu]

the following error received:


---
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.0\ext\subversion\subversion\libsvn_client\ra.c'
 line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM)
---
OK
---


was using tortoise svn 1.7
Installed Visual SVN client for dotnet
Visual SVN installation advised for 1.8 upgrate.
Downloaded and installed the same.
Henceforth not able to perform SVN operation

No Commit, No Update,, nothing

Tried going back to 1.7, but it is telling project is in higher version :((

how to use now, my development is getting affected!!!

svnmucc installation bug in Subversion 1.8.0

[Nico Kadel-Garcia]

I'm trying to build up a subversion-1.8.0 SRPM toolkit, and have
noticed a little "svnucc" deployment bug.

Specifically, the Makefile winds up saying this:

# Compatibility symlink.
# This runs after the target of the same name in build-outputs.mk.
INSTALL_EXTRA_TOOLS=\
  $(MKDIR) $(DESTDIR)$(bindir); \
  test -n "$$SVN_SVNMUCC_IS_SVNSYITF" && \
  ln -sf svnmucc$(EXEEXT) $(DESTDIR)$(bindir)/svnsyitf$(EXEEXT); \
  if test "$(DESTDIR)$(bindir)" != "$(DESTDIR)$(toolsdir)"; then \
ln -sf $(DESTDIR)$(bindir)/svnmucc$(EXEEXT)
$(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \
  fi


Unfortunately, when building RPM's "DESTDIR" is the location of the
RPM "BUILDROOT" location, not the atual deployment location. So it
needs to be:

ln -sf $(bindir)/svnmucc$(EXEEXT) $(DESTDIR)$(toolsdir)/svnmucc$(EXEEXT); \

So can I safely assume that I just need to patch that for RPM building?

Re: Advice for changing filename case in SVN on case insensitive system

[Geoff Hoffman]

Yes, that helps, Dave, thanks.

But,

deleting the file from Subversion, then adding the copy with the correct
case.

Question: Doesn't that blow away revision history? If I didn't care about
revision history I would just start over with a fresh repo.

I also thought about doing full URL svn mv's but seemed like that could
take a very long time to do...





Geoff Hoffman
Solutions Architect & LAMP Engineer
phone +1 623.399.4918
mobile +1 480.231.8323
web CardinalPath.com 



On Thu, Jun 20, 2013 at 3:45 PM, Dave Huang  wrote:

> On 6/20/2013 5:34 PM, Geoff Hoffman wrote:
>
>> We have a bunch of Kohana 3.2 projects in revision control, all with
>> lower case filenames.
>>
>> We're upgrading to Kohana 3.3; one of the main changes to Kohana 3.3 is
>> implementing PSR-0 filename conventions, which require the class
>> Model_Myclass to be found in Model/Myclass.php ... in our current repo it's
>> in model/myclass.php (all lower case).
>>
>> I thought I could just svn rename, however I'm confused by the output I'm
>> seeing:
>>
>> svn rename myclass.php Myclass.php
>> svn: E155007: Path '/Full/Path/To/Myclass.php' is not a directory
>>
>
> Perhaps 
> http://subversion.apache.org/**faq.html#case-changemight
>  be helpful.
>
> (Interesting/surprising that SVN 1.7 only fixed svn rename on Windows, but
> not on other OSes with case-insensitive filesystems like MacOS X)
>

-- 


Connect with us on twitter , 
google+
, facebook , or 
linkedin
.

Catch our next training in San Diego Jun 17 - 
21
, Tampa Jun 24 
-28
, Austin, Jul 8 - 
12
, San Francisco Jul 15 - 
19
 or See 
All
.

This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: Advice for changing filename case in SVN on case insensitive system

[Dave Huang]

On 6/20/2013 5:34 PM, Geoff Hoffman wrote:
We have a bunch of Kohana 3.2 projects in revision control, all with 
lower case filenames.


We're upgrading to Kohana 3.3; one of the main changes to Kohana 3.3 
is implementing PSR-0 filename conventions, which require the class 
Model_Myclass to be found in Model/Myclass.php ... in our current repo 
it's in model/myclass.php (all lower case).


I thought I could just svn rename, however I'm confused by the output 
I'm seeing:


svn rename myclass.php Myclass.php
svn: E155007: Path '/Full/Path/To/Myclass.php' is not a directory


Perhaps http://subversion.apache.org/faq.html#case-change might be helpful.

(Interesting/surprising that SVN 1.7 only fixed svn rename on Windows, 
but not on other OSes with case-insensitive filesystems like MacOS X)

Advice for changing filename case in SVN on case insensitive system

[Geoff Hoffman]

We have a bunch of Kohana 3.2 projects in revision control, all with lower
case filenames.

We're upgrading to Kohana 3.3; one of the main changes to Kohana 3.3 is
implementing PSR-0 filename conventions, which require the class
Model_Myclass to be found in Model/Myclass.php ... in our current repo it's
in model/myclass.php (all lower case).

I thought I could just svn rename, however I'm confused by the output I'm
seeing:

svn rename myclass.php Myclass.php
svn: E155007: Path '/Full/Path/To/Myclass.php' is not a directory

Making things more confusing, we're on Macs without the extended case
sensitive filename option in OS X, and we have mixed/outdated SVN versions
across our organization: our server is running 1.6.6 and workstations a
hodgepodge of 1.6.19 - 1.7.7

I need some advice on how to deal with all of this. I thought about
installing VirtualBox and using Linux command line to do everything, but
that seems like a bit overkill.

Thanks in advance!

Geoff

-- 


Connect with us on twitter , 
google+
, facebook , or 
linkedin
.

Catch our next training in San Diego Jun 17 - 
21
, Tampa Jun 24 
-28
, Austin, Jul 8 - 
12
, San Francisco Jul 15 - 
19
 or See 
All
.

This email, including any attachments, is for the sole use of the intended 
recipient and may contain confidential information. If you are not the 
intended recipient, please immediately notify us by reply email or by 
telephone, delete this email and destroy any copies. Thank you.

Re: Regarding the Voilation exception while creating the workspace

[Johan Corveleyn]

That's a known issue that was only present in 1.7.7 on Windows (crash
with --username option in combination with cached credentials on
Windows). You should upgrade your svn client to at least 1.7.8.

--
Johan

On Thu, Jun 20, 2013 at 7:48 PM, Amar Kumar Banda  wrote:
> Hi,
>
> Please could you go through the below files and give the solution, am unable
> to create the workspace for nwms.
>
> --
>
> Thank You!
>
> Best Regards,
>
> AMARKUMAR BANDA

Re: Regarding the Voilation exception while creating the workspace

[Stefan Sperling]

On Thu, Jun 20, 2013 at 11:18:31PM +0530, Amar Kumar Banda wrote:
> Hi,
> 
> Please could you go through the below files and give the solution, am
> unable to create the workspace for nwms.

Looks like a known bug in 1.7.7, which was fixed in 1.7.8 (see below).
Please upgrade to 1.7.10 or 1.8.0 to resolve this issue.

(from https://svn.apache.org/repos/asf/subversion/branches/1.7.x/CHANGES):
Version 1.7.8
(17 Dec 2012, from /branches/1.7.x)
http://svn.apache.org/repos/asf/subversion/tags/1.7.8
 User-visible changes
 [...]
* fix crash with --username option on Windows (r1396285)

Re: Blocker: svn 1.8 assertion failed

[Daniel Shahaf]

Stefan Sperling wrote on Thu, Jun 20, 2013 at 16:22:23 +0200:
> On Thu, Jun 20, 2013 at 03:29:00PM +0200, arrigo.zane...@exorint.it wrote:
> > The problem is related to SVN itself. Tried also wandisco svn 
> > distribution: same error.
> 
> Thanks. In this case this is probably a problem with the new default
> HTTP client access layer which uses serf.
> See http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
> 
> Can you please try the following:
> 
>  - Check out from the same repository URL using a 1.7 client
>with the following option to enable serf in 1.7:
>  svn checkout --config-option 'servers:global:http-library=serf'
> 

Does 'svn --version' say "serf" anywhere?  Otherwise this would use neon.

Re: Possible Install bug

[Andy Levy]

On Thu, Jun 20, 2013 at 1:50 PM, Mike Flum  wrote:
> I have just tried to install 1.8 on a Windows XP SP3 and received the
> following error (see attachment picture)

Is this from TortoiseSVN? If so, you ought to be posting there.

TortoiseSVN 1.8 requires a newer Windows Installer. See
http://svn.haxx.se/tsvnusers/archive-2013-06/0104.shtml . You need to
acquire & install Windows Installer 4.5.

Possible Install bug

[Mike Flum]

I have just tried to install 1.8 on a Windows XP SP3 and received the
following error (see attachment picture)

Michael
mfl...@gmail.com
<>

Re: Blocker: svn 1.8 assertion failed

[Philip Martin]

arrigo.zane...@exorint.it writes:

> As to your second request, my provider supports only HTTP. Btw, you can 
> try by your own:
>
> svn checkout http://testzanza.unfuddle.com/svn/testzanza_test/

That's another instance of nginx on the server not supporting chunked
transfer encoding:

HTTP/1.1 411 Length Required
Server: nginx/1.2.4
Date: Thu, 20 Jun 2013 17:57:15 GMT
Content-Type: text/html
Content-Length: 180
Connection: close

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com

Re: Subversion Failed - Not finding solution

[Philip Martin]

"Bert Huijben"  writes:

> I can reproduce this problem with 1.8.0 / trunk
> svn co http://svn2.xp-dev.com/svn/1541UltimateII/trunk tmp
>
> Looking with the debugger I see that serf ignores a HTTP 411 - Length
> Required error and just returns the default (invalid) revision as SUCCESS
> value.
>
> My educated guess would be that this server runs behind some proxy server
> that doesn't support Chunked transfers.

Yes, it appears to be nginx:

OPTIONS /svn/1541UltimateII/trunk HTTP/1.1
Host: svn2.xp-dev.com
User-Agent: SVN/1.9.0-dev (x86_64-unknown-linux-gnu) serf/1.2.1
Content-Type: text/xml
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked

83

0

HTTP/1.1 411 Length Required
Server: nginx/1.1.19
Date: Thu, 20 Jun 2013 16:37:06 GMT
Content-Type: text/html
Content-Length: 181
Connection: close


411 Length Required

411 Length Required
nginx/1.1.19



-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com

Re: Blocker: svn 1.8 assertion failed

[Arrigo . Zanette]

Hi Stefan, using svn 1.7 + serf to connect to repository I get another 
error:

svn: E175009: XML parsing failed: (411 Length Required)

As to your second request, my provider supports only HTTP. Btw, you can 
try by your own:

svn checkout http://testzanza.unfuddle.com/svn/testzanza_test/

user: test
pass: test

Thanks,
Arrigo



From:
Stefan Sperling 
To:
arrigo.zane...@exorint.it, 
Cc:
users@subversion.apache.org
Date:
20/06/2013 16:22
Subject:
Re: Blocker: svn 1.8 assertion failed



On Thu, Jun 20, 2013 at 03:29:00PM +0200, arrigo.zane...@exorint.it wrote:
> The problem is related to SVN itself. Tried also wandisco svn 
> distribution: same error.

Thanks. In this case this is probably a problem with the new default
HTTP client access layer which uses serf.
See http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted

Can you please try the following:

 - Check out from the same repository URL using a 1.7 client
   with the following option to enable serf in 1.7:
 svn checkout --config-option 'servers:global:http-library=serf'

Whether or not this checkout fails in the same way as in 1.8 would
be an interesting data point.

 - Check out from the same repository using a 1.8 client and a
   non-HTTP URL,svn :// or svn+ssh://

This is to confirm that the problem is limited to clients using serf.

Thanks!

Re: Subversion Failed - Not finding solution

[Stefan Sperling]

On Thu, Jun 20, 2013 at 09:15:55AM -0700, Fredric QJ Blåholtz wrote:
> I changed to the latest TortoiseSVN 1.7, works fine.
> 
> It would have been nice if the e-mails this group generates had a link to 
> this page - so you don't have to google it to find your way back.

The google group you seem to be using is managed by google and not
by the Subversion project. We use a mailing list, see
http://subversion.apache.org/mailing-lists.html

Google seems to somehow provide an interface to this list which
some people then use to post to our list. But it's not the official
way of contacting this list.

Re: Subversion Failed - Not finding solution

[Fredric QJ Blåholtz]

I changed to the latest TortoiseSVN 1.7, works fine.

It would have been nice if the e-mails this group generates had a link to 
this page - so you don't have to google it to find your way back.


I don't really care anymore, I just wanted to tell someone that it didn't 
work, 1.7 works fine for me.

RE: Subversion Failed - Not finding solution

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@elego.de]
> Sent: donderdag 20 juni 2013 13:18
> To: Fredric QJ Blåholtz
> Cc: users@subversion.apache.org; guenther.scha...@rs-software.at;
> Verónica Santos
> Subject: Re: Subversion Failed - Not finding solution
> 
> On Thu, Jun 20, 2013 at 02:45:11AM -0700, Fredric QJ Blåholtz wrote:
> > I have the same problem.
> >
> > First the download link was wrong, they had forgotten the .html on the
> > webadress and now I get the same exact error message here - have
> someone
> > forgotten to change something in that file "ra.c"?
> > I'm trying a previous version, perhaps it was compiled when sober...
;-)
> >
> > I was installing on Windows XP Home, I've had TortoiseSVN installed
before
> > I had to swap harddrives and reinstall everything from scratch, an
earlier
> > version ofcourse, and it has always worked perfectly for several years.
> > That row "
> > 'D:\Development\SVN\Releases\TortoiseSVN-
> 1.8.0\ext\subversion\subversion\libsvn_client\ra.c'"
> > Where does that come from, is it the place where I'm fetching, some
> adress
> > that the compiler-person has when making the current release? It's not a
> > fileadress on my computer at least.
> >
> > I was trying to check out: "http://svn2.xp-
> dev.com/svn/1541UltimateII/trunk"
> >
> > But it seems someone compiling this version messed up, right?
> >
> 
> Has anybody ruled out whether this problem is specific to TortoiseSVN?
> 
> Can you check out from the repository with the 'svn.exe' binary which
> can be optionally installed along with TortoiseSVN?
> (http://gaurangpatel.net/posted_images/SVN-checkout-using-BATCH-and-
> Powershell_A0FD/SVNInstall.png)

I can reproduce this problem with 1.8.0 / trunk
svn co http://svn2.xp-dev.com/svn/1541UltimateII/trunk tmp

Looking with the debugger I see that serf ignores a HTTP 411 - Length
Required error and just returns the default (invalid) revision as SUCCESS
value.

My educated guess would be that this server runs behind some proxy server
that doesn't support Chunked transfers.

Bert

Re: Automatic windows authentication using serf/svn 1.8

[Gert Kello]

>> If I enable the ‘SSPIPackage Negotiate’ line (which I just added) then my
>> Subversion 1.8 clients appear to authenticate correctly, but my neon based
>> 1.7 clients fail with an even worse error that can’t be resolved by just
>> typing the password.
>>
>
> Seems like for me the SSPIPackage Negotiate is not working for 1.8
> client. Did not try with 1.7 client.

A status update:
I can successfully authenticate against the server when I use
"correct" name of server. i.e. I there are several name forms of
server I can use:
https:/svnserver/svn
https://svnserver.domain1.com/svn
https://svnserver.domain2.com/svn
https://10.xx.yy.zz/svn

When having SSPIPackage Negotiate, first two of name forms
(https:/svnserver/svn and https://svnserver.domain1.com/svn) do not
work, but last two ones work (https://svnserver.domain2.com/svn and
ip-based access). So there's something wrong with our network setup.
Server machine is joined to domain2.com, my machine and my user are in
domain1.com.

Svn 1.7 client works if serf http library is used, i.e.
svn list https://svnserver.domain2.com/svn --config-option
servers:global:http-library=serf

So I have almost working solution, after network problem is fixed. I
just have to persuade every team member either to upgrade or to change
their servers configuration file.

Gert

Re: Blocker: svn 1.8 assertion failed

[Stefan Sperling]

On Thu, Jun 20, 2013 at 03:29:00PM +0200, arrigo.zane...@exorint.it wrote:
> The problem is related to SVN itself. Tried also wandisco svn 
> distribution: same error.

Thanks. In this case this is probably a problem with the new default
HTTP client access layer which uses serf.
See http://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted

Can you please try the following:

 - Check out from the same repository URL using a 1.7 client
   with the following option to enable serf in 1.7:
 svn checkout --config-option 'servers:global:http-library=serf'

Whether or not this checkout fails in the same way as in 1.8 would
be an interesting data point.

 - Check out from the same repository using a 1.8 client and a
   non-HTTP URL,svn :// or svn+ssh://

This is to confirm that the problem is limited to clients using serf.

Thanks!

Re: Blocker: svn 1.8 assertion failed

[Arrigo . Zanette]

The problem is related to SVN itself. Tried also wandisco svn 
distribution: same error.





From:
Stefan Sperling 
To:
arrigo.zane...@exorint.it, 
Cc:
users@subversion.apache.org
Date:
20/06/2013 13:16
Subject:
Re: Blocker: svn 1.8 assertion failed



On Thu, Jun 20, 2013 at 12:07:59PM +0200, arrigo.zane...@exorint.it wrote:
> Hi,
> 
> I've just installed a win64 subversion build, revision 1.8.0 r1490375. 
> Trying to checkout  a repository from our unfuddle server (I guess 
server 
> version <=1.7):
> 
> svn: E235000: In file '..\..\..\subversion\libsvn_client\ra.c' line 647: 

> assertion failed (peg_revnum != SVN_INVALID_REVNUM)
> 
> All other svn operations fail as well.

This problem has been reported to this mailing list before today:
http://svn.haxx.se/users/archive-2013-06/0171.shtml

Have you ruled out whether this problem is specific to TortoiseSVN?
Can you check out the repository with the 'svn.exe' binary which
can be optionally installed along with TortoiseSVN (
http://gaurangpatel.net/posted_images/SVN-checkout-using-BATCH-and-Powershell_A0FD/SVNInstall.png
)

Aw: Re: Externals and sparse checkouts on 1.8

[Matthias Binninger]

> Gesendet: Donnerstag, 20. Juni 2013 um 11:05 Uhr
> Von: "Stefan Sperling" 
>
> On Thu, Jun 20, 2013 at 10:50:51AM +0200, Matthias Binninger wrote:
> > Hi,
> >  
> > updated three computers to (Tortoise)SVN 1.8 yesterday and one problem 
> > occurred on each of them:
> >  
> > After the initial wc upgrade, attempts to update fail while updating 
> > externals in folders that are not even checked out (sparse checkout).
> >
> > C:\Projects\SomeFolder>svn up
> > Updating '.':
> > Removed external 'SubFolder\NotCheckOut\Externals\file.txt'
> > svn: E720003: Can't remove directory 
> > 'D:\Projects\SomeFolder\SubFolder\NotCheckOut\Externals': Das System kann 
> > den angegebenen Pfad nicht finden.
> >
> > "Das System kann den angegebenen Pfad nicht finden." = "The system can not 
> > find the given path."
> > Which is correct, the path does not exist, as it is not checked out, as is 
> > the folder with the externals property on it.
> >
> > The update is aborted after the error.
> > The error is only raised once per external, the subsequent update fails on 
> > the next external.
> > The current solution is to do multiple updates in a loop until all errors 
> > are gone.
> >
> > Matthias
>
> Hi Matthias,
>
> thanks for you report. This looks like a bug to me. Can you please
> file an issue in our issue tracker? Thanks!
> http://subversion.apache.org/reporting-issues.html
>

Bug filed:
http://subversion.tigris.org/issues/show_bug.cgi?id=4381

Matthias

Re: Subversion Failed - Not finding solution

[Stefan Sperling]

On Thu, Jun 20, 2013 at 02:45:11AM -0700, Fredric QJ Blåholtz wrote:
> I have the same problem.
> 
> First the download link was wrong, they had forgotten the .html on the 
> webadress and now I get the same exact error message here - have someone 
> forgotten to change something in that file "ra.c"?
> I'm trying a previous version, perhaps it was compiled when sober...  ;-)
> 
> I was installing on Windows XP Home, I've had TortoiseSVN installed before 
> I had to swap harddrives and reinstall everything from scratch, an earlier 
> version ofcourse, and it has always worked perfectly for several years.
> That row " 
> 'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'"
>  
> Where does that come from, is it the place where I'm fetching, some adress 
> that the compiler-person has when making the current release? It's not a 
> fileadress on my computer at least.
> 
> I was trying to check out: "http://svn2.xp-dev.com/svn/1541UltimateII/trunk";
> 
> But it seems someone compiling this version messed up, right?
> 

Has anybody ruled out whether this problem is specific to TortoiseSVN?

Can you check out from the repository with the 'svn.exe' binary which
can be optionally installed along with TortoiseSVN? 
(http://gaurangpatel.net/posted_images/SVN-checkout-using-BATCH-and-Powershell_A0FD/SVNInstall.png)

Re: Blocker: svn 1.8 assertion failed

[Stefan Sperling]

On Thu, Jun 20, 2013 at 12:07:59PM +0200, arrigo.zane...@exorint.it wrote:
> Hi,
> 
> I've just installed a win64 subversion build, revision 1.8.0 r1490375. 
> Trying to checkout  a repository from our unfuddle server (I guess server 
> version <=1.7):
> 
> svn: E235000: In file '..\..\..\subversion\libsvn_client\ra.c' line 647: 
> assertion failed (peg_revnum != SVN_INVALID_REVNUM)
> 
> All other svn operations fail as well.

This problem has been reported to this mailing list before today:
http://svn.haxx.se/users/archive-2013-06/0171.shtml

Have you ruled out whether this problem is specific to TortoiseSVN?
Can you check out the repository with the 'svn.exe' binary which
can be optionally installed along with TortoiseSVN 
(http://gaurangpatel.net/posted_images/SVN-checkout-using-BATCH-and-Powershell_A0FD/SVNInstall.png)

Blocker: svn 1.8 assertion failed

[Arrigo . Zanette]

Hi,

I've just installed a win64 subversion build, revision 1.8.0 r1490375. 
Trying to checkout  a repository from our unfuddle server (I guess server 
version <=1.7):

svn: E235000: In file '..\..\..\subversion\libsvn_client\ra.c' line 647: 
assertion failed (peg_revnum != SVN_INVALID_REVNUM)

All other svn operations fail as well.

Thanks,

Arrigo

Re: Problem, svn upgrade & externals & svn status (1.6 --> 1.7)

[Johan Holmberg]

On Wed, Jun 19, 2013 at 1:51 PM, Bert Huijben  wrote:

> Subversion 1.7.7 and later automatically upgrade all working copies
> referenced from svn:externals properties too.
>
> ** **
>
> For older clients can use ‘svn upgrade’ on the externals itself.
>
> Bert
>
> **
>


I have upgraded *both* the top-project and the one referenced by the
svn:externals (manually with 1.7.5). The problem I tried to describe was
that "svn status" no longer followed the "svn:externals" into the
sub-directory. If I use  "svn status proj1/proj2-subdir", my svn will
accurately show the status of the "proj1/proj2-subdir" directory, but "svn
status proj1" never even looks at the "proj1/proj2-subdir" directory.

/Johan Holmberg



>  **
>
> *From:* Johan Holmberg [mailto:johan...@gmail.com]
> *Sent:* woensdag 19 juni 2013 13:12
> *To:* users@subversion.apache.org
> *Subject:* Problem, svn upgrade & externals & svn status (1.6 --> 1.7)
>
> ** **
>
> Hi!
>
> I have just started using the Subversion client 1.7.5 (I used 1.6.17
> previously). To be able to use my old working copies I had to do a "svn
> upgrade". But after the upgrade, the svn:externals are no longer fully
> recognized. The "svn status" command no longer "recurses into sub-projects"
> the way it used to. The difference can be seen by:
>
> -
> $ svn status proj1
> X   proj1/proj2-subdir
> $
> $ svn status proj1-new
> X   proj1-new/proj2-subdir
>
> Performing status on external item at 'proj1-new/proj2-subdir':
> -
>
> "proj1" is the old working copy with "svn upgrade" applied. "proj1-new" is
> a fresh checkout of the project with the new client version. I have looked
> around in the ".svn" directory of the projects and found a difference that
> perhaps explains the difference i behaviour:
>
> -
> $ sqlite3 proj1/.svn/wc.db 'select * from EXTERNALS order by
> local_relpath'
> 1|proj2-subdir||1|normal|unknown
> $
> $ sqlite3 proj1-new/.svn/wc.db 'select * from EXTERNALS order by
> local_relpath'
> 1|proj2-subdir||1|normal|dir||proj2||
> -
>
> Note that the upgraded working copy has the externals entry marked
> "unknown".
>
> Is what I describe here a known problem of the "svn upgrade" command?
>
> I also wonder if there is some way to get my existing working copies fully
> functional again without doing a  new checkout.
>
> /Johan Holmberg
>
>
>
>
> 
>

Re: Subversion Failed - Not finding solution

[Fredric QJ Blåholtz]

I have the same problem.

First the download link was wrong, they had forgotten the .html on the 
webadress and now I get the same exact error message here - have someone 
forgotten to change something in that file "ra.c"?
I'm trying a previous version, perhaps it was compiled when sober...  ;-)

I was installing on Windows XP Home, I've had TortoiseSVN installed before 
I had to swap harddrives and reinstall everything from scratch, an earlier 
version ofcourse, and it has always worked perfectly for several years.
That row " 
'D:\Development\SVN\Releases\TortoiseSVN-1.8.0\ext\subversion\subversion\libsvn_client\ra.c'"
 
Where does that come from, is it the place where I'm fetching, some adress 
that the compiler-person has when making the current release? It's not a 
fileadress on my computer at least.

I was trying to check out: "http://svn2.xp-dev.com/svn/1541UltimateII/trunk";

But it seems someone compiling this version messed up, right?

Re: crash: svnadmin upgrade

[Stefan Sperling]

On Thu, Jun 20, 2013 at 11:52:53AM +0400, Alexander Leschinsky wrote:
> 

Thanks for your crash report. It looks like this known issue:
http://svn.haxx.se/dev/archive-2013-06/0342.shtml
This will be fixed in 1.8.1.

Re: Externals and sparse checkouts on 1.8

[Stefan Sperling]

On Thu, Jun 20, 2013 at 10:50:51AM +0200, Matthias Binninger wrote:
> Hi,
>  
> updated three computers to (Tortoise)SVN 1.8 yesterday and one problem 
> occurred on each of them:
>  
> After the initial wc upgrade, attempts to update fail while updating 
> externals in folders that are not even checked out (sparse checkout).
> 
> C:\Projects\SomeFolder>svn up
> Updating '.':
> Removed external 'SubFolder\NotCheckOut\Externals\file.txt'
> svn: E720003: Can't remove directory 
> 'D:\Projects\SomeFolder\SubFolder\NotCheckOut\Externals': Das System kann den 
> angegebenen Pfad nicht finden.
> 
> "Das System kann den angegebenen Pfad nicht finden." = "The system can not 
> find the given path."
> Which is correct, the path does not exist, as it is not checked out, as is 
> the folder with the externals property on it.
> 
> The update is aborted after the error.
> The error is only raised once per external, the subsequent update fails on 
> the next external.
> The current solution is to do multiple updates in a loop until all errors are 
> gone.
> 
> Matthias

Hi Matthias,

thanks for you report. This looks like a bug to me. Can you please
file an issue in our issue tracker? Thanks!
http://subversion.apache.org/reporting-issues.html

Externals and sparse checkouts on 1.8

[Matthias Binninger]

Hi,
 
updated three computers to (Tortoise)SVN 1.8 yesterday and one problem occurred 
on each of them:
 
After the initial wc upgrade, attempts to update fail while updating externals 
in folders that are not even checked out (sparse checkout).

C:\Projects\SomeFolder>svn up
Updating '.':
Removed external 'SubFolder\NotCheckOut\Externals\file.txt'
svn: E720003: Can't remove directory 
'D:\Projects\SomeFolder\SubFolder\NotCheckOut\Externals': Das System kann den 
angegebenen Pfad nicht finden.

"Das System kann den angegebenen Pfad nicht finden." = "The system can not find 
the given path."
Which is correct, the path does not exist, as it is not checked out, as is the 
folder with the externals property on it.

The update is aborted after the error.
The error is only raised once per external, the subsequent update fails on the 
next external.
The current solution is to do multiple updates in a loop until all errors are 
gone.

Matthias

crash: svnadmin upgrade

[Alexander Leschinsky]

crash.7z
Description: Binary data

Re: Subversion Failed - Not finding solution

[Günther Schabus]

I am experiencing a similar problem, right after updating to Version 
1.8.0.24401, 64 bit on a Windows 8.0 64 bit machine.

When trying to connect to an existing repository i am getting
the following error.

In file
 'D:\Development\SVN\Releases\TortoiseSVN-
1.8.0\ext\subversion\subversion\libsvn_client\ra.c'
 line 647: assertion failed (peg_revnum != SVN_INVALID_REVNUM)
---
OK   
---

Any ideas?

Thank you in advance for your support, Günther