Re: Subversion Exception

[Sidewinder_GER]

Hi,

Am 16.01.2012 16:48, schrieb Dave Huang:
> Actually, the error message specifically states that it should be
reported to the Subversion mailing list--it's an assertion failure in
the SVN library.

Of course you're correct. I should have added that I tested a checkout
with a problematic path on SVN command line client and on TortoiseSVN:

SVN command line client:

 > svn --version
svn, version 1.7.2 (r1207936)
   compiled Jan 13 2012, 14:57:12
[...]

 > svn co http:/server.com/repo/
svn: E020024: Error resolving case of 'http:\server.com\repo\'

Notice that the error message is quite misleading.

Using the same path from a checkout from TortoiseSVN 1.7.4
(linked against svn 1.7.2) yields the reported crash.

So yes, the crash happens in the Subversion library, but it originates
in svn command line client and TortoiseSVN using the subversion library
in a different way. Sorry for the confusion.

-- 
Michael Geisinger

Re: subversion sqlite.c bug

[Philip Martin]

Андрей Нагих  writes:

> I get this error while commiting to local fsfs svn repository.
>
> In file
>  
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.4\ext\subversion\subversion\libsvn_subr\sqlite.c'
>  line 187: assertion failed (stmt_idx < db->nbr_statements)
>
> May be the reason that I sync repository folder with Dropbox (I knew
> it's bad now)

It's probably the db/rep-cache.db file that is corrupt.  Running

   sqlite3 db/rep-cache.db "pragma integrity_check"

may confirm this.  Since it is only a cache you can remove the the
rep-cache.db file and a new empty cache will get created.  That should
recover the repository.  You may want to disable the use of rep-cache.db
(see rep-sharing in in db/fsfs.conf) if some non-sqlite-aware process is
writing to the repository.

-- 
Philip

Re: Internal assertion when updating symlink changes on 64-bit Ubuntu 10.04 LTS

[Philip Martin]

Chad Austin  writes:

> I admit I haven't updated my working copy on this Linux machine in some
> time, but I do know that we had some symlink changes in recent history that
> broke Subversion 1.7.0 on Windows with a similar assertion to the
> following.  Upgrading to Subversion 1.7.2 on Windows fixed the assertion.
>
> However, now that I've gone to update on Linux, I get the following
> assertion:
>
> svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line 1583:
> assertion failed (action == svn_wc_conflict_action_edit || action ==
> svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
>
> Deleting the directories containing the symlinks allows "svn update" to
> complete.
>
> Perhaps the above assertion is the same as
> http://mail-archives.apache.org/mod_mbox/subversion-dev/201201.mbox/%3c20120101235241.gb10...@ted.stsp.name%3E?

Which version of Subversion on Linux?

Can you describe the nature of the symlink change?

-- 
Philip

Re: Exception...line 673: assertion failed (checksum != NULL)

[Balogh Péter]

On 2012.01.14. 5:07, Les Mikesell wrote:

2012/1/13 Balogh Péter:


I've got exactly the same exception from one of our old wc.
I'm not sure what's the reason for cleanup.
The wc was update-ed from 1.6 to 1.7
I did found some .svn directories deeper in the directory tree.
Maybe the update went wrong?
Can I help track this bug down?
I'm already using a fresh checkout so I'm going to have the wc around if you
wish.

Are those subdirectories related to svn external references?  Someone
here reported a similar issue some time after the main part of the wc
should have been upgraded so I was wondering if it doesn't recurse
into the external part until there is a change.


No, there were no external references in the svn repo.

Re: Internal assertion when updating symlink changes on 64-bit Ubuntu 10.04 LTS

[Chad Austin]

On Tue, Jan 17, 2012 at 12:57 AM, Philip Martin
wrote:

> Which version of Subversion on Linux?
>

1.7.2


> Can you describe the nature of the symlink change?


I don't recall exactly the issue, but it all started when someone made a
code checkout with Cygwin and then committed with TortoiseSVN.  Because
Cygwin and native Windows builds of Subversion use different working copy
representations of symlinks, suddenly all of the symlinks in the repository
were broken.  In the process of reverting his changes, older versions of
Subversion stopped being able to update.  Then I removed those symlinks
from the tree entirely, except for one, and now Subversion 1.7.2 on Linux
cannot update.

Thanks,
Chad

Exception at Subversion

[Césare - Reitech TI]

Hello,

 

I was trying to commit some changes today and got this message.

Now everything i try to do the exception appears.

Could you please help me out?

 

Below is the exception message.

 

---

Subversion Exception!

---

Subversion encountered a serious problem.

Please take the time to report this on the Subversion mailing list

(users@subversion.apache.org)

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.7.0\ext\subversion\subversion\lib
svn_wc\wc_db.c'

line 9465: assertion failed (work_presence == svn_wc__db_status_normal ||

work_presence == svn_wc__db_status_not_present || work_presence ==

svn_wc__db_status_base_deleted)

---

OK   

 

 

---

TortoiseSVN

---

Cleanup failed to process the following paths:

C:\C#\rei_erp_csharp

In file

'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\lib
svn_wc\wc_db.c'

line 9465: assertion failed (work_presence == svn_wc__db_status_normal ||

work_presence == svn_wc__db_status_not_present || work_presence ==

svn_wc__db_status_base_deleted)

cannot rollback savepoint - SQL statements in progress, executing statement

'ROLLBACK TO s666'

SQLite busy at transaction rollback; resetting all busy SQLite statements to

allow rollback

---

OK   

 

Thank you in advance.

 


Descrição: Logo

Césare Cibien
  ces...@reitech.com.br

Reitech T.I
Tel.: (48) 3628-1741
  cont...@reitech.com.br -
 www.reitech.com.br

 

 

<>

svn:externals to another svn:externals issue

[Andrew]

Hello all!

I've got an issue with a repo that I manage regarding svn:externals
and have been unable to find any information regarding it (apologies
if the issue has already been brought up and I didn't find it.)

So I've got a pair of projects, we'll call them /tools and /libs.
Under each I'm using ./tags/v1.0 ./tags/v2.0 as well as an
svn:externals of ./tags/latest which points to the most recent tagged
version.  This all works fine.  What I'd like to do and seem to be
unable is to use svn:externals to point from /tools/tags/v2.0/libs to
/libs/tags/latest, as that directory only exists as a property of it's
parent.  I'd like to use this so that I don't have to worry about
updating the libs path for my tools every time I release a new
version.

Does anyone have any ideas on how I might be able to accomplish this
or a more effective way of managing this code?

Thanks!

-- 
Andrew
http://blog.psych0tik.net

Subversion Exception

[Frank Capodieci]

I got an exception on update; Windows 7 Home Premium 64-bit.  I have been
using Tortoise for over a year without problem.  I don't think I was doing
anything unusual today except for having a large number of unversioned
binary files in the folder.

---
Subversion Exception!
---
...

In file
 
'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\update_editor.c'
 line 1583: assertion failed (action == svn_wc_conflict_action_edit ||
action
 == svn_wc_conflict_action_delete || action ==
svn_wc_conflict_action_replace)
---
OK
---

Re: svn:externals to another svn:externals issue

[Stephen Butler]

On Jan 17, 2012, at 17:33 , Andrew wrote:

> Hello all!
> 
> I've got an issue with a repo that I manage regarding svn:externals
> and have been unable to find any information regarding it (apologies
> if the issue has already been brought up and I didn't find it.)
> 
> So I've got a pair of projects, we'll call them /tools and /libs.
> Under each I'm using ./tags/v1.0 ./tags/v2.0 as well as an
> svn:externals of ./tags/latest which points to the most recent tagged
> version.  

Subversion tags are URLs in a repository.  The svn:externals values 
are stored, but not interpreted, in the repository.  

> This all works fine.  What I'd like to do and seem to be
> unable is to use svn:externals to point from /tools/tags/v2.0/libs to
> /libs/tags/latest, as that directory only exists as a property of it's
> parent.  I'd like to use this so that I don't have to worry about
> updating the libs path for my tools every time I release a new
> version.
> 
> Does anyone have any ideas on how I might be able to accomplish this
> or a more effective way of managing this code?

One idea is to

  svn rm ^/libs/tags/latest
  svn cp ^/libs/tags/1.1 ^/libs/tags/latest

every time you create a new tag, so that the .../latest URL is a copy
of the most recent tag.  Teams accustomed to "promotion levels"
(i.e., coming from a version control system that includes build and
release management) often use this kind of scheme after switching 
to Subversion.

But the actual content of .../latest is obscured by the generic name.
You need to run 'svn log' to find out what's actually there.

I'd prefer to use unique tag URLs in svn:externals, with peg revisions
of course.  When tagging a new releases, instead of silently swapping
a .../latest URL, I'd announce it via a bug-tracker or continuous 
integration system.  Or by email or just shouting across the room.  

Steve
--
Stephen Butler | Consultant
elego Software Solutions GmbH
Gustav-Meyer-Allee 25, 13355 Berlin, Germany
tel: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elego.de
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719