#3521 closed enhancement (worksforme)
Updates sourceforge2trac.py to work with at least trac 0.9.6
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | contrib | Version: | 0.9.6 |
Severity: | normal | Keywords: | helpwanted contrib review |
Cc: | wojdyr@…, techtonik@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
This updates the necessary field names for the script to run correctly. I have however run into an issue with the way the script is built and the way sourceforge stores mass updates to tickets in the xml dump. And that being that time stamps get duplicated when comments were added very shortly after a mass comment addition. This isn't major, but due to my current lack of time, the script does not handle this at all and dies out. There is however a commented out line to help you find the culprit and then adjust the time in the xml file directly.
Attachments (5)
Change History (24)
by , 18 years ago
Attachment: | sourceforge2trac.py.diff added |
---|
comment:3 by , 18 years ago
Hi,
Last night we patched the latest version of sourceforge2trac.py with the 2nd attached diff and were able to successfully import our sourceforge project. So, I think it is safe to commit the patch if anyone around can do that.
Thank you so much for your help and hard work!
Cheers, Mark
comment:4 by , 18 years ago
Keywords: | helpwanted added |
---|---|
Milestone: | → none |
comment:5 by , 17 years ago
I've been working on this as well last night. I was not able to import my projects and started work on the script without having a look on the trac tickets first *DUH*
I can upload a diff where I first create a sql query before running execute so it's even easier to find ticket_change queries that wont work because of the same time/ticket/field values.
What I did was drop the table and recreate it without the UNIQUE constraint before running this script.
comment:6 by , 17 years ago
Milestone: | not applicable → 0.11.1 |
---|
Is there any reason why we should not just update this in /contrib? I looks a lot more sound than the current import script that still uses kind=
for enum types…
However, I won't be testing it myself so I can just commit it as-is on blind faith - thinking it will anyway be much better than what we currently have in trunk…
comment:8 by , 17 years ago
BTW: It would be great if anyone with recent success with this script can verify that #2808 is no longer an issue - ie. using Postgres and non-ascii characters in tickets.
comment:9 by , 17 years ago
I just uploaded sourceforge2trac-patch.txt which includes the changes I needed to make to get the sourceforge2trac.py script to import the tracker export into trac-0.10.4. The diff is against SVN trunk as of a few minutes ago.
I'm not too thrilled about mvanbaak's patch as it removes the use of bind variables (ick).
comment:10 by , 17 years ago
I've tried the sourceforge2trac-patch.txt against trac 0.11b2 with SQLite version 3.5.7. It works fine except the changetime value that generate a "TypeError: a float is required" when I try to browse te ticket. To fix it I've executed the following query:
update ticket set changetime=0;
Regards, Luca
comment:11 by , 17 years ago
To set the correct data I've executed for each ticket the following query:
update ticket set changetime=(select distinct time from ticket_change where ticket=$i) where id = $i;
where $i is the ticket id Regards, Luca
comment:12 by , 17 years ago
I'm attaching a new script sfn2trac.py for SF import, that was just used for wxWidgets/wxPython migration ( http://trac.wxwidgets.org/ ).
It takes a file in different format as an input (a new SF backup file) and imports also attachments and users.
comment:13 by , 16 years ago
Cc: | added |
---|
I submitted the new script here: http://trac-hacks.org/wiki/SfnToTracScript
comment:14 by , 16 years ago
Keywords: | contrib added |
---|---|
Milestone: | 0.11-retriage → not applicable |
comment:15 by , 15 years ago
Cc: | added |
---|
Will it be removed from contrib/ with not applicable milestone or just wait until somebody contributes a better patch?
comment:16 by , 15 years ago
Keywords: | review added |
---|
I'm all for removing it from contrib and just leaving it on http://trac-hacks.org.
comment:17 by , 15 years ago
Component: | general → contrib |
---|---|
Owner: | changed from | to
Let's just do that then.
We should keep in contrib the scripts actively maintained.
Same thing for bugzilla2trac and others, when someone feels like starting a "fork" and maintain it on TracHacks or elsewhere, we'll also remove it.
Too bad for my just created contrib component ;-)
follow-up: 19 comment:18 by , 15 years ago
Milestone: | not applicable |
---|---|
Resolution: | → worksforme |
Status: | new → closed |
Wait, looks like the contrib/sourceforge2trac.py is now more up to date than this sfn2trac.py script (which was not really maintained there either after the initial code drop).
So if someone feels like creating a NewHack from the current sourceforge2trac.py script, please do so, in the meantime there's no harm in keeping it in the contrib (as it can then get the occasional update, like happened for r9169).
comment:19 by , 15 years ago
Replying to cboos:
Wait, looks like the contrib/sourceforge2trac.py is now more up to date than this sfn2trac.py script (which was not really maintained there either after the initial code drop).
I'm the maintainer of sfn2trac.py. The script haven't been updated since we finished the migration of wxWidgets to Trac, because I haven't got any feedback from other users and I even don't know if anyone else was considering using this script.
I guess that there are not that many people doing migrations, and most of them probably just finds the official script and is not aware of the alternative. I'm not for removing the official script from contrib/, but it could be useful for some users if you put a comment in this script with a link to sfn2trac.py. AFAICS the script in contrib/ still can't download attachments, so sfn2trac.py can be more useful in some cases.
the patch