search

1000goalsoffice / support-tools

Automatically exported from code.google.com/p/support-tools
Apache License 2.0
0 stars 0 forks source link

maybe add a --verify_existing_comments flag. #22

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. run the github_issue_converter.py migration tool
2. in the middle of transferring comments, abort the script. In my case it was 
aborted due to the abuse filter kicking in.
3. run the github_issue_converter.py migration tool once more

What is the expected output? What do you see instead?
Expected that the tool picked up where it left of by continuing the migration 
of not yet transferred comments. But instead it skips this issue completely and 
continues with the next.

What version of the product are you using? On what operating system?
Linux *** 3.13.0-43-generic #72~precise1-Ubuntu SMP Tue Dec 9 12:14:18 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

Original issue reported on code.google.com by hans.bec...@gmail.com on 13 Mar 2015 at 12:10

GoogleCodeExporter commented 9 years ago

Original comment by chrsm...@google.com on 14 Mar 2015 at 10:58

GoogleCodeExporter commented 9 years ago 
I really do not agree with the classification that this as an enhancement. This 
is a bug in my opinion.
As it currently works projects are not migrated properly due to the GitHub 
abuse filter or any other issue occurring while the migration is in progress.
Will the current script work if I remove the comments completely from GitHub? I 
do not think I can remove the issue itself.

Original comment by hans.bec...@gmail.com on 15 Mar 2015 at 1:42

GoogleCodeExporter commented 9 years ago 
@hans.beckerus: Until this issue is resolved, you can always delete the GitHub 
repo and retry importing from the beginning. Since there's a workaround (albeit 
an inconvenient one), this is an Enhancement.

Original comment by jasonhall@google.com on 16 Mar 2015 at 8:50

GoogleCodeExporter commented 9 years ago 
That workaround is not applicable in my use case. I have had the code 
duplicated in SVN and GIT for a very long time. Deleting the repo, and import 
from scratch, would throw away all history and commit ids. Thus, this is a bug 
and not an enhancement. Sorry, but to me it is obviously a bug if a tool can 
not seamlessly handle a break during the migration. Prioritization is something 
different though. But I would really like to see some priority on this one.

Original comment by hans.bec...@gmail.com on 17 Mar 2015 at 7:33