1000goalsoffice / support-tools

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

Migrating attachments #10

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I plan to migrate a project from GoogleCode to Bitbucket. The main reason not 
choosing GitHub was it's issue handler doesn't support file attachments(just 
pictures). But Bitbucket does! The GoogleCodeProjectHosting.json file created 
by Takeout contains all necessary info to concatenate an attachment url ,so it 
would be nice to have a command line option to migrate file attachments of 
issue comments too.

Original issue reported on code.google.com by gbtami on 24 Jan 2015 at 8:34

GoogleCodeExporter commented 9 years ago
Created a clone https://code.google.com/r/gbtami-googlecode2bitbucket/
It converts attachments and updates to logs. (The code contains some PyChess 
specific labels and milestones.)

Original comment by gbtami on 27 Jan 2015 at 8:37

GoogleCodeExporter commented 9 years ago
Attached is a patch (download_support.patch) created at revision 8ac29fcfa 
based on the changes from comment #1 and including the following enhancements:

- Fix the project download URL (all project URLs have the form 
https://code.google.com/p/...).
- Don't re-download an attachment if it already exists in the attachments path.
- Also unescape "&" in FixUpComment.
- Remove PyChess-specific logic.

Also attached is the example of converting an issue from Google Code to 
Bitbucket:
example_google_code.pdf = Original issue.
example_bitbucket.pdf = Bitbucket import including the changes from this patch.

One additional nice-to-have feature would be better formatting [1] in 
FixUpComment for comments that include code snippets or call stacks. The 
default Markdown formatting for these is usually quite bad, including breaking 
other Markdown syntax if the comment code brackets (`{}`) are unmatched (see 
comments #1 and #4 in the example pdf for examples of bad formatting).

Also, it should be noted that the target attachments folder (passed via 
--attachments_path=<path>) needs to be relative to the db-1.0.json file 
location and included in the zip archive uploaded in Bitbucket.

[1] 
https://bitbucket.org/tutorials/markdowndemo/overview#markdown-header-code-and-s
yntax-highlighting

Original comment by magreenb...@gmail.com on 13 Mar 2015 at 10:54

Attachments:

GoogleCodeExporter commented 9 years ago
Attached is an updated patch with a few more minor enhancements:

- Add a space after "@" to avoid user references.
- Escape "\", "`", "_", "*" and "#" which are otherwise treated as formatting. 
This makes python and C++ call stacks look decent.
- Map "done" and "verified" statuses to "resolved".

Original comment by magreenb...@gmail.com on 14 Mar 2015 at 2:48

Attachments:

GoogleCodeExporter commented 9 years ago
@magreenblatt, thank you for the patches. I'll try to merge them in as soon as 
I can.

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

GoogleCodeExporter commented 9 years ago
Thank for the patch. However, I get a 404 error when trying to download first 
attachement with gbtami cloned script and a "Failed to download..." message 
error with the above patch for all attachments. When directly  typing the 
address returned by the error log in a browser, the file is however accessible.

Could you tell me what I'm doing wrong and if I'm missing something to allow 
HTTP downloads from a python script (windows user here) ?

Original comment by ekeeke31@gmail.com on 15 Mar 2015 at 6:18

GoogleCodeExporter commented 9 years ago
@comment#5: You'll get the "Failed to download..." error with the patch if the 
directory passed to `--attachments_path` does not already exist.

Original comment by magreenb...@gmail.com on 15 Mar 2015 at 7:02

GoogleCodeExporter commented 9 years ago
Thanks for your answer.

The directory passed as parameter exists but it seems like the patch actually 
fails if the attachment file does not exist locally.

I fixed it by removing the following line:
if not os.path.exists(path):

At this step, path contains the full pathname for the file (attachments_path/ 
attachmentId) so I'm not sure if this intended behavior or a bug.

Original comment by ekeeke31@gmail.com on 15 Mar 2015 at 7:28