You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Thomas Krebs <Th...@mecadtron.de> on 2011/12/22 18:16:58 UTC
TortoiseSVN assertion failed
Hi,
I encountered the following problem in subversion/TortoiseSVN.
Background: We want to move our VisualSVN server from a W2k3 x86 to a
new server hardware/OS W2k8 x64.
I tried to move the repository by dumping/importing to the new
subversion installation. In the first place I tried CollabNet Subversion
Edge as it has a x64 variant. I could dump the repository
and import it again in the new server without problems.
When I checkout a project the icons do not get the Tortoise overlay
icons and when I right click on the project directory the Windows
shell crashes. This is absolutely reproducibly.
Using the command line tools I can produce the following error with
svn diff:
svn: E235000: In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
line 6846: assertion failed (repos_id == last_repos_id)
As I'm not sure if the problem comes from Tortoise or subversion
I tried also VisualSVN and another way to transfer the repository not
by dump/load rather than copying the hotcopy we create on a daily basis
for backup purposes. This showed the same behaviour.
I need to mention that the project in question has some svn:externals
both directories and files. Another project without externals
works fine.
The old server with the still on-line repository also still runs fine.
Hope I could contribute to find the problem.
Thomas
Re: TortoiseSVN assertion failed
Posted by Thomas Krebs <Th...@mecadtron.de>.
Am 13.02.2012 23:07, schrieb Stefan Sperling:
...
Stefan,
Please be patient. Our new server is not yet back from service, so I
can't check. Furthermore I'll have to investigate to build from
sources, which I didn't do so far.
Thomas
--
Mecadtron GmbH
Sitz der Gesellschaft: Nürnberg
Amtsgericht Nürnberg, HRB20209
Geschäftsführer: Dr. Thomas Krebs
Allersberger Str. 185
90461 Nürnberg
Germany
Tel.: +49 911 462369-0
Fax: +49 911 462369-11
www.mecadtron.de
www.mecadtron.com
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 27, 2011 at 03:28:48PM +0100, Stefan Sperling wrote:
> On Tue, Dec 27, 2011 at 03:13:34PM +0100, Thomas Krebs wrote:
> > I changed the property values to ^/... and now it is somewhat better but
> > there is still one referenced subproject that does not work! What can I
> > do here?
>
> Well, for a start, you'll have to show us exactly what you're seeing.
> By now you should understand the drill with problem reports.
> We can read neither your mind nor your screen from over here :)
>
> > But even though, I apparently won't be able to checkout or update to
> > older revisions any more...?
>
> You'll need to either wait for a new 1.7 client which has a fix to work around
> the issue (no patch exists as of yet but IMO we'll have to fix this in a
> patch release eventually because this is clearly a regression), or use a
> 1.6 client to check out those older revisions, or change the repository
> history by adjusting the svn:externals properties in older revisions.
> The latter would require a dump/load cycle filtered through svndumptool
> which you can find here: http://svn.borg.ch/svndumptool/
>
> > I'm getting somewhat nervous ...
>
> Understandably. I'm sorry you're hitting this problem. It might take
> some time to be resolved (due to people being on holidays, new year's,
> etc.) but we'll try our best to provide a fix ASAP.
Hi again Thomas,
I've implemented a fix for this problem and nominated it for backport
to the 1.7.4 release. This didn't make 1.7.3 which was released today,
sorry about that.
I am including a patch against 1.7.3 below. Are you able to you try
this patch to see if it fixes the problem for you? That would be very
valuable. Thank you!
Index: subversion/libsvn_client/externals.c
===================================================================
--- subversion/libsvn_client/externals.c (.../1.7.x) (revision 1243712)
+++ subversion/libsvn_client/externals.c (.../1.7.x-issue4087) (revision 1243712)
@@ -811,6 +811,7 @@ handle_external_item_change(const struct external_
svn_ra_session_t *ra_session;
svn_client__ra_session_from_path_results ra_cache = { 0 };
const char *new_url;
+ svn_node_kind_t kind;
ra_cache.kind = svn_node_unknown;
@@ -829,43 +830,38 @@ handle_external_item_change(const struct external_
parent_dir_url,
scratch_pool, scratch_pool));
- /* If the external is being checked out, exported or updated,
- determine if the external is a file or directory. */
- if (new_item)
- {
- svn_node_kind_t kind;
+ /* Determine if the external is a file or directory. */
+ /* Get the RA connection. */
+ SVN_ERR(svn_client__ra_session_from_path(&ra_session,
+ &ra_cache.ra_revnum,
+ &ra_cache.ra_session_url,
+ new_url, NULL,
+ &(new_item->peg_revision),
+ &(new_item->revision), eb->ctx,
+ scratch_pool));
- /* Get the RA connection. */
- SVN_ERR(svn_client__ra_session_from_path(&ra_session,
- &ra_cache.ra_revnum,
- &ra_cache.ra_session_url,
- new_url, NULL,
- &(new_item->peg_revision),
- &(new_item->revision), eb->ctx,
- scratch_pool));
+ SVN_ERR(svn_ra_get_uuid2(ra_session, &ra_cache.repos_uuid,
+ scratch_pool));
+ SVN_ERR(svn_ra_get_repos_root2(ra_session, &ra_cache.repos_root_url,
+ scratch_pool));
+ SVN_ERR(svn_ra_check_path(ra_session, "", ra_cache.ra_revnum, &kind,
+ scratch_pool));
- SVN_ERR(svn_ra_get_uuid2(ra_session, &ra_cache.repos_uuid,
- scratch_pool));
- SVN_ERR(svn_ra_get_repos_root2(ra_session, &ra_cache.repos_root_url,
- scratch_pool));
- SVN_ERR(svn_ra_check_path(ra_session, "", ra_cache.ra_revnum, &kind,
- scratch_pool));
+ if (svn_node_none == kind)
+ return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
+ _("URL '%s' at revision %ld doesn't exist"),
+ ra_cache.ra_session_url,
+ ra_cache.ra_revnum);
- if (svn_node_none == kind)
- return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
- _("URL '%s' at revision %ld doesn't exist"),
- ra_cache.ra_session_url,
- ra_cache.ra_revnum);
+ if (svn_node_dir != kind && svn_node_file != kind)
+ return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
+ _("URL '%s' at revision %ld is not a file "
+ "or a directory"),
+ ra_cache.ra_session_url,
+ ra_cache.ra_revnum);
- if (svn_node_dir != kind && svn_node_file != kind)
- return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
- _("URL '%s' at revision %ld is not a file "
- "or a directory"),
- ra_cache.ra_session_url,
- ra_cache.ra_revnum);
+ ra_cache.kind = kind;
- ra_cache.kind = kind;
- }
/* Not protecting against recursive externals. Detecting them in
the global case is hard, and it should be pretty obvious to a
@@ -873,96 +869,95 @@ handle_external_item_change(const struct external_
if (! old_defining_abspath)
{
- /* This branch is only used during a checkout or an export. */
+ /* The target dir might have multiple components. Guarantee the path
+ leading down to the last component. */
+ SVN_ERR(svn_io_make_dir_recursively(svn_dirent_dirname(local_abspath,
+ scratch_pool),
+ scratch_pool));
+ }
- /* First notify that we're about to handle an external. */
- if (eb->ctx->notify_func2)
- (*eb->ctx->notify_func2)(
- eb->ctx->notify_baton2,
- svn_wc_create_notify(local_abspath, svn_wc_notify_update_external,
- scratch_pool), scratch_pool);
-
- switch (ra_cache.kind)
- {
- case svn_node_dir:
- /* The target dir might have multiple components. Guarantee
- the path leading down to the last component. */
- SVN_ERR(svn_io_make_dir_recursively(svn_dirent_dirname(local_abspath,
- scratch_pool),
- scratch_pool));
-
- SVN_ERR(switch_dir_external(
- local_abspath, new_url,
- &(new_item->peg_revision), &(new_item->revision),
- parent_dir_abspath, eb->timestamp_sleep, eb->ctx,
- scratch_pool));
- break;
- case svn_node_file:
- SVN_ERR(switch_file_external(local_abspath,
- new_url,
- &new_item->peg_revision,
- &new_item->revision,
- parent_dir_abspath,
- ra_session,
- ra_cache.ra_session_url,
- ra_cache.ra_revnum,
- ra_cache.repos_root_url,
- eb->timestamp_sleep, eb->ctx,
- scratch_pool));
- break;
- default:
- SVN_ERR_MALFUNCTION();
- break;
- }
- }
- else
+ switch (ra_cache.kind)
{
- /* This branch handles a definition change or simple update. */
+ case svn_node_dir:
+ SVN_ERR(switch_dir_external(local_abspath, new_url,
+ &(new_item->peg_revision),
+ &(new_item->revision),
+ parent_dir_abspath,
+ eb->timestamp_sleep, eb->ctx,
+ scratch_pool));
+ break;
+ case svn_node_file:
+ if (strcmp(eb->repos_root_url, ra_cache.repos_root_url) == 0)
+ {
+ SVN_ERR(switch_file_external(local_abspath,
+ new_url,
+ &new_item->peg_revision,
+ &new_item->revision,
+ parent_dir_abspath,
+ ra_session,
+ ra_cache.ra_session_url,
+ ra_cache.ra_revnum,
+ ra_cache.repos_root_url,
+ eb->timestamp_sleep, eb->ctx,
+ scratch_pool));
+ }
+ else
+ {
+ const char *repos_uuid;
+ const char *ext_repos_relpath;
+
+ /*
+ * The working copy library currently requires that all files
+ * in the working copy have the same repository root URL.
+ * The URL from the file external's definition differs from the
+ * one used by the working copy. As a workaround, replace the
+ * root URL portion of the file external's URL, after making
+ * sure both URLs point to the same repository. See issue #4087.
+ */
- /* First notify that we're about to handle an external. */
- if (eb->ctx->notify_func2)
- {
- svn_wc_notify_t *nt;
+ SVN_ERR(svn_client__ra_session_from_path(&ra_session,
+ &ra_cache.ra_revnum,
+ &ra_cache.ra_session_url,
+ eb->repos_root_url,
+ NULL,
+ &(new_item->peg_revision),
+ &(new_item->revision),
+ eb->ctx, scratch_pool));
+ SVN_ERR(svn_ra_get_uuid2(ra_session, &repos_uuid,
+ scratch_pool));
+ ext_repos_relpath = svn_uri_skip_ancestor(ra_cache.repos_root_url,
+ new_url, scratch_pool);
+ if (strcmp(repos_uuid, ra_cache.repos_uuid) != 0 ||
+ ext_repos_relpath == NULL)
+ return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
+ _("Unsupported external: url of file external '%s' "
+ "is not in repository '%s'"),
+ new_url, eb->repos_root_url);
- nt = svn_wc_create_notify(local_abspath,
- svn_wc_notify_update_external,
- scratch_pool);
+ SVN_ERR(svn_ra_get_repos_root2(ra_session,
+ &ra_cache.repos_root_url,
+ scratch_pool));
+ new_url = svn_path_url_add_component2(ra_cache.repos_root_url,
+ ext_repos_relpath,
+ scratch_pool);
+ SVN_ERR(svn_ra_reparent(ra_session, new_url, scratch_pool));
+ SVN_ERR(switch_file_external(local_abspath,
+ new_url,
+ &new_item->peg_revision,
+ &new_item->revision,
+ parent_dir_abspath,
+ ra_session,
+ ra_cache.ra_session_url,
+ ra_cache.ra_revnum,
+ ra_cache.repos_root_url,
+ eb->timestamp_sleep, eb->ctx,
+ scratch_pool));
- eb->ctx->notify_func2(eb->ctx->notify_baton2, nt, scratch_pool);
- }
-
- /* Either the URL changed, or the exact same item is present in
- both hashes, and caller wants to update such unchanged items.
- In the latter case, the call below will try to make sure that
- the external really is a WC pointing to the correct
- URL/revision. */
- switch (ra_cache.kind)
- {
- case svn_node_dir:
- SVN_ERR(switch_dir_external(local_abspath, new_url,
- &(new_item->peg_revision),
- &(new_item->revision),
- parent_dir_abspath,
- eb->timestamp_sleep, eb->ctx,
- scratch_pool));
- break;
- case svn_node_file:
- SVN_ERR(switch_file_external(local_abspath,
- new_url,
- &new_item->peg_revision,
- &new_item->revision,
- parent_dir_abspath,
- ra_session,
- ra_cache.ra_session_url,
- ra_cache.ra_revnum,
- ra_cache.repos_root_url,
- eb->timestamp_sleep, eb->ctx,
- scratch_pool));
- break;
- default:
- SVN_ERR_MALFUNCTION();
- break;
- }
+ }
+ break;
+ default:
+ SVN_ERR_MALFUNCTION();
+ break;
}
return SVN_NO_ERROR;
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 27, 2011 at 03:13:34PM +0100, Thomas Krebs wrote:
> I changed the property values to ^/... and now it is somewhat better but
> there is still one referenced subproject that does not work! What can I
> do here?
Well, for a start, you'll have to show us exactly what you're seeing.
By now you should understand the drill with problem reports.
We can read neither your mind nor your screen from over here :)
> But even though, I apparently won't be able to checkout or update to
> older revisions any more...?
You'll need to either wait for a new 1.7 client which has a fix to work around
the issue (no patch exists as of yet but IMO we'll have to fix this in a
patch release eventually because this is clearly a regression), or use a
1.6 client to check out those older revisions, or change the repository
history by adjusting the svn:externals properties in older revisions.
The latter would require a dump/load cycle filtered through svndumptool
which you can find here: http://svn.borg.ch/svndumptool/
> I'm getting somewhat nervous ...
Understandably. I'm sorry you're hitting this problem. It might take
some time to be resolved (due to people being on holidays, new year's,
etc.) but we'll try our best to provide a fix ASAP.
Re: TortoiseSVN assertion failed
Posted by Thomas Krebs <Th...@mecadtron.de>.
Am 23.12.2011 14:59, schrieb Stefan Sperling:
> On Fri, Dec 23, 2011 at 02:26:12PM +0100, Thomas Krebs wrote:
>> Am 23.12.2011 13:08, schrieb Stefan Sperling:
>>> Well, is the URL of this file in the same _repository_ as the working
>>> copy root folder, or not? One server can serve multiple repositories so
>>> your statement doesn't clearly explain the situation.
>>
>> Yes, in the original server/repository it is in the same
>> server/repository, after moving it to the new server it (of course)
>> points to the original server/repository. I would not expect it to be
>> changed by the transfer.
>>
>>>
>>> Can you show the output of these commands?
>>> cd working_copy
>>> svn info
>>> svn info acisapp.rc
>>
>> Path: .
>> Working Copy Root Path: D:\tools\Nextra_Application-sonne
>> URL: https://sonne.mecadtron.de/svn/main/Nextra_Application
>> Repository Root: https://sonne.mecadtron.de/svn/main
>> Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
>> Revision: 19125
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: Joachim
>> Last Changed Rev: 19125
>> Last Changed Date: 2011-12-21 19:01:41 +0100 (Mi, 21 Dez 2011)
>>
>>
>> D:\tools\Nextra_Application-sonne>svn info acisapp.rc
>> Path: acisapp.rc
>> Name: acisapp.rc
>> Working Copy Root Path: D:\tools\Nextra_Application-sonne
>> URL: https://merkur.mecadtron.de/svn/main/Acis_Application/acisapp.rc
>> Repository Root: https://merkur.mecadtron.de/svn/main
>> Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
>> Revision: 19127
>> Node Kind: file
>> Schedule: normal
>> Last Changed Author: thomas
>> Last Changed Rev: 19056
>> Last Changed Date: 2011-11-29 14:47:25 +0100 (Di, 29 Nov 2011)
>> Text Last Updated: 2011-12-22 17:38:40 +0100 (Do, 22 Dez 2011)
>> Checksum: 2ba869d8c2b25d271149e4fe535f0313a99f1868
>>
>> I see the situation - the external file points to a URL that is in a
>> different server, but even that should work, right?
>
> Ah, this explains it. The repos_id is generated based on root URL and UUID.
> So you'll get a different repos_id for the file external.
> See create_repos_id() in this file:
> https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_wc/wc_db.c
>
> We might need to revisit this and generated unique repos_id's based
> on the UUID only. Not sure if that can be made to work without a working
> copy format bump though. This would mean a fix could only be released in 1.8.
>
> Try making the URLs match. That should fix the issue.
> If you use relative external syntax you should be able to checkout from
> either UR.L Put a line like this in the svn:externals property on the
> Nextra_Application folder: ^/Acis_Application/acisapp.rc acisapp.rc
I changed the property values to ^/... and now it is somewhat better but
there is still one referenced subproject that does not work! What can I
do here?
But even though, I apparently won't be able to checkout or update to
older revisions any more...?
I'm getting somewhat nervous ...
>
> Thanks a lot for your help in figuring this out!
Thomas
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 23, 2011 at 02:59:32PM +0100, Stefan Sperling wrote:
> We might need to revisit this and generated unique repos_id's based
> on the UUID only. Not sure if that can be made to work without a working
> copy format bump though. This would mean a fix could only be released in 1.8.
I've filed this as a bug:
http://subversion.tigris.org/issues/show_bug.cgi?id=4087
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 23, 2011 at 02:26:12PM +0100, Thomas Krebs wrote:
> Am 23.12.2011 13:08, schrieb Stefan Sperling:
> >Well, is the URL of this file in the same _repository_ as the working
> >copy root folder, or not? One server can serve multiple repositories so
> >your statement doesn't clearly explain the situation.
>
> Yes, in the original server/repository it is in the same
> server/repository, after moving it to the new server it (of course)
> points to the original server/repository. I would not expect it to be
> changed by the transfer.
>
> >
> >Can you show the output of these commands?
> > cd working_copy
> > svn info
> > svn info acisapp.rc
>
> Path: .
> Working Copy Root Path: D:\tools\Nextra_Application-sonne
> URL: https://sonne.mecadtron.de/svn/main/Nextra_Application
> Repository Root: https://sonne.mecadtron.de/svn/main
> Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
> Revision: 19125
> Node Kind: directory
> Schedule: normal
> Last Changed Author: Joachim
> Last Changed Rev: 19125
> Last Changed Date: 2011-12-21 19:01:41 +0100 (Mi, 21 Dez 2011)
>
>
> D:\tools\Nextra_Application-sonne>svn info acisapp.rc
> Path: acisapp.rc
> Name: acisapp.rc
> Working Copy Root Path: D:\tools\Nextra_Application-sonne
> URL: https://merkur.mecadtron.de/svn/main/Acis_Application/acisapp.rc
> Repository Root: https://merkur.mecadtron.de/svn/main
> Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
> Revision: 19127
> Node Kind: file
> Schedule: normal
> Last Changed Author: thomas
> Last Changed Rev: 19056
> Last Changed Date: 2011-11-29 14:47:25 +0100 (Di, 29 Nov 2011)
> Text Last Updated: 2011-12-22 17:38:40 +0100 (Do, 22 Dez 2011)
> Checksum: 2ba869d8c2b25d271149e4fe535f0313a99f1868
>
> I see the situation - the external file points to a URL that is in a
> different server, but even that should work, right?
Ah, this explains it. The repos_id is generated based on root URL and UUID.
So you'll get a different repos_id for the file external.
See create_repos_id() in this file:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_wc/wc_db.c
We might need to revisit this and generated unique repos_id's based
on the UUID only. Not sure if that can be made to work without a working
copy format bump though. This would mean a fix could only be released in 1.8.
Try making the URLs match. That should fix the issue.
If you use relative external syntax you should be able to checkout from
either UR.L Put a line like this in the svn:externals property on the
Nextra_Application folder: ^/Acis_Application/acisapp.rc acisapp.rc
Thanks a lot for your help in figuring this out!
Re: TortoiseSVN assertion failed
Posted by Thomas Krebs <Th...@mecadtron.de>.
Am 23.12.2011 13:08, schrieb Stefan Sperling:
> On Fri, Dec 23, 2011 at 12:05:43PM +0100, Thomas Krebs wrote:
>> Am 23.12.2011 02:52, schrieb Stefan Sperling:
>>> Are you sure you checked out a new working copy before this happened?
>>
>> The assertion only happens from the working copy checked out from the
>> new server.
>
>> sqlite> select repos_id from nodes where local_relpath = '';
>> 1
>> sqlite> select repos_id, local_relpath from nodes where
>> file_external is not null;
>> 2|acisapp.rc
>> sqlite>
>>
>> The file acisapp.rc is an external file.
>
> Thanks. That clearly shows that svn has a problem.
>
>>> If my suspicion about file externals is correct this should provide some
>>> insight. Normally the repos IDs shown in the first column should all match up.
>>> In your case there will be one or more paths shown with a repos_id that
>>> differs. Can you check the corresponding external definitions for correctness?
>>
>> What do you mean with correctness? In the original repository they
>> are correct in the way that they work. The URL points to a file on
>> the
>> server like: https://myserver.mydomain.tld/svn/main/.../blabla
>
> Well, is the URL of this file in the same _repository_ as the working
> copy root folder, or not? One server can serve multiple repositories so
> your statement doesn't clearly explain the situation.
Yes, in the original server/repository it is in the same
server/repository, after moving it to the new server it (of course)
points to the original server/repository. I would not expect it to be
changed by the transfer.
>
> Can you show the output of these commands?
> cd working_copy
> svn info
> svn info acisapp.rc
Path: .
Working Copy Root Path: D:\tools\Nextra_Application-sonne
URL: https://sonne.mecadtron.de/svn/main/Nextra_Application
Repository Root: https://sonne.mecadtron.de/svn/main
Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
Revision: 19125
Node Kind: directory
Schedule: normal
Last Changed Author: Joachim
Last Changed Rev: 19125
Last Changed Date: 2011-12-21 19:01:41 +0100 (Mi, 21 Dez 2011)
D:\tools\Nextra_Application-sonne>svn info acisapp.rc
Path: acisapp.rc
Name: acisapp.rc
Working Copy Root Path: D:\tools\Nextra_Application-sonne
URL: https://merkur.mecadtron.de/svn/main/Acis_Application/acisapp.rc
Repository Root: https://merkur.mecadtron.de/svn/main
Repository UUID: 179b6de1-e90f-224f-a09f-19cd8c20e1bf
Revision: 19127
Node Kind: file
Schedule: normal
Last Changed Author: thomas
Last Changed Rev: 19056
Last Changed Date: 2011-11-29 14:47:25 +0100 (Di, 29 Nov 2011)
Text Last Updated: 2011-12-22 17:38:40 +0100 (Do, 22 Dez 2011)
Checksum: 2ba869d8c2b25d271149e4fe535f0313a99f1868
I see the situation - the external file points to a URL that is in a
different server, but even that should work, right?
> Thanks!
Thomas
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 23, 2011 at 12:05:43PM +0100, Thomas Krebs wrote:
> Am 23.12.2011 02:52, schrieb Stefan Sperling:
> >Are you sure you checked out a new working copy before this happened?
>
> The assertion only happens from the working copy checked out from the
> new server.
> sqlite> select repos_id from nodes where local_relpath = '';
> 1
> sqlite> select repos_id, local_relpath from nodes where
> file_external is not null;
> 2|acisapp.rc
> sqlite>
>
> The file acisapp.rc is an external file.
Thanks. That clearly shows that svn has a problem.
> >If my suspicion about file externals is correct this should provide some
> >insight. Normally the repos IDs shown in the first column should all match up.
> >In your case there will be one or more paths shown with a repos_id that
> >differs. Can you check the corresponding external definitions for correctness?
>
> What do you mean with correctness? In the original repository they
> are correct in the way that they work. The URL points to a file on
> the
> server like: https://myserver.mydomain.tld/svn/main/.../blabla
Well, is the URL of this file in the same _repository_ as the working
copy root folder, or not? One server can serve multiple repositories so
your statement doesn't clearly explain the situation.
Can you show the output of these commands?
cd working_copy
svn info
svn info acisapp.rc
Thanks!
Re: TortoiseSVN assertion failed
Posted by Thomas Krebs <Th...@mecadtron.de>.
Am 23.12.2011 02:52, schrieb Stefan Sperling:
> On Fri, Dec 23, 2011 at 01:48:58AM +0100, Stefan Sperling wrote:
>> On Thu, Dec 22, 2011 at 06:16:58PM +0100, Thomas Krebs wrote:
>>> When I checkout a project the icons do not get the Tortoise overlay
>>> icons and when I right click on the project directory the Windows
>>> shell crashes. This is absolutely reproducibly.
>>> Using the command line tools I can produce the following error with
>>> svn diff:
>>> svn: E235000: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
>>> line 6846: assertion failed (repos_id == last_repos_id)
>>>
>> This is probably a file external which points to a foreign repository.
>
> Are you sure you checked out a new working copy before this happened?
The assertion only happens from the working copy checked out from the
new server.
> It wasn't upgraded from a 1.6 working copy?
No, not this working copy.
>
> Can you get the sqlite3 command shell program from
> http://sqlite.org/download.html , e.g.
> http://sqlite.org/sqlite-shell-win32-x86-3070900.zip ,
> and run the following commands in cmd.exe in the working copy?
> This will help us understand the problem better.
>
> In the top-level directory of the working copy, run this:
> sqlite3 .svn\wc.db
>
> This will prompt with 'sqlite>'. Enter:
> select repos_id from nodes where local_relpath = '';
> select repos_id, local_relpath from nodes where file_external is not null;
>
Gives:
sqlite> select repos_id from nodes where local_relpath = '';
1
sqlite> select repos_id, local_relpath from nodes where file_external is
not null;
2|acisapp.rc
sqlite>
The file acisapp.rc is an external file.
> If my suspicion about file externals is correct this should provide some
> insight. Normally the repos IDs shown in the first column should all match up.
> In your case there will be one or more paths shown with a repos_id that
> differs. Can you check the corresponding external definitions for correctness?
What do you mean with correctness? In the original repository they are
correct in the way that they work. The URL points to a file on the
server like: https://myserver.mydomain.tld/svn/main/.../blabla
> Do you have any idea when and how these externals definitions were set
> and which client version was used to set them?
>
It was done 15. of March 2010. The hole repository was converted from
MS VisualSourceSafe before. As we try to use the most recent version
of available tools it was the VisualSVN/TortoiseSVN available then,
1.6.x maybe?
> Thanks for your help!
Hope this helps.
Thomas
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Dec 23, 2011 at 01:48:58AM +0100, Stefan Sperling wrote:
> On Thu, Dec 22, 2011 at 06:16:58PM +0100, Thomas Krebs wrote:
> > When I checkout a project the icons do not get the Tortoise overlay
> > icons and when I right click on the project directory the Windows
> > shell crashes. This is absolutely reproducibly.
> > Using the command line tools I can produce the following error with
> > svn diff:
> > svn: E235000: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
> > line 6846: assertion failed (repos_id == last_repos_id)
> >
> This is probably a file external which points to a foreign repository.
Are you sure you checked out a new working copy before this happened?
It wasn't upgraded from a 1.6 working copy?
Can you get the sqlite3 command shell program from
http://sqlite.org/download.html , e.g.
http://sqlite.org/sqlite-shell-win32-x86-3070900.zip ,
and run the following commands in cmd.exe in the working copy?
This will help us understand the problem better.
In the top-level directory of the working copy, run this:
sqlite3 .svn\wc.db
This will prompt with 'sqlite>'. Enter:
select repos_id from nodes where local_relpath = '';
select repos_id, local_relpath from nodes where file_external is not null;
If my suspicion about file externals is correct this should provide some
insight. Normally the repos IDs shown in the first column should all match up.
In your case there will be one or more paths shown with a repos_id that
differs. Can you check the corresponding external definitions for correctness?
Do you have any idea when and how these externals definitions were set
and which client version was used to set them?
Thanks for your help!
Re: TortoiseSVN assertion failed
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Dec 22, 2011 at 06:16:58PM +0100, Thomas Krebs wrote:
> Hi,
>
> I encountered the following problem in subversion/TortoiseSVN.
>
> Background: We want to move our VisualSVN server from a W2k3 x86 to a
> new server hardware/OS W2k8 x64.
> I tried to move the repository by dumping/importing to the new
> subversion installation. In the first place I tried CollabNet
> Subversion Edge as it has a x64 variant. I could dump the repository
> and import it again in the new server without problems.
> When I checkout a project the icons do not get the Tortoise overlay
> icons and when I right click on the project directory the Windows
> shell crashes. This is absolutely reproducibly.
> Using the command line tools I can produce the following error with
> svn diff:
> svn: E235000: In file 'D:\Development\SVN\Releases\TortoiseSVN-1.7.3\ext\subversion\subversion\libsvn_wc\wc_db.c'
> line 6846: assertion failed (repos_id == last_repos_id)
>
> As I'm not sure if the problem comes from Tortoise or subversion
> I tried also VisualSVN and another way to transfer the repository not
> by dump/load rather than copying the hotcopy we create on a daily basis
> for backup purposes. This showed the same behaviour.
>
> I need to mention that the project in question has some svn:externals
> both directories and files. Another project without externals
> works fine.
> The old server with the still on-line repository also still runs fine.
>
> Hope I could contribute to find the problem.
This is probably a file external which points to a foreign repository.
Such file externals aren't supported but they somehow are not caught
by the code which inserts external information into working copy meta
data. So later this invalid external information violates the assumption
asserted elsewhere that all file nodes must come from the same repository.
You should fix your external definition and get a fresh checkout.
I've proposed a change for backport to 1.7.3 which transforms this
assertion into a more descriptive error message.