Add support for using PostgreSQL database and other enhancements #35
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use pg gem and use query syntax compatible with it.
Existing code was confused about whether it wanted to use the usernames or emails and used different keys when looking up the assignee and the comment author, fix it to always use Trac usernames which seems more logical and avoids an unnecessary database lookup. Also obfuscate the emails if we do use it and also include Trac username in the string used on GitHub to allow searching by it later.
This can be useful to check that we can do everything but actually creating the tickets correctly.
Avoid creating useless comments without any contents for the changes we don't handle (such as those to the milestone field).
We only use the final value for the assignee and the intermediate changes are not really interesting, but leak (unobfuscated) email addresses.
Just map them to SHA-1s directly, GitHub will recognize them.
Trac stores changes to each field separately, but presents them as a single change at the UI level, so do the same thing for the issues that we create.
They're not shown in Trac (except to admins) and so can be reasonably considered to be private, so don't show them publicly.
This is possible, i.e. there can be a row in session_attribute table with the correct sid and empty value.
This allows to run the script for testing on the repositories without the user accounts used in user mappings.
Importing milestones may be useful too.
This is useful to test migration of a single ticket, for example.
Checking too often is counterproductive and just results in exhausting the request quota.
Doing it for all keywords is not a good idea as there are typically too many of them, but it can be still worth doing it for some selected keywords, that can now be specified in the labels config file section.
vadz
force-pushed
the
pg-and-other-enhancements
branch
from
0a439f2 to
a38107e
Compare
This can be useful when using custom statuses, e.g. "confirmed" for the tickets that were verified to be reproducible.
This is helpful when importing issues into an existing repository with some existing PRs, as they take consume numbers in the same namespace as the issues, making it impossible to preserve (all) the existing issue numbers. Using this option it's at least possible to start importing from some round number, e.g. 100, or 1000, so that the old ticket N is now mapped to 100+N or 1000+N.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
First of all, thanks for your script, it was really great to be able to use it!
I'm submitting a PR with some changes that we've made to this useful script in order to migrate ~20000 tickets from out Trac to GitHub.
All commits here are more or less independent, so you can omit those of them that don't seem useful to you, but hopefully at least some of them (or maybe even all?) will be helpful.