howdy.
As you've all been forced to be aware, i have a subversion repo with all of my personal textmate stuff in it. I love the new way that bundles get textmate specific names. I love how you can get a nice clean version of something by dragging it to the finder. I love being able to use almost any character you can think of in bundle item names. BUT! Using crazy characters in the names can potentially upset subversion. and since my svn server runs on a linux box, it can get even more upset when i try to do a checkout there.
SO
Can we change the way it makes the actual file system file names to not use crazy characters even though they are in the names of bundle items themselves?
I've been doing it manually for now. I could write a script or something to do it, but i'm lazy (aka busy). Personally, i think it should be the default behavior, but it could just as easily be done as a command.
Has anyone else had a problem with this?
thomas Aylott—subtleGradient
On 7/6/2006, at 13:38, thomas Aylott wrote:
Using crazy characters in the names can potentially upset subversion.
It can? This is with LC_CTYPE set correctly? How does the problems manifest themselves?
We do use crazy glyphs in the default bundle items.
and since my svn server runs on a linux box, it can get even more upset when i try to do a checkout there.
hmm… I do not know what the de facto encoding for Linux file systems are. I could imagine that there is still a lot of stuff stuck with latin-1 or just “8 bit clean, but let’s show it as ASCII.”
SO
Can we change the way it makes the actual file system file names to not use crazy characters even though they are in the names of bundle items themselves?
I actually did consider to do ASCII transliteration, because of all those who do a svn checkout w/o reading all the steps first ;) but then I also think that it’s a shame to cater to the common denominator, when Apple actually made our file system work with all unicode code points!
Personally, i think it should be the default behavior, but it could just as easily be done as a command.
I could maybe do it as a hidden option -- no sane Mac system should give a problem with this.
On Jun 7, 2006, at 4:27 PM, Allan Odgaard wrote:
On 7/6/2006, at 13:38, thomas Aylott wrote:
Using crazy characters in the names can potentially upset subversion.
It can? This is with LC_CTYPE set correctly? How does the problems manifest themselves? We do use crazy glyphs in the default bundle items.
The only problem i've noticed with svn is the tab character. I've been naming a lot of stuff with tabs to line everything up nicely.
and since my svn server runs on a linux box, it can get even more upset when i try to do a checkout there.
hmm… I do not know what the de facto encoding for Linux file systems are. I could imagine that there is still a lot of stuff stuck with latin-1 or just “8 bit clean, but let’s show it as ASCII.”
I use dreamhost. I'm not sure how they configure everything. I wanted to add a subversion hook to do a checkout and then tar everything on commit. I'm a fan of the ellipsis (…)
SO Can we change the way it makes the actual file system file names to not use crazy characters even though they are in the names of bundle items themselves?
I actually did consider to do ASCII transliteration, because of all those who do a svn checkout w/o reading all the steps first ;) but then I also think that it’s a shame to cater to the common denominator, when Apple actually made our file system work with all unicode code points!
Personally, i think it should be the default behavior, but it could just as easily be done as a command.
I could maybe do it as a hidden option -- no sane Mac system should give a problem with this.
Works for me ;)
thomas Aylott—subtleGradient
On 7/6/2006, at 22:37, thomas Aylott wrote:
[...] The only problem i've noticed with svn is the tab character. I've been naming a lot of stuff with tabs to line everything up nicely.
And tab actually is ASCII, so my proposed transliteration wouldn’t have removed that -- none of the default items have a tab in the filename, so I can’t use our repository as an example of it working.
But having a problem with tab is rather suspicious, as tab is not a crazy glyph, it is ASCII character 9, which every file system should support.
How does the problem manifest itself?
On Jun 7, 2006, at 4:58 PM, Allan Odgaard wrote:
On 7/6/2006, at 22:37, thomas Aylott wrote:
[...] The only problem i've noticed with svn is the tab character. I've been naming a lot of stuff with tabs to line everything up nicely.
And tab actually is ASCII, so my proposed transliteration wouldn’t have removed that -- none of the default items have a tab in the filename, so I can’t use our repository as an example of it working.
But having a problem with tab is rather suspicious, as tab is not a crazy glyph, it is ASCII character 9, which every file system should support.
How does the problem manifest itself?
I get: svn: Invalid control character '0x09' in path 'Snippets/ untitled with tab.tmSnippet'
That's just when trying to add it to the repo. Subversion command-line client, version 1.3.0. Mac OS X 10.4.6 Internal HD HFS+ Svn repo stored on dreamhost i686 GNU/Linux
thomas Aylott—subtleGradient
On 8/6/2006, at 19:47, thomas Aylott wrote:
I get: svn: Invalid control character '0x09' in path 'Snippets/ untitled with tab.tmSnippet'
For me:
% touch $'test\ttab.txt' % svn add $'test\ttab.txt' A test tab.txt
I.e. works fine.
That's just when trying to add it to the repo. Subversion command-line client, version 1.3.0. Mac OS X 10.4.6 Internal HD HFS+ Svn repo stored on dreamhost i686 GNU/Linux
I believe I am running subversion 1.3.1, this is from DarwinPorts. I also use 10.4.6 and HFS+. If your failure happens while adding the file, the off-site storage shouldn’t matter.
On Jun 11, 2006, at 9:27 AM, Allan Odgaard wrote:
On 8/6/2006, at 19:47, thomas Aylott wrote:
I get: svn: Invalid control character '0x09' in path 'Snippets/ untitled with tab.tmSnippet'
For me:
% touch $'test\ttab.txt' % svn add $'test\ttab.txt' A test tab.txt
I.e. works fine.
I'm happy for you. But that still doesn't help me. If 1.3.1 fixes it then that's great, but it doesn't help me share this stuff. People aren't go to bother upping to the latest point point release just to use by bundles.
That's just when trying to add it to the repo. Subversion command-line client, version 1.3.0. Mac OS X 10.4.6 Internal HD HFS+ Svn repo stored on dreamhost i686 GNU/Linux
I believe I am running subversion 1.3.1, this is from DarwinPorts. I also use 10.4.6 and HFS+. If your failure happens while adding the file, the off-site storage shouldn’t matter.
When trying to checkout to my dreamhost server, i get: svn: Can't recode string It doesn't give the specific file that it has a problem with , but if i remove the crazy unicode characters in the names around where it stopped, it's good to go.
I still think it would be best to save the file names to be compatible with lowest common denominator. It doesn't even matter what the file names are since the real full name is stored in the thing itself.
thomas Aylott—subtleGradient
On 11/6/2006, at 15:47, thomas Aylott wrote:
I.e. works fine.
I'm happy for you. But that still doesn't help me. If 1.3.1 fixes it then that's great, but it doesn't help me share this stuff. People aren't go to bother upping to the latest point point release just to use by bundles.
% ls -l `which svn` -rwxr-xr-x 2 root admin 323916 May 13 2005 /opt/local/bin/svn
So I installed this more than a year ago. Maybe it only is 1.3.0, I couldn’t find an option to make the svn executable itself give the version number.
If 1.3.1 “fixes” this, then clearly 1.3.0 had a bug, and TM shouldn’t be changed to cater to a bug in svn which was fixed more than a year ago.
But I don’t think this really is a bug, I would suspect this is something else. And as the problem is with a tab character, then it is not clear what exactly the “workaround” in TM should be, i.e. how many other ASCII characters could trigger this?
[...] When trying to checkout to my dreamhost server, i get: svn: Can't recode string
Did you set LC_CTYPE to utf-8? And is this a checkout of http:// textmate.svn.subtlegradient.com/?
I tried to checkout this to both a BSD and a Linux server, both worked w/o problems (revision 130.)
I still think it would be best to save the file names to be compatible with lowest common denominator. It doesn't even matter what the file names are since the real full name is stored in the thing itself.
But I need to know what lowest common denominator is -- that a tab character is excluded from this set, indicates that ASCII is not the lowest common denominator.
On Jun 11, 2006, at 9:58 AM, Allan Odgaard wrote:
On 11/6/2006, at 15:47, thomas Aylott wrote:
I.e. works fine.
I'm happy for you. But that still doesn't help me. If 1.3.1 fixes it then that's great, but it doesn't help me share this stuff. People aren't go to bother upping to the latest point point release just to use by bundles.
% ls -l `which svn` -rwxr-xr-x 2 root admin 323916 May 13 2005 /opt/local/bin/svn
So I installed this more than a year ago. Maybe it only is 1.3.0, I couldn’t find an option to make the svn executable itself give the version number.
If 1.3.1 “fixes” this, then clearly 1.3.0 had a bug, and TM shouldn’t be changed to cater to a bug in svn which was fixed more than a year ago.
But I don’t think this really is a bug, I would suspect this is something else. And as the problem is with a tab character, then it is not clear what exactly the “workaround” in TM should be, i.e. how many other ASCII characters could trigger this?
[...] When trying to checkout to my dreamhost server, i get: svn: Can't recode string
Did you set LC_CTYPE to utf-8? And is this a checkout of http:// textmate.svn.subtlegradient.com/?
I tried to checkout this to both a BSD and a Linux server, both worked w/o problems (revision 130.)
Setting LC_CTYPE fixed my checkout to dreamhost. Thanks! But I still have the tab character problem.
I still think it would be best to save the file names to be compatible with lowest common denominator. It doesn't even matter what the file names are since the real full name is stored in the thing itself.
But I need to know what lowest common denominator is -- that a tab character is excluded from this set, indicates that ASCII is not the lowest common denominator.
I would assume that no ascii control characters should be used in file names. http://www.evergreen.edu/biophysics/technotes/program/ascii_ctrl.htm
Regular ascii is one thing but tabs, line feeds and the Backspace character for example, might cause a problem under some circumstances, despite all being ascii characters.
I come from an old MS-DOS background, so anything other than [-_a-zA- Z0-9.] seems a strange thing to have in a file name. But that's just me i suppose.
Now that i know that the checkout problem way totally my own stupidity/laziness maybe we should just limit the use of ascii control characters in file names? Or i'll just rename them myself and shut up about it.
thomas Aylott—subtleGradient
On 12/6/2006, at 5:14, Chris Thomas wrote:
So I installed this more than a year ago. Maybe it only is 1.3.0, I couldn’t find an option to make the svn executable itself give the version number.
% svn --version svn, version 1.3.0 (r17949) ...
And that reveals I have 1.1.4 -- updating as we speak… :)
I wonder if the ASCII control character check is then a new thing.
-
Allan Odgaard -
Chris Thomas -
thomas Aylott