You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2012/05/01 11:43:20 UTC

Re: error when upgrading working copy

Ryan Schmitz <js...@marketstar.com> writes:

> Is there another way for me to run 'svn status'?

We might be able to do without.  It's unfortunate that the abort message
doesn't give us the filename, if you can run under a debugger the stack
trace would help.  Or make your woking copy available to somebody else.

Failing that we have to resort to examining the .svn/entries files
manually--there is one in every directory in a 1.6 working copy.  The
upgrade output can help identify which .svn/entries to examine. Given:

Upgrade 'F'
Upgrade 'F/X'
Upgrade 'F/A'
Upgrade 'F/A/P'
Upgrade 'F/A/Y'
Abort

then we know the problem occurred after 'F/A/Y' and is not in any of the
directories in the output.  It should be the first of:

  - subdirectories of 'F/A/Y' such as 'F/A/Y/T'

  - subdirectories of 'F/A' such as 'F/A/T'

  - subdirectories of 'F' such as 'F/T'

  - subdirectories of '' such as 'T'

What we want to identify is the .svn/entries files that has a "deleted"
token.  You can generally open these files with an editor on Linux but I
don't know which Windows tool to suggest.  The token is a line of text
"deleted" (not "delete" which is a separate token that is not
interesting in this case).

-- 
Philip

RE: error when upgrading working copy

Posted by Ryan Schmitz <js...@marketstar.com>.
Yes! I removed the 'delete' before the deleted flag, leaving in the empty line preceding it, and I was able to upgrade SVN to 1.7.6. Thanks for all your help!

Ryan Schmitz   |   OLAP Developer / Kalido Specialist   |   MarketStar   |   People + Knowledge Accelerating Sales
e  jschmitz@marketstar.com   |   w  801.786.5287   |   m  435.553.1230   |   f  801.393.4115



-----Original Message-----
From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of Philip Martin
Sent: Tuesday, May 01, 2012 2:14 PM
To: Ryan Schmitz
Cc: Daniel Shahaf; users@subversion.apache.org
Subject: Re: error when upgrading working copy

Ryan Schmitz <js...@marketstar.com> writes:

> It appears to be failing in the Data Definitions subfolder. There were
> no 'deleted' flags in the entries folder there, but there were several
> in the folders that were at the next level down. I've pasted the
> entries with the deleted flag below, and the first one,
> DeviceSalesLastSevenDaysdir caught my eye because it has both delete
> and deleted.

That will be it.

"delete" means "delete this at the next commit".

"deleted" means "commit has deleted this" or "update has removed this".

I don't think it's valid for a node to have both set.

> These entries refer to folders at the next level that were recently
> deleted, and I remember that, for this first one, I accidentally
> deleted it irreversibly through the file system before deleting it
> from SVN, and I had to do something funky to get it back to a point
> that I could check it in. The folder was empty, and I tried to recover
> it through SVN, but that didn't work. I ended up creating a new folder
> with the same name and deleting it through SVN, but it was tricky when
> committing. I hope this is helpful to your evaluation process. I've
> attached the three entries folders that I've examined for your
> reference and named them for the folder they resided in.

The delete/deleted combination is not supposed to occur, it's a 1.6 bug that it let you get into that state.

You may be able to upgrade the rest of the working copy by editing the .svn/entries file that has the delete/deleted entry. Remove the delete but make sure to leave the empty line.

$ svnadmin create repo
$ svn mkdir -mm file://`pwd`/repo/A
$ svn1.6 co file://`pwd`/repo wc
$ svn1.6 up -r0 wc/A
$ edit wc/.svn/entries          # add delete at line 34
$ svn1.7 upgrade wc
svn: E235000: In file '../src-1.7/subversion/libsvn_wc/entries.c' line 126: assertion failed (entry->schedule == svn_wc_schedule_add || entry->schedule == svn_wc_schedule_normal) Aborted

It appears that 1.6 ignores the delete and gives deleted precedence:

$ svn1.6 st wc
$ svn1.6 info wc/A
wc/A:  (Not a versioned resource)
svn: A problem occurred; see other errors for details

I suppose 1.7 could do the same but upgrading corrupt working copies is not really practical because we don't know what else is broken.

--
Philip
This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by replying to sender.

Re: error when upgrading working copy

Posted by Philip Martin <ph...@wandisco.com>.
Ryan Schmitz <js...@marketstar.com> writes:

> It appears to be failing in the Data Definitions subfolder. There were
> no 'deleted' flags in the entries folder there, but there were several
> in the folders that were at the next level down. I've pasted the
> entries with the deleted flag below, and the first one,
> DeviceSalesLastSevenDaysdir caught my eye because it has both delete
> and deleted.

That will be it.

"delete" means "delete this at the next commit".

"deleted" means "commit has deleted this" or "update has removed this".

I don't think it's valid for a node to have both set.

> These entries refer to folders at the next level that
> were recently deleted, and I remember that, for this first one, I
> accidentally deleted it irreversibly through the file system before
> deleting it from SVN, and I had to do something funky to get it back
> to a point that I could check it in. The folder was empty, and I tried
> to recover it through SVN, but that didn't work. I ended up creating a
> new folder with the same name and deleting it through SVN, but it was
> tricky when committing. I hope this is helpful to your evaluation
> process. I've attached the three entries folders that I've examined
> for your reference and named them for the folder they resided in.

The delete/deleted combination is not supposed to occur, it's a 1.6 bug
that it let you get into that state.

You may be able to upgrade the rest of the working copy by editing the
.svn/entries file that has the delete/deleted entry. Remove the delete
but make sure to leave the empty line.

$ svnadmin create repo
$ svn mkdir -mm file://`pwd`/repo/A
$ svn1.6 co file://`pwd`/repo wc
$ svn1.6 up -r0 wc/A
$ edit wc/.svn/entries          # add delete at line 34
$ svn1.7 upgrade wc
svn: E235000: In file '../src-1.7/subversion/libsvn_wc/entries.c' line 126: assertion failed (entry->schedule == svn_wc_schedule_add || entry->schedule == svn_wc_schedule_normal)
Aborted

It appears that 1.6 ignores the delete and gives deleted precedence:

$ svn1.6 st wc
$ svn1.6 info wc/A
wc/A:  (Not a versioned resource)
svn: A problem occurred; see other errors for details

I suppose 1.7 could do the same but upgrading corrupt working copies is
not really practical because we don't know what else is broken.

-- 
Philip

RE: error when upgrading working copy

Posted by Ryan Schmitz <js...@marketstar.com>.
Philip and Daniel,

It appears to be failing in the Data Definitions subfolder. There were no 'deleted' flags in the entries folder there, but there were several in the folders that were at the next level down. I've pasted the entries with the deleted flag below, and the first one, DeviceSalesLastSevenDaysdir caught my eye because it has both delete and deleted. These entries refer to folders at the next level that were recently deleted, and I remember that, for this first one, I accidentally deleted it irreversibly through the file system before deleting it from SVN, and I had to do something funky to get it back to a point that I could check it in. The folder was empty, and I tried to recover it through SVN, but that didn't work. I ended up creating a new folder with the same name and deleting it through SVN, but it was tricky when committing. I hope this is helpful to your evaluation process. I've attached the three entries folders that I've examined for your reference and named them for the folder they resided in.

Development\Data Definitions\RIM.Data.Implementations\.svn\entries -
DeviceSalesLastSevenDaysdirdeletedeleted
DeviceAttributesdirdeleted
CompetitiveStoreSalesPercentdirdeleted
POPPresencedirdeleted
ExpenseSubCategorydirdeleted
PassThroughTypedirdeleted
AdminTimeRIMBusinessUnitdirdeleted
DeviceAttributedirdeleted
VisitDeviceSalesFactorsdirdeleted
POPTypedirdeleted

Development\Data Definitions\RIM.Data.Migrations\.svn\entries -
1.POPPresencedirdeleted
2.AdminTimeRIMBusinessUnitdirdeleted
1.DeviceAttributedirdeleted
1.DeviceAttributesdirdeleted
1.VisitDeviceSalesFactorsdirdeleted
1.POPTypedirdeleted
1.ExpenseSubCategorydirdeleted
1.CompetitiveStoreSalesPercentdirdeleted
1.DeviceSalesLastSevenDaysdirdeleted
1.PassThroughTypedirdeleted

Thanks again for your help,

Ryan Schmitz   |   OLAP Developer / Kalido Specialist   |   MarketStar   |   People + Knowledge Accelerating Sales
e  jschmitz@marketstar.com   |   w  801.786.5287   |   m  435.553.1230   |   f  801.393.4115



-----Original Message-----
From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of Philip Martin
Sent: Tuesday, May 01, 2012 6:42 AM
To: Daniel Shahaf
Cc: Ryan Schmitz; users@subversion.apache.org
Subject: Re: error when upgrading working copy

Daniel Shahaf <d....@daniel.shahaf.name> writes:

> Philip Martin wrote on Tue, May 01, 2012 at 10:43:20 +0100:
>> Ryan Schmitz <js...@marketstar.com> writes:
>>
>> > Is there another way for me to run 'svn status'?
>>
>> We might be able to do without.  It's unfortunate that the abort
>> message doesn't give us the filename, if you can run under a debugger
>> the stack trace would help.  Or make your woking copy available to somebody else.
>>
>
> Would a syscall trace (strace equivalent) help?

It would probably tell us which .svn/entries file to look at: the last one opened.

--
Philip
This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent responsible for delivering the message to the intended recipient, is prohibited. If you have received this e-mail in error, please immediately notify us by replying to sender.

Re: error when upgrading working copy

Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:

> Philip Martin wrote on Tue, May 01, 2012 at 10:43:20 +0100:
>> Ryan Schmitz <js...@marketstar.com> writes:
>> 
>> > Is there another way for me to run 'svn status'?
>> 
>> We might be able to do without.  It's unfortunate that the abort message
>> doesn't give us the filename, if you can run under a debugger the stack
>> trace would help.  Or make your woking copy available to somebody else.
>> 
>
> Would a syscall trace (strace equivalent) help?

It would probably tell us which .svn/entries file to look at: the last
one opened.

-- 
Philip

Re: error when upgrading working copy

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Philip Martin wrote on Tue, May 01, 2012 at 10:43:20 +0100:
> Ryan Schmitz <js...@marketstar.com> writes:
> 
> > Is there another way for me to run 'svn status'?
> 
> We might be able to do without.  It's unfortunate that the abort message
> doesn't give us the filename, if you can run under a debugger the stack
> trace would help.  Or make your woking copy available to somebody else.
> 

Would a syscall trace (strace equivalent) help?

> What we want to identify is the .svn/entries files that has a "deleted"
> token.  You can generally open these files with an editor on Linux but I
> don't know which Windows tool to suggest.  The token is a line of text
> "deleted" (not "delete" which is a separate token that is not
> interesting in this case).

I would copy entries to entries.txt and open the latter in notepad.
This also avoids any chance of 'entries' being changed silently by
a DWIM-y editor.