This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 124870 - ldif files are base64/mime encoded during diff export.
Summary: ldif files are base64/mime encoded during diff export.
Status: RESOLVED FIXED
Alias: None
Product: versioncontrol
Classification: Unclassified
Component: Subversion (show other bugs)
Version: 6.x
Hardware: Macintosh All
: P3 blocker with 1 vote (vote)
Assignee: issues@versioncontrol
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-08 09:43 UTC by abobrov
Modified: 2008-07-21 16:47 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description abobrov 2008-01-08 09:43:39 UTC
the problem is with 6.0 release and it is a regression as it has never happened in milestone builds
although i did skip the beta so i assume this regression got introduced somewhere between m10 and
release.

basically we have some .ldif files in our project, they are ascii text files containing ldap config
entries, no special characters or weird headers just plain text files, see here for some examples :

http://builds2.opends.org/source/xref/trunk/opends/resource/config/config.ldif
http://builds2.opends.org/source/xref/trunk/opends/resource/schema/02-config.ldif

these files are under NB freeform project in my case and they are under SVN management. when i do a
diff of my changes from within NB such diff itself looks absolutely fine. the problem occurs when
i try to export diff patch. when i do that all ldif files like the ones mentioned above are mime /
base64 encoded in the resulting diff file. here is what it looks like, just the headers of each :

# This patch file was generated by NetBeans IDE
# Following Index: paths are relative to: /Users/test/Projects/OpenDS/src/opends
# This patch can be applied using context Tools: Patch action on respective folder.
# It uses platform neutral UTF-8 encoding and \n newlines.
# Above lines and this line are ignored by the patching process.
Index: resource/config/config.ldif
MIME: application/octet-stream; encoding: Base64; length: 81078
IyBDRERMIEhFQURFUiBTVEFSVAojCiMgVGhlIGNvbnRlbnRzIG9mIHRoaXMg
ZmlsZSBhcmUgc3ViamVjdCB0byB0aGUgdGVybXMgb2YgdGhlCiMgQ29tbW9u
IERldmVsb3BtZW50IGFuZCBEaXN0cmlidXRpb24gTGljZW5zZSwgVmVyc2lv

[ skipped for clarity ]

Index: resource/schema/02-config.ldif
MIME: application/octet-stream; encoding: Base64; length: 127812
IyBDRERMIEhFQURFUiBTVEFSVAojCiMgVGhlIGNvbnRlbnRzIG9mIHRoaXMg
ZmlsZSBhcmUgc3ViamVjdCB0byB0aGUgdGVybXMgb2YgdGhlCiMgQ29tbW9u
IERldmVsb3BtZW50IGFuZCBEaXN0cmlidXRpb24gTGljZW5zZSwgVmVyc2lv

[ skipped for clarity ]

then goes the rest of the diff in normal shape and form ie some java files, xml files etc.

i been trying to work around this glitch by making .ldif files recognized as some standard
file type within NB. there is however seems to be no option to define new file type within
NB anymore or at least i couldnt find it. even if i did i'm not so sure it would have
helped with this issue anyway as it seems to be some handler or module encoding such files
on the fly only when exporting.

it is not a diff module fault per se as it doesnt really matter if i use NB internal or
specify external diff utility. it happens only when exporting diff patch otherwise diff
works fine on these .ldif files and treats them as plain ascii text.
Comment 1 Maros Sandor 2008-01-25 13:01:33 UTC
SvnUtils.getMimeType(file) returns fileObject.getMIMEType() for files that does not contain svn:mime-type property. In
case of .ldif file fileObject.getMIMEType() returns null and this logic fails. I think we should not rely too much on
foleObject mime types.
Comment 2 Tomas Stupka 2008-07-21 16:47:40 UTC
fixed in scope of d3c0a9acb947