Edgewall Software

Ticket #2440 (closed defect: fixed)

Opened 3 years ago

Last modified 3 years ago

Error using initenv with 0.9.1 on Win32

Reported by: alasdair@… Owned by: cboos
Priority: high Milestone: 0.9.3
Component: version control Version: 0.9
Severity: normal Keywords:
Cc:

Description (last modified by cboos) (diff)

After building the wiki pages, I get the following error while running initenv in trac-admin (trying to index the repository). This is on a Python 2.3, Win32 install (following the wiki pages on how to install on Windows). This problem disappears if I revert the "Lib\site-packages\trac\versioncontrol" folder back to the files which came with version 0.9b2

Indexing repository
Failed to initialize environment. null argument to internal routine
Traceback (most recent call last):
File "C:\Python23\Lib\site-packages\trac\scripts\admin.py", line 610, in do_initenv
repos.sync()

File "C:\Python23\Lib\site-packages\trac\versioncontrol\cache.py", line 83, in sync
for path,kind,action,base_path,base_rev in changeset.get_changes():

File "C:\Python23\Lib\site-packages\trac\versioncontrol\svn_fs.py", line 488, in get_changes
change.base_path, pool())

SystemError: null argument to internal routine 

Attachments

Change History

Changed 3 years ago by cboos

  • owner changed from jonas to cboos
  • priority changed from normal to high
  • component changed from general to version control
  • description modified (diff)
  • milestone set to 0.9.2

I can't reproduce this. What version of the SVN bindings are you using? Also, after the above failure, it should be nevertheless possible to run a trac-admin resync command. Please do that with the log level set to DEBUG. i.e. configure your trac.ini like that:

[logging]
log_file = trac.log
log_level = DEBUG
log_type = stderr

Then, for which changeset does the initial error occur? What is the output of svn log -r XXX -v for that revision?

Changed 3 years ago by mgood

  • milestone changed from 0.9.2 to 0.9.3

I don't think that this will be done for 0.9.2

Changed 3 years ago by cboos

  • status changed from new to assigned

Can you try the following fix:

Index: svn_fs.py
===================================================================
--- svn_fs.py	(revision 2599)
+++ svn_fs.py	(working copy)
@@ -484,10 +484,11 @@
                     action = Changeset.ADD
             else:
                 action = Changeset.EDIT
+                base_path = change.base_path or change.path
                 change.base_rev = fs.node_created_rev(prev_root,
-                                                      change.base_path, pool())
+                                                      base_path, pool())
                 change.base_path = fs.node_created_path(prev_root,
-                                                      change.base_path, pool())
+                                                      base_path, pool())
             kind = _kindmap[change.item_kind]
             path = path[len(self.scope) - 1:]
             base_path = _scoped_path(self.scope, change.base_path)

Changed 3 years ago by alasdair@…

I'm using SVN 1.2.3 with python bindings 1.2.3

Here is the output from svn log -r 36 -v

r36 | randolph | 2005-05-11 15:29:23 +0100 (Wed, 11 May 2005) | 1 line Changed paths:

M /branches/8.7/projectx

The debug log has the following information:

Trac[cache] DEBUG: Caching node change in [36]: ('branches/8.7/projectx, 'dir', 'edit', 'branches/8.7/projectx', 23)

Command failed: null argument to internal routine Trac[svn_fs] DEBUG: Closing subversion file-system at e:\subversion\repositories\myproject

The suggested patch didn't seem to work - exactly the same error occurs (though the error message reflects the changes to the svn_fs.py file)

Changed 3 years ago by cboos

Can you post the output of svn log -r 37 -v, since it's actually that one and not r36 which must be the problematic changeset.

In the meantime, I've upgraded my SVN bindings to version 1.2.3, but I still can't reproduce the issue.

Changed 3 years ago by alasdair@…

Hi, Here is the output from revision 37. I have tried with a new repository (nothing checked in) and everything seems to work fine, so I guess it is something to do with this checkin.

------------------------------------------------------------------------
r37 | randolph | 2005-05-11 15:30:08 +0100 (Wed, 11 May 2005) | 1 line
Changed paths:
   A /branches/8.7/SchComp (from /branches/8.7/prsa:5)
   M /branches/8.7/SchComp/MSSCCPRJ.SCC
   D /branches/8.7/SchComp/Grid.oca
   D /branches/8.7/SchComp/SA.Changes.txt
   A /branches/8.7/SchComp/SchComp.build
   D /branches/8.7/SchComp/SchComp.oca
   M /branches/8.7/SchComp/SchComp.vbp
   D /branches/8.7/SchComp/SchComp_file.inc
   D /branches/8.7/SchComp/SystemDB/ENG/Order Comparison Actions.tbl.$$$
   D /branches/8.7/SchComp/Translate.txt
   D /branches/8.7/SchComp/XMLCode.bas.bak
   M /branches/8.7/SchComp/SchComp.vbw
   D /branches/8.7/SchComp/prsa.build
   A /branches/8.7/SchComp/publish.cmd


------------------------------------------------------------------------

Changed 3 years ago by cboos

Ahhh... of course: the wc -> wc copy with changes :)

Ok, I'll try to cope with this case.

Changed 3 years ago by cboos

Ok, I've been able to reproduce the issue.

The following fix should now work:

Index: svn_fs.py
===================================================================
--- svn_fs.py	(revision 2615)
+++ svn_fs.py	(working copy)
@@ -457,8 +457,6 @@
     def get_changes(self):
         pool = Pool(self.pool)
         root = fs.revision_root(self.fs_ptr, self.rev, pool())
-        if self.rev > 0:
-            prev_root = fs.revision_root(self.fs_ptr, self.rev - 1, pool())
         editor = repos.RevisionChangeCollector(self.fs_ptr, self.rev, pool())
         e_ptr, e_baton = delta.make_editor(editor, pool())
         repos.svn_repos_replay(root, e_ptr, e_baton, pool())
@@ -484,10 +482,10 @@
                     action = Changeset.ADD
             else:
                 action = Changeset.EDIT
-                change.base_rev = fs.node_created_rev(prev_root,
-                                                      change.base_path, pool())
-                change.base_path = fs.node_created_path(prev_root,
-                                                      change.base_path, pool())
+                b_path, b_rev = change.base_path, change.base_rev
+                b_root = fs.revision_root(self.fs_ptr, b_rev, pool())
+                change.base_path = fs.node_created_path(b_root, b_path, pool())
+                change.base_rev = fs.node_created_rev(b_root, b_path, pool())
             kind = _kindmap[change.item_kind]
             path = path[len(self.scope) - 1:]
             base_path = _scoped_path(self.scope, change.base_path)

Changed 3 years ago by cboos

Should be fixed by r2623 in trunk. When it's reported to work, I'll port on 0.9-stable and close the ticket.

Changed 3 years ago by alasdair@…

Thanks, that patch works and the repository is indexed correctly. I only have one problem (some people are never happy!) and I'm not sure whether this is related to the patch or the upgrade to 0.9.1.

The memory usage while indexing using the 0.9b2 files increases by roughly 20MB. With this patch, it increases by roughly 500MB - the server goes very unresponsive at around checkin 750 but comes back to life after indexing is finished. Is this memory usage likely to be assosciated with this patch, or rather some different way of caching introduced with 0.9.1 (my knowledge of Python is flakey, but I wondered if this patch had introduced a recursive bug)?

Changed 3 years ago by cboos

Ouch, I expected that the patch would need more resources, but not that much!

Please try:

Index: svn_fs.py
===================================================================
--- svn_fs.py	(revision 2623)
+++ svn_fs.py	(working copy)
@@ -491,6 +491,7 @@
             base_path = _scoped_path(self.scope, change.base_path)
             changes.append([path, kind, action, base_path, change.base_rev])
             idx += 1
+        pool.clear()
 
         moves = []
         for k,v in copies.items():

If that's not enough, I'll cache the fs objects.

Changed 3 years ago by cboos

i.e.

Index: trac/versioncontrol/svn_fs.py
===================================================================
--- trac/versioncontrol/svn_fs.py       (revision 2623)
+++ trac/versioncontrol/svn_fs.py       (working copy)
@@ -464,6 +464,7 @@
         idx = 0
         copies, deletions = {}, {}
         changes = []
+        revroots = {}
         for path, change in editor.changes.items():
             if not self.authz.has_permission(path):
                 # FIXME: what about base_path?
@@ -483,7 +484,11 @@
             else:
                 action = Changeset.EDIT
                 b_path, b_rev = change.base_path, change.base_rev
-                b_root = fs.revision_root(self.fs_ptr, b_rev, pool())
+                if revroots.has_key(b_rev):
+                    b_root = revroots[b_rev]
+                else:
+                    b_root = fs.revision_root(self.fs_ptr, b_rev, pool())
+                    revroots[b_rev] = b_root
                 change.base_path = fs.node_created_path(b_root, b_path, pool())
                 change.base_rev = fs.node_created_rev(b_root, b_path, pool())
             kind = _kindmap[change.item_kind]

This could make a difference. Let's hope the pool.clear() was enough...

Changed 3 years ago by alasdair@…

The pool.clear() didn't really help for me (not sure if there was an improvement, I ran out of swapfile both times!). The 2nd patch you thought may help works perfectly (I used it with the pool.clear()) - the memory usage was more like 110MB increase.

With all the patches, it seems to work well for me and the problem is definitely fixed from what I can tell.

Thanks!

Changed 3 years ago by cboos

  • status changed from assigned to closed
  • resolution set to fixed

Applied second patch to trunk (r2624) and ported the whole set of changes to 0.9-stable (r2625).

Changed 3 years ago by cmlenz

#2525 has been marked as duplicate of this ticket.

Add/Change #2440 (Error using initenv with 0.9.1 on Win32)

Author



Change Properties
<Author field>
Action
as closed
Next status will be 'reopened'
 
Note: See TracTickets for help on using tickets.