Christian Hammond wrote:
> I think we need a better way to factor this all out, though. Otherwise
> you'll have to maintain a custom patch for every upgrade.
>
> Can you tell me where you placed the first bit of code (encoding
> changeset0['desc'])?
>
> We probably can reuse the repository's Encoding field and insert the
> lines into perforce.py to respect it, in much the same way that you
> did. So instead of unicode(something, 'cp949'), it'd be
> unicode(something, repository.encoding). Right now, that field only
> appears to affect the patches.
>
> And in your case, what does p4.charset show?

This is a good example of why we need support for named encoding in
postreview, doing a look up is certainly the right thing to do; by
checking the source code control system (where possible) and the
ReviewBoard repository encoding. However we also need an override/force
option.

In the first instance a command line parameter would be useful.

RE where the decode() call (rather than unicode) takes places, I'd
suggest around line 3877. Either before or after:

if options.output_diff_only:
# The comma here isn't a typo, but rather suppresses the extra newline
print diff,
sys.exit(0)

The print would probably need a repr() around it if done before.

Line 3854 also needs a change to open options.diff_filename in binary
('rb') mode.


Example code:

diff_encoding = 'utf-8'
diff_encoding = 'cp949' # ... from command line, config file, lookup in
RB repo, etc.
......
diff = diff.decode(diff_encoding)

Chris

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to