You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Fahlander <da...@gmail.com> on 2011/12/15 06:03:14 UTC
line 1652: assertion failed (parent_node || entry->schedule == svn_wc_schedule_normal)
Got problems after an upgrade.
1) Upgraded one sub path to 1.7
2) Upgraded sub path by sub path to 1.7
3) Failed to upgrade one of the sub paths, claiming that my localhost SVN
server disconnected the socket. This happened over and over so I decided to
make a Cleanup.
4) Cleanup failed. See below.
Note: I am using SVN server on my local machine. I also have a backup
service supervising and constantly backing up my Repositories directory as
well as my working directories... if it could be that the backup tool was
trying to read at the same time the SVN operation took place. Dont know.
Other special thing is that the root directory of my repository is my
Visual Studio 2008\Projects folder and it contains lots of subdirs but only
a few of them are included in the SVN repo.
---------------------------
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\libsvn_wc\entries.c'
line 1652: assertion failed (parent_node || entry->schedule ==
svn_wc_schedule_normal)
---------------------------
OK
---------------------------
Re: line 1652: assertion failed (parent_node || entry->schedule == svn_wc_schedule_normal)
Posted by David Fahlander <da...@gmail.com>.
Thanks for your excellent help :) Your intepretation of my structure is
correct. And the Visual Studio 2008\Projects directory is a sub directory
of My Documents created by default by VS2008.
I solved the situation by checking out a new WC. Each subdir in the old WC
worked, so there were no need to manually copy things. Only when using the
root, I got problems. Not on the new WC though.
2011/12/15 Ulrich Eckhardt <ul...@dominolaser.com>
> Am 15.12.2011 06:03, schrieb David Fahlander:
>
> Got problems after an upgrade.
>>
>> 1) Upgraded one sub path to 1.7
>> 2) Upgraded sub path by sub path to 1.7
>> 3) Failed to upgrade one of the sub paths, claiming that my localhost SVN
>> server disconnected the socket. This happened over and over so I decided
>> to
>> make a Cleanup.
>>
>
> Just so I get you right, you had the following setup:
>
> ...WC-root
> /sub1
> /sub2
> /sub3
>
> There is one big change between 1.6 and 1.7, namely that for 1.7 a
> subfolder of a working copy is not an independent working copy itself. So,
> if you upgraded sub1 above, you would permanently detach this WC from its
> parent WC. If you now tried to upgrade the WC-root dir, it would find that
> sub1 is already an upgraded working copy on its own. I don't know how it
> handles this case.
>
> Firstly, you probably avoid doing that. Secondly, SVN should arguably warn
> if you do that. It can't and shouldn't create an error, because there are
> valid reasons to actually split one big WC into several smaller ones on
> upgrade.
>
> To resolve the situation, the first thing is to make up your mind how you
> want your working copies organized. Then, if you don't have too many
> pending changes and if you have a consistent state otherwise, I'd just
> check out a new working copy and copy things over manually. The easiest way
> is not to copy the versioned data, but to copy the .svn folder. You then
> delete all .svn folders in your current WC and copy the single .svn folder
> from the new WC. Then, I'd try to update and then also to run a diff, to
> find out which local changes are not yet checked in and if that matches
> your expectations.
>
>
>
> Note: I am using SVN server on my local machine. I also have a backup
>> service supervising and constantly backing up my Repositories directory as
>> well as my working directories... if it could be that the backup tool was
>> trying to read at the same time the SVN operation took place. Dont know.
>>
>
> Virus scanners are known to cause faulty behaviour in other applications,
> this backup tool could cause the same by holding locks on files while SVN
> is trying to move them around.
>
>
>
> Other special thing is that the root directory of my repository is my
>> Visual Studio 2008\Projects folder and it contains lots of subdirs but
>> only
>> a few of them are included in the SVN repo.
>>
>
> Your terminology is a bit confusing here. Do you mean the "Visual Studio
> 2008" folder in your "own files" or "personal files" ("Eigene Dateien" in
> German)? So that one is just a folder, and SVN doesn't care if you put
> working copies along non-working-copy folders inside.
>
>
>
> In file
>> 'D:\Development\SVN\Releases\**TortoiseSVN-1.7.0\ext\**
>> subversion\subversion\libsvn_**wc\entries.c'
>> line 1652: assertion failed (parent_node || entry->schedule ==
>> svn_wc_schedule_normal)
>>
>
> You are using 1.7.0 while two further bugfix versions have been released,
> especially for problems while upgrading working copies. Upgrade!
>
>
> Good luck!
>
> Uli
> ****************************************************************
> **************************
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> ****************************************************************
> **************************
> Visit our website at http://www.dominolaser.com
> ****************************************************************
> **************************
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der
> beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu
> löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder
> anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie
> nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese
> Folgen nicht verantwortlich.
> ****************************************************************
> **************************
>
>
Re: line 1652: assertion failed (parent_node || entry->schedule ==
svn_wc_schedule_normal)
Posted by Ulrich Eckhardt <ul...@dominolaser.com>.
Am 15.12.2011 06:03, schrieb David Fahlander:
> Got problems after an upgrade.
>
> 1) Upgraded one sub path to 1.7
> 2) Upgraded sub path by sub path to 1.7
> 3) Failed to upgrade one of the sub paths, claiming that my localhost SVN
> server disconnected the socket. This happened over and over so I decided to
> make a Cleanup.
Just so I get you right, you had the following setup:
...WC-root
/sub1
/sub2
/sub3
There is one big change between 1.6 and 1.7, namely that for 1.7 a
subfolder of a working copy is not an independent working copy itself.
So, if you upgraded sub1 above, you would permanently detach this WC
from its parent WC. If you now tried to upgrade the WC-root dir, it
would find that sub1 is already an upgraded working copy on its own. I
don't know how it handles this case.
Firstly, you probably avoid doing that. Secondly, SVN should arguably
warn if you do that. It can't and shouldn't create an error, because
there are valid reasons to actually split one big WC into several
smaller ones on upgrade.
To resolve the situation, the first thing is to make up your mind how
you want your working copies organized. Then, if you don't have too many
pending changes and if you have a consistent state otherwise, I'd just
check out a new working copy and copy things over manually. The easiest
way is not to copy the versioned data, but to copy the .svn folder. You
then delete all .svn folders in your current WC and copy the single .svn
folder from the new WC. Then, I'd try to update and then also to run a
diff, to find out which local changes are not yet checked in and if that
matches your expectations.
> Note: I am using SVN server on my local machine. I also have a backup
> service supervising and constantly backing up my Repositories directory as
> well as my working directories... if it could be that the backup tool was
> trying to read at the same time the SVN operation took place. Dont know.
Virus scanners are known to cause faulty behaviour in other
applications, this backup tool could cause the same by holding locks on
files while SVN is trying to move them around.
> Other special thing is that the root directory of my repository is my
> Visual Studio 2008\Projects folder and it contains lots of subdirs but only
> a few of them are included in the SVN repo.
Your terminology is a bit confusing here. Do you mean the "Visual Studio
2008" folder in your "own files" or "personal files" ("Eigene Dateien"
in German)? So that one is just a folder, and SVN doesn't care if you
put working copies along non-working-copy folders inside.
> In file
> 'D:\Development\SVN\Releases\TortoiseSVN-1.7.0\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1652: assertion failed (parent_node || entry->schedule ==
> svn_wc_schedule_normal)
You are using 1.7.0 while two further bugfix versions have been
released, especially for problems while upgrading working copies. Upgrade!
Good luck!
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************