You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Keith Williams <kw...@sauer-danfoss.com> on 2011/12/01 18:09:52 UTC
Attmpting to Update Working Directory for a Project from V1.6.17 to
V1.7.1 using SVN Upgrade working copy
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.1\ext\subversion\subversion\libsvn_wc\entries.c'
line 1654: assertion failed (parent_node || entry->schedule ==
svn_wc_schedule_normal)
Keith Williams
Software Solution Services
Group Engineer| kwilliams@sauer-danfoss.com<ma...@sauer-danfoss.com> |ph: 763-509-2049|fax: 763-559-5769
Re: Attmpting to Update Working Directory for a Project from
V1.6.17 to V1.7.1 using SVN Upgrade working copy
Posted by pjaytycy <pi...@gmail.com>.
Maybe this can happen in this specific situation if somebody uses "map
network path" to a drive letter on windows.
If the real root of the WC is \\someserver\\some\path\to\wc\root
I can probably still map a drive letter (ie V: to
\\someserver\some\path\to\wc\root\sub\folder\for\my\project
If I then use SVN 1.7 upgrade on that, SVN will not be able to see that I
only have part of the working copy.
Re: Attmpting to Update Working Directory for a Project from V1.6.17
to V1.7.1 using SVN Upgrade working copy
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Dec 5, 2011 at 5:51 PM, Philip Martin
<ph...@wandisco.com> wrote:
> "Cooke, Mark" <ma...@siemens.com> writes:
>
>> My reading of the OP was that someone had probably seleected a
>> sub-folder for conversion and that may well have succeeded. Seeing as
>> you can take a 1.6 sub-folder and effectively make it a top-level
>> folder, this makes sense to me? Or does the upgrade code crawl
>> upwards to see if folders above are versioned?
>
> The upgrade code checks the parent folder. If one were to bypass this
> check, by moving the 1.6 subfolder out of the 1.6 working copy, then it
> would be possible to upgrade the subfolder. However such an upgraded
> subfolder would be a complete 1.7 working copy. Moving it back into the
> 1.6 working copy won't work as the upgraded subfolder is now an entirely
> separate working copy.
Does it only check the parent folder, or does it travel upward until
the drive root?
Just wondering what happens with an external dir which is inside an
unversioned directory. If you run upgrade from there, will it go
upwards beyond the unversioned dir, to find that it's part of a larger
working copy?
Anyway, that's a total edge case (and probably not the problem of the
OP), but I'm just wondering.
--
Johan
Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy
Posted by Philip Martin <ph...@wandisco.com>.
"Cooke, Mark" <ma...@siemens.com> writes:
> My reading of the OP was that someone had probably seleected a
> sub-folder for conversion and that may well have succeeded. Seeing as
> you can take a 1.6 sub-folder and effectively make it a top-level
> folder, this makes sense to me? Or does the upgrade code crawl
> upwards to see if folders above are versioned?
The upgrade code checks the parent folder. If one were to bypass this
check, by moving the 1.6 subfolder out of the 1.6 working copy, then it
would be possible to upgrade the subfolder. However such an upgraded
subfolder would be a complete 1.7 working copy. Moving it back into the
1.6 working copy won't work as the upgraded subfolder is now an entirely
separate working copy.
--
Philip
RE: Attmpting to Update Working Directory for a Project from
V1.6.17 to V1.7.1 using SVN Upgrade working copy
Posted by "Cooke, Mark" <ma...@siemens.com>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: 05 December 2011 16:25
> To: Keith Williams
> Cc: users@subversion.apache.org
> Subject: Re: Attmpting to Update Working Directory for a
> Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy
>
> Keith Williams <kw...@sauer-danfoss.com> writes:
>
> > In examining the Working Copy more closely, the Folder Structure is
> > partially in 1.6 format and partially is 1.7 format. I am
> making this
> > assumption by the presence of the .svn folder in some top level
> > folders but not in others. A couple of files were deleted at the
> > repository level prior to the attempt to convert the Working Copy to
> > the 1.7 format. Since the Working Copy is on a network drive someone
> > probably updated a subfolder to 1.7 before the full working
> folder was
> > attempted to be converted which was when the failure and
> report below
> > occurred.
>
> A 1.7 working copy will have a .svn/wc.db file in the root of the
> working copy. A 1.6 working copy will have a .svn/entries
> file in every versioned folder.
>
> It's not possible to upgrade a subfolder, only an entire working copy
> can be upgraded. The upgrade process writes all the 1.7 .svn
> data, for all subfolders, into a temporary location before deleting
> any of the 1.6 data. The final step of the upgrade is to move the
> new 1.7 .svn data into place and to remove the old 1.6 .svn data.
My reading of the OP was that someone had probably seleected a sub-folder for conversion and that may well have succeeded. Seeing as you can take a 1.6 sub-folder and effectively make it a top-level folder, this makes sense to me? Or does the upgrade code crawl upwards to see if folders above are versioned?
The error then happened when someone tried to convert the real root folder, where one of the subfolders was already converted...
~ mark c
> The error message you showed happens while writing the 1.7
> .svn data, so
> it happens before any of the 1.6 .svn data has been deleted from the
> subfolders. If you have versioned subfolders that are missing .svn
> folders it is likely that something other than the upgrade was
> responsible.
>
> > There are no externals associated with this Project
> > Repository. I am not aware of any changes to nodes. We do
> make commits
> > from this working copy but would not be able to do so following the
> > upgrade of the SVN Server to 1.7 until after the upgrade of the
> > working copy to the 1.7 Format.
>
> A 1.7 server supports earlier clients and doesn't care about
> the working
> copy format. If you are unable to use the working copy it's
> because you
> upgraded the client, not the server.
>
> --
> Philip
>
Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy
Posted by Philip Martin <ph...@wandisco.com>.
Keith Williams <kw...@sauer-danfoss.com> writes:
> In examining the Working Copy more closely, the Folder Structure is
> partially in 1.6 format and partially is 1.7 format. I am making this
> assumption by the presence of the .svn folder in some top level
> folders but not in others. A couple of files were deleted at the
> repository level prior to the attempt to convert the Working Copy to
> the 1.7 format. Since the Working Copy is on a network drive someone
> probably updated a subfolder to 1.7 before the full working folder was
> attempted to be converted which was when the failure and report below
> occurred.
A 1.7 working copy will have a .svn/wc.db file in the root of the
working copy. A 1.6 working copy will have a .svn/entries file in every
versioned folder.
It's not possible to upgrade a subfolder, only an entire working copy
can be upgraded. The upgrade process writes all the 1.7 .svn data, for
all subfolders, into a temporary location before deleting any of the 1.6
data. The final step of the upgrade is to move the new 1.7 .svn data
into place and to remove the old 1.6 .svn data.
The error message you showed happens while writing the 1.7 .svn data, so
it happens before any of the 1.6 .svn data has been deleted from the
subfolders. If you have versioned subfolders that are missing .svn
folders it is likely that something other than the upgrade was
responsible.
> There are no externals associated with this Project
> Repository. I am not aware of any changes to nodes. We do make commits
> from this working copy but would not be able to do so following the
> upgrade of the SVN Server to 1.7 until after the upgrade of the
> working copy to the 1.7 Format.
A 1.7 server supports earlier clients and doesn't care about the working
copy format. If you are unable to use the working copy it's because you
upgraded the client, not the server.
--
Philip
RE: Attmpting to Update Working Directory for a Project from
V1.6.17 to V1.7.1 using SVN Upgrade working copy
Posted by Keith Williams <kw...@sauer-danfoss.com>.
In examining the Working Copy more closely, the Folder Structure is partially in 1.6 format and partially is 1.7 format. I am making this assumption by the presence of the .svn folder in some top level folders but not in others. A couple of files were deleted at the repository level prior to the attempt to convert the Working Copy to the 1.7 format. Since the Working Copy is on a network drive someone probably updated a subfolder to 1.7 before the full working folder was attempted to be converted which was when the failure and report below occurred. There are no externals associated with this Project Repository. I am not aware of any changes to nodes. We do make commits from this working copy but would not be able to do so following the upgrade of the SVN Server to 1.7 until after the upgrade of the working copy to the 1.7 Format.
Keith
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Monday, December 05, 2011 4:58 AM
To: Keith Williams
Cc: users@subversion.apache.org
Subject: Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy
Keith Williams <kw...@sauer-danfoss.com> writes:
> 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.1\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1654: assertion failed (parent_node || entry->schedule ==
> svn_wc_schedule_normal)
That looks like one we haven't seen before. I think this occurred during an upgrade, so the working copy should still be in the 1.6 format. If we are to do anything with this report then we need to know what is special/different about this working copy.
How old is the working copy? What does 'svn status' show? What local changes do you have? Any added/deleted nodes? Switched nodes? Mixed revisions? Is it a sparse working copy? Any svn:externals, file or directory? Do you make commits from this working copy? Is it nested inside another working copy?
--
Philip
Re: Attmpting to Update Working Directory for a Project from V1.6.17 to V1.7.1 using SVN Upgrade working copy
Posted by Philip Martin <ph...@wandisco.com>.
Keith Williams <kw...@sauer-danfoss.com> writes:
> 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.1\ext\subversion\subversion\libsvn_wc\entries.c'
> line 1654: assertion failed (parent_node || entry->schedule ==
> svn_wc_schedule_normal)
That looks like one we haven't seen before. I think this occurred
during an upgrade, so the working copy should still be in the 1.6
format. If we are to do anything with this report then we need to know
what is special/different about this working copy.
How old is the working copy? What does 'svn status' show? What local
changes do you have? Any added/deleted nodes? Switched nodes? Mixed
revisions? Is it a sparse working copy? Any svn:externals, file or
directory? Do you make commits from this working copy? Is it nested
inside another working copy?
--
Philip