Re: [fossil-users] problem with illegal characters
On Fri, 09 Mar 2012 08:53:21 +0100
Martijn Coppoolse
li...@martijn.coppoolse.com wrote:
Why is that a bad practice? Because there's programs (like Fossil)
that won't let you work with them?
The first three hits on Google with the query using brackets in filenames
gives:
http://support.microsoft.com/kb/123577
http://social.msdn.microsoft.com/forums/en-US/sqldataaccess/thread/f0de2e77-aa54-4d60-be4f-fe95e80405f1/
http://www.vistax64.com/powershell/13575-square-brackets-file-names-unexpected-results.html
all speaking about problems on Windows.
I reckon you don't hear so much people complain about spaces in tags
because it *isn't* a more severe limitation than disallowing
(otherwise perfectly valid) characters in file names.
Don't forget that Fossi is Simple, high-reliability, distributed
software configuration management and not tool to cater all kinds of
files containing funky characters you have in your OS.
Any, there is valid reason why programmers (who use software
configuration management) and are regular users of shells, avoid those
characters where naming their source code filenames.
Even having spaces is cumbersome, since such files have to be quoted.
Programmers have been circumventing lack of spaces in identifiers for
ages, by using underscores, dashes, or by playing on capitalization.
Right.
Filenames, on the other hand, are often pre-existing, and you don't
always have the luxury of picking and choosing, since they are not
always created by you; worse, sometimes you don't even have the
possibility of imposing limitations on the characters used.
What do you mean 'pre-existing'? Software is created by you. Can you
show me some sotware project using names with such funky characters?
We've already seen that someone who wants to store OOXML files in a
'diff'-able way, will have to jump through extra hoops to get the
[Content-Types].xml file into fossil.
OOXML files are 'binaries', not diff-able and therefore not suitable for
'software configuration management'.
I also run into this issue every now and then, because someone in our
office once long ago decided to timestamp historical versions with the
time and dates between square brackets.
First of all educate people how to name files and/or then write simple
script to batch rename those files before checking them into fossil.
Our office's current VCS (PVCS/Serena ChangeMan) has no trouble at
all with [ and ], but then we routinely use the GUI interface. I
haven't used their command line interface extensively, so I don't
know how it fares then. Then again, it's on Windows, and AFAIK [ and
] have no special meaning for cmd.exe -- certainly not if you quote
the file names (which is a good idea anyway, since spaces do occur
from time to time).
Well, I do understand *you* have issues using Fossil, but those are
coming from the fact that:
1) your choise of character set used in naming the files is the one
which creates problems with the tools/applications (see the links above)
2) your filetypes (OOXML) are binaries and are supposed to be saved as
such since it's not possible to diff merge them
3) Fossil is meant for 'software configuration management' and if you
have desire to abuse it (as I do), then be ready to take into
consideration its design choices which are in accordance with its
desired functionality and/or usage.
As far as I'm concerned, having ability to select individual branches
for push/pull and having some sort of roolback to quickly repair from
accidental check-in mistakes, would bring much more to Fossil, imho.
Otoh, as Richard wrote Steve pointed out, if handling 3 lines of code
if( c=='\\' || c=='*' || c=='[' || c==']' || c=='?' ){
return 0;
}
is such a problem for you to adopt a Fossil, then I might say that you
do not have enough experience with (D)VCS in general to be able to
appreciate everything which Fossil does so superbly.
Otoh, you can try Git/Mercurial/Bazaar/Monotone if you believe that this
feature is critical for you your team.
Sincerely,
Gour
--
All living bodies subsist on food grains, which are produced
from rains. Rains are produced by performance of yajña [sacrifice],
and yajña is born of prescribed duties.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
signature.asc
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Fri, Mar 9, 2012 at 04:18, Gour g...@atmarama.net wrote: What do you mean 'pre-existing'? Software is created by you. Can you show me some sotware project using names with such funky characters? Gour, one size fits all does not work in real life. For instance, brackets, spaces, etc. are used in file names generated by certain medical imagining machines. And when you deal with medical technicians, nurses, medical students and above all physicians telling them that your software cannot handle file names with spaces is a sure bet to loose their interest. I agree that if I am naming a file, I will produce a name that is shell friendly and avoid using random characters. But I should be able, in principle, to import someone else's file which is named using different conventions. That said, I personally have no problem maintaining a separate branch where I modify fossil code to suit my needs. We've already seen that someone who wants to store OOXML files in a 'diff'-able way, will have to jump through extra hoops to get the [Content-Types].xml file into fossil. OOXML files are 'binaries', not diff-able and therefore not suitable for 'software configuration management'. You can think of OOXML as compressed tar archives. They are text XML files underneath. You can diff and merge them the same way you diff and merge regular XML or HTML files. You just store and track OOXML files in expanded form. First of all educate people how to name files and/or then write simple script to batch rename those files before checking them into fossil. Tooling and retooling should not be too intrusive. Remember, tools are here to help people not to add extra hustle to their already complex work. If your tool is a nuisance people will shun using it. Not everyone is as passionate about SCM tools as people on this list. is such a problem for you to adopt a Fossil, then I might say that you do not have enough experience with (D)VCS in general to be able to appreciate everything which Fossil does so superbly. Otoh, you can try Git/Mercurial/Bazaar/Monotone if you believe that this feature is critical for you your team. Please, keep discussion devoid of emotions. It is a technical list and we are all friends here. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
Leo, I think that you have described fairly well the situation. I am a Unix/Windows user since the Silicon Graphics time. I would never put brackets on a file name. However, I fail to understand why the SCM tool should prohibit to do so to people that think differently. Specially on Windows, where people use the command line utilities less often. Maybe add a warning when doing fossil add, and explain that they will not be able to put a link to that file in the Wiki, and that's it. To create a fossil branch with the modification is a practical idea only if you are a lonely developer or in a very controlled team. How do you say to a new developer?: Please use fossil, but not the standard one, because it has a strange limitation in character names for files. RR 2012/3/9 Leo Razoumov slonik...@gmail.com On Fri, Mar 9, 2012 at 04:18, Gour g...@atmarama.net wrote: What do you mean 'pre-existing'? Software is created by you. Can you show me some sotware project using names with such funky characters? Gour, one size fits all does not work in real life. For instance, brackets, spaces, etc. are used in file names generated by certain medical imagining machines. And when you deal with medical technicians, nurses, medical students and above all physicians telling them that your software cannot handle file names with spaces is a sure bet to loose their interest. I agree that if I am naming a file, I will produce a name that is shell friendly and avoid using random characters. But I should be able, in principle, to import someone else's file which is named using different conventions. That said, I personally have no problem maintaining a separate branch where I modify fossil code to suit my needs. We've already seen that someone who wants to store OOXML files in a 'diff'-able way, will have to jump through extra hoops to get the [Content-Types].xml file into fossil. OOXML files are 'binaries', not diff-able and therefore not suitable for 'software configuration management'. You can think of OOXML as compressed tar archives. They are text XML files underneath. You can diff and merge them the same way you diff and merge regular XML or HTML files. You just store and track OOXML files in expanded form. First of all educate people how to name files and/or then write simple script to batch rename those files before checking them into fossil. Tooling and retooling should not be too intrusive. Remember, tools are here to help people not to add extra hustle to their already complex work. If your tool is a nuisance people will shun using it. Not everyone is as passionate about SCM tools as people on this list. is such a problem for you to adopt a Fossil, then I might say that you do not have enough experience with (D)VCS in general to be able to appreciate everything which Fossil does so superbly. Otoh, you can try Git/Mercurial/Bazaar/Monotone if you believe that this feature is critical for you your team. Please, keep discussion devoid of emotions. It is a technical list and we are all friends here. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Fri, Mar 9, 2012 at 1:04 PM, Ramon Ribó ram...@compassis.com wrote: To create a fossil branch with the modification is a practical idea only if you are a lonely developer or in a very controlled team. How do you say to a new developer?: Please use fossil, but not the standard one, because it has a strange limitation in character names for files. Perhaps we could/should make the set of illegal characters a config option, defaulting to the current set? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Fri, 9 Mar 2012 06:51:14 -0500 Leo Razoumov slonik...@gmail.com wrote: one size fits all does not work in real life. I'm aware of it. For instance, brackets, spaces, etc. are used in file names generated by certain medical imagining machines. Do those 'medical' machines create text files? And when you deal with medical technicians, nurses, medical students and above all physicians telling them that your software cannot handle file names with spaces is a sure bet to loose their interest. I agree that if I am naming a file, I will produce a name that is shell friendly and avoid using random characters. But I should be able, in principle, to import someone else's file which is named using different conventions. That said, I personally have no problem maintaining a separate branch where I modify fossil code to suit my needs. OK. That's my point. Fossil is meant for specific purpose and why make it vulnerable for those using it 'according to the spec' because some users have strange needs? You can think of OOXML as compressed tar archives. They are text XML files underneath. I know about them. Just tried to save one file in LibreOffice as flat-xml (.fodt extension) so where is the problem with brackets? The file can be normally named and saved. Btw, I use Gnucash Gnumeric non-compressed files and track them with Fossil, so I know what I'm talking about. You can diff and merge them the same way you diff and merge regular XML or HTML files. You just store and track OOXML files in expanded form. Good luck. ;) Tooling and retooling should not be too intrusive. Remember, tools are here to help people not to add extra hustle to their already complex work. If your tool is a nuisance people will shun using it. Not everyone is as passionate about SCM tools as people on this list. It's not the point about being passionate about SCM tools, but the point is to use SCM tools for what they are meant! I did ask on this list how to 'abuse' Fossil and use it to track patient records in our small clinic, but I have to be aware that such usage is not in accordance with original usage of Fossil and have to adjust to the situation. Trying to use hammer (Fossil) believing that all files are nails is the problem I'm talking here, nothing else. Please, keep discussion devoid of emotions. It is a technical list and we are all friends here. What emotions? I tried to give sincere advise if people find that Fossil is not according to their needs. If you have burning need to track empty dirs, I will simply point out that Mercurial is not the tool for you. Why should Mercurial adjust to those wanting tracking empty dirs if it's against their design? Fortunately, there are enough choices, and they're even free if maintaining separate branch and three lines of code is too much. Richard's explanation: The reason such names are disallowed is because they are prone to error. Not in Fossil itself, but in other software. For example: optional external merge and diff programs that people might choose to set up. So for safety's sake , Fossil goes to the extra trouble of disallowing them. is very clear and since he is giving software for free, it's simple as take it or leave it. btw, if you look in the archives I was (amongst others) complaining a lot about Fossil not having support 'standard' wiki markup (e.g. markdown), but after putting everything on the scale, I've decided that things which Fossil provides are outweighting missing bits. Simple like that and no emotions and I'm ending this thread from my side. ;) Sincerely, Gour -- Not by merely abstaining from work can one achieve freedom from reaction, nor by renunciation alone can one attain perfection. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Fri, Mar 9, 2012 at 07:11, Stephan Beal sgb...@googlemail.com wrote: Perhaps we could/should make the set of illegal characters a config option, defaulting to the current set? This may cause problem with globing. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
Lol... coincidently i was just reading: http://www.boost.org/doc/libs/1_49_0/libs/filesystem/v3/doc/tutorial.html and their tut5.cpp example demonstrates using \u263A (a smiley face!) in filenames. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
I'm in the mood for some long winded editorializing Bob Coder is moving his development team off of AntiquatedSCM and on to one of the fancy new distributed SCMs that are all the rage. They look at git but it seems kinda complicated and one of the devs suggests Fossil. Wow, nice, simple, elegant, reliable, data storage design that looks trustworthy, solves multiple problems with one executable. Cool. But in the evaluation it comes to light that some legacy files with funky characters can't be checked in and the only two solutions are to throw away or rewrite multiple megs of test cases or to maintain a private branch of the Fossil source. Neither option is tenable and Fossil is eliminated. So Fossil loses another potential advocate due to being devoted to a philosophy of enforcing adherence to the lowest common denominator and the ever pragmatic (albeit, bloody complicated) git gains another user. Sure, it is a silly story and who cares, fossil was not written to be everything to everyone. But still, we've seen at least one real world variant of this story reported to the list A strongly worded warning makes sense but I personally think a no-alternative enforcement does not. IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. On Wed, Mar 7, 2012 at 3:16 PM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 14:30, sky5w...@gmail.com wrote: because of the hassle of re-working their multitudes of files or create/maintain Fossil branches using Richard's suggestion. If square bracket limitation is the only thing that make fossil unacceptable to you then, please, consider making your own fossil branch as Richard suggested. Actually, I found maintaining my own fossil branch quite easy. And my changes are larger and more intrusive that commenting out couple of lines of code. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
If it is just three lines of code that filter out those characters, how difficult would it be to wrap those into a configurable option, enabled by default but with an option to disable for those who really know what they're doing? best, Steve On 3/8/2012 6:22 PM, Matt Welland wrote: I'm in the mood for some long winded editorializing Bob Coder is moving his development team off of AntiquatedSCM and on to one of the fancy new distributed SCMs that are all the rage. They look at git but it seems kinda complicated and one of the devs suggests Fossil. Wow, nice, simple, elegant, reliable, data storage design that looks trustworthy, solves multiple problems with one executable. Cool. But in the evaluation it comes to light that some legacy files with funky characters can't be checked in and the only two solutions are to throw away or rewrite multiple megs of test cases or to maintain a private branch of the Fossil source. Neither option is tenable and Fossil is eliminated. So Fossil loses another potential advocate due to being devoted to a philosophy of enforcing adherence to the lowest common denominator and the ever pragmatic (albeit, bloody complicated) git gains another user. Sure, it is a silly story and who cares, fossil was not written to be everything to everyone. But still, we've seen at least one real world variant of this story reported to the list A strongly worded warning makes sense but I personally think a no-alternative enforcement does not. IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. On Wed, Mar 7, 2012 at 3:16 PM, Leo Razoumov slonik...@gmail.com mailto:slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 14:30, sky5w...@gmail.com mailto:sky5w...@gmail.com wrote: because of the hassle of re-working their multitudes of files or create/maintain Fossil branches using Richard's suggestion. If square bracket limitation is the only thing that make fossil unacceptable to you then, please, consider making your own fossil branch as Richard suggested. Actually, I found maintaining my own fossil branch quite easy. And my changes are larger and more intrusive that commenting out couple of lines of code. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org mailto:fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On 09/03/2012, at 8:22 AM, Matt Welland wrote: I'm in the mood for some long winded editorializing Bob Coder is moving his development team off of AntiquatedSCM and on to one of the fancy new distributed SCMs that are all the rage. They look at git but it seems kinda complicated and one of the devs suggests Fossil. Wow, nice, simple, elegant, reliable, data storage design that looks trustworthy, solves multiple problems with one executable. Cool. But in the evaluation it comes to light that some legacy files with funky characters can't be checked in and the only two solutions are to throw away or rewrite multiple megs of test cases or to maintain a private branch of the Fossil source. Neither option is tenable and Fossil is eliminated. So Fossil loses another potential advocate due to being devoted to a philosophy of enforcing adherence to the lowest common denominator and the ever pragmatic (albeit, bloody complicated) git gains another user. Sure, it is a silly story and who cares, fossil was not written to be everything to everyone. But still, we've seen at least one real world variant of this story reported to the list A strongly worded warning makes sense but I personally think a no-alternative enforcement does not. IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. +1 In my experience, good software tools embody best practice out of the box, while accommodating existing non ideal practice (and leading the user gently from the latter to the former). Steve On Wed, Mar 7, 2012 at 3:16 PM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Mar 7, 2012 at 14:30, sky5w...@gmail.com wrote: because of the hassle of re-working their multitudes of files or create/maintain Fossil branches using Richard's suggestion. If square bracket limitation is the only thing that make fossil unacceptable to you then, please, consider making your own fossil branch as Richard suggested. Actually, I found maintaining my own fossil branch quite easy. And my changes are larger and more intrusive that commenting out couple of lines of code. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On 8 March 2012 03:18, Gour g...@atmarama.net wrote: I already voiced a release engineer's reluctance to pursue Fossil due to the restriction of '[]'s. I'm with computers since time of Apple's IIe and never encountered need to have filenames with '[]'s. Never worked with VMS then, I'm gathering. Or a few other such OSes. Even if such would arise, I'd try as hard as possible to find workaround instead of fiddling with strange bugs which might occur due to shell's mechanisms etc., so here I fully agree with Richard's decision. Sometimes those strange bugs are part of the actual file system and can't be worked around. -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Fri, 9 Mar 2012 12:07:18 +0800 Michael Richter ttmrich...@gmail.com wrote: Never worked with VMS then, I'm gathering. Or a few other such OSes. I did work with VMS, but didn't own VMS machine...even used punchcards with IBM 370...but, still, never encountered need for having those strange characters in filename. Sometimes those strange bugs are part of the actual file system and can't be worked around. I do have /usr/bin/[ but it's part of the OS and not meant to be kep under DVCS. Sincerely, Gour -- According to the three modes of material nature and the work associated with them, the four divisions of human society are created by Me. And although I am the creator of this system, you should know that I am yet the nondoer, being unchangeable. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Thu, 8 Mar 2012 17:22:14 -0700 Matt Welland estifo...@gmail.com wrote: IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. Fossil does work perfectly both on Unix Windows, but having those funky characters (space included) in a filenames which are meant to be kept under DVCS is *bad practice* both on Unix Windows. As I wrote earlier, not being able to have space in a tag name is much severe limitation, but I do not hear many people complain about (g)it. If Bob Coder is moving his development team off of AntiquatedSCM they should be prepare to have some migration issues with *any* DVCS they choose and we would like to hear more about that AntiquatedSCM... Sincerely, Gour -- One who is able to withdraw his senses from sense objects, as the tortoise draws its limbs within the shell, is firmly fixed in perfect consciousness. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
Matt Wellandestifo...@gmail.com wrote: IMHO a more viable philosophy is to use documentation and methodology to make seamless interoperability between Windows and Unix/Linux possible for teams that need it. Otherwise where possible and where the code cost is not too high, independently make fossil work perfectly on Unix and perfectly on Windows. Agree. Out of curiosity, is there someone that's already followed Richard's advice and created their own branch of fossil, disabling just those three lines? If so, do they often run into trouble with the mentioned files? I keep reading about potential issues if [ and ] were to be allowed, but the only *actual* issues I’m seeing are due to the fact that [ and ] are _not_ allowed. It would be nice to have that balanced by someone who's already tried it. (I may try it at some point in the future, but haven’t got too much time for it atm). Fossil does work perfectly both on Unix Windows, but having those funky characters (space included) in a filenames which are meant to be kept under DVCS is *bad practice* both on Unix Windows. Why is that a bad practice? Because there's programs (like Fossil) that won't let you work with them? As I wrote earlier, not being able to have space in a tag name is much severe limitation, but I do not hear many people complain about (g)it. I reckon you don't hear so much people complain about spaces in tags because it *isn't* a more severe limitation than disallowing (otherwise perfectly valid) characters in file names. Tags are something you add once you're using your SCM; also, you're free to decide what kind of tag you want to use. Programmers have been circumventing lack of spaces in identifiers for ages, by using underscores, dashes, or by playing on capitalization. Filenames, on the other hand, are often pre-existing, and you don't always have the luxury of picking and choosing, since they are not always created by you; worse, sometimes you don't even have the possibility of imposing limitations on the characters used. We've already seen that someone who wants to store OOXML files in a 'diff'-able way, will have to jump through extra hoops to get the [Content-Types].xml file into fossil. I also run into this issue every now and then, because someone in our office once long ago decided to timestamp historical versions with the time and dates between square brackets. Our office's current VCS (PVCS/Serena ChangeMan) has no trouble at all with [ and ], but then we routinely use the GUI interface. I haven't used their command line interface extensively, so I don't know how it fares then. Then again, it's on Windows, and AFAIK [ and ] have no special meaning for cmd.exe -- certainly not if you quote the file names (which is a good idea anyway, since spaces do occur from time to time). Yours, -- Martijn Coppoolse ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
Thank you for examples. I wish to say that I have a high regard for the work being done and my objections were and are sole for putting that work and effort to good use. In some contexts fossil might try to treat [abcdef] as a uuid or wiki page name, and would fail to do so (or, just as bad, it would succeed in surprising ways). e.g. the filename gets pasted into a wiki page or commit message. The vast majority of fossil's error cases are fatal to the app. I understand the problem and I would like to reiterate that (the problem) isn't attacked at the right level. If there are issues with wiki interaction or some other side, then the wiki parser or that part/module should receive attention. Solving things the way it is done now simply affects the general usability of the entire thing. Small flicks like no square brackets cause strong attitudes against otherwise a wonderful tool. But aside from contrived examples, experienced Unix/shell users will all (well, there's always at least one naysayer) agree that special characters in filenames eventually lead to Grief and Suffering. Even the seemingly innocuous space character is very problematic/annoying for us command-line users because the space character plays a special role in shells (it separates tokens). Thus commands like the following: find . -name '*.doc' | xargs rm -f can (depending on the circumstances) end in disaster if that command finds My Special Document.doc. Yes, there are workarounds for this (and yes, i know them ;), but the point is that we only need workarounds because GUI users don't find the space character as appalling as the much older species of Unix users, and this deviation from convention breaks a lot of conventional tools and usage patterns. Again, I understand your point (actually never been in the dark here), but is this a Fossil's problem that it has to deal with? That's actually a someone else's problem. About those conventional tools and usage patterns - tools won't crash because Fossil would be less restrictive, but because of the user's action (with or without Fossil). Those usage patterns should be respected by the users who apply them, not by being guarded by some CSM. It just doesn't make sense to impose restrictions at the CSM level. What if i, on Linux, commit a file named a:b:c and you (on WIndows, i presume) try to check it out? You can't. You are right, I can't. That's why we will address the cross-platform issues before deciding actually on taking it to cross-platform. That's our decision and freedom of choosing a consensus, not the CSM's burden. double check if added files respect the OS rules. It's redundant! But portable! Yes, but again - should the CSM hold your hand here? On the flip side, it will give you enough reasons to hate it before getting to that - how come the tool is imposing me restrictions a filenaming style? Those files under the revision control may never reach another platform to cause problems. And if problems will eventually occur, it will because the multiplatform ambition, not because something else. Nonono - as a programmer i generally write code based on a standardized doc describing _the language_ (C/C++), not the _platform_ on which the language will run. Such details like which characters are legal in filenames are _platform_ properties, and fossil aims to be as platform-independent as feasible. Thus, for this particular case, it has to restrict certain characters. It arguably errs on the side of safety, but not enough that it hinders average use-cases. What I was saying was that multiplatform thing (be it source code or anything else) should be addressed separately. Asking it at the CSM level is an awkward way to do it. Those filename restrictions don't actually make Fossil more or less multiplatform, those make it more or less usable (or at least desirable) in general. To get back to my point: a standards-conforming programmer does not have to know (and very often does not know) platform-level restrictions. I just don't agree here but anyway - it's not the CSM that is defining the cross-platform standards. It's platform themselves. If a platform is asking only numbers as filenames, it wouldn't be the CSM that has to deal with that by imposing some stupid restrictions, it has to be solved by the people involved. Or am I wrong? Will be Fossil's advancements in multi-platform support result in further and further restrictions? And a programmer actually always has to know something (and at the same time afford to [ignore]/[make abstraction of] other things). If his work is somehow related with files, he has to know them at a certain degree, too. That's why we don't use a:b:c in sourcecode filenames (among other things). If those programmers aren't aware of the filenaming restrictions on different platforms, they will soon find out. That's normal, we don't have to worry about it. (i don't know a damned thing about such limits on Mac systems, and i
Re: [fossil-users] problem with illegal characters
2012/3/7 sky5w...@gmail.com: If you are considering cross-platform issues, is it not unreasonable to add your choice of CSM's requirements? A brief wiki survey lists the older win95 VFAT restrictions include: |\?*:+[]/ I understand the effort to prevent trouble (and that's what people will usually do anyway, without being forced), but the currently adopted solution comes itself as another problem. It doesn't make sense. For your example, _if_ one of the machines involved in a project would be potentially affected due to it's file system restrictions then we will address that problem by renaming our files accordingly to fit everyone involved in that project. Why do we have to rename all the files in the world? If there are tools that don't like some characters, then we'll settle guidelines and restrictions inside our development team to avoid those. Why do we have to force them down on everybody's throat? And aside from software development, Fossil on the whole has a lot of advantages and possess a great potential for adoption far beyond the programmer's world, why does it have to be hurtful with restrictions? Does everybody has to consider the cross-platform issues in everything they do? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Tue, Mar 6, 2012 at 4:14 PM, Ștefan Fulea fulea.ste...@gmail.com wrote: I've looked at the posts related to prohibited characters and I still don't get it! The addition of files containing square brackets - why does it have to be an error? Why isn't it just a warning? If you don't understand, please see what error and warning mean (or actually what they should mean). Here's a concrete (but admittedly contrived) example: filename: my-[abcdef].foo In some contexts fossil might try to treat [abcdef] as a uuid or wiki page name, and would fail to do so (or, just as bad, it would succeed in surprising ways). e.g. the filename gets pasted into a wiki page or commit message. The vast majority of fossil's error cases are fatal to the app. But aside from contrived examples, experienced Unix/shell users will all (well, there's always at least one naysayer) agree that special characters in filenames eventually lead to Grief and Suffering. Even the seemingly innocuous space character is very problematic/annoying for us command-line users because the space character plays a special role in shells (it separates tokens). Thus commands like the following: find . -name '*.doc' | xargs rm -f can (depending on the circumstances) end in disaster if that command finds My Special Document.doc. Yes, there are workarounds for this (and yes, i know them ;), but the point is that we only need workarounds because GUI users don't find the space character as appalling as the much older species of Unix users, and this deviation from convention breaks a lot of conventional tools and usage patterns. If it may cause problems in other software, it is a problem that should be fixed there, or it should be avoided by the users that choose to use those. Why does it have to be a SCM problem? It's beyondme, really! It's not that it may break other software (which is also the case), but that it splits far away from conventional wisdom (something which we ignore at our own perils). If it's easy to proactively avoid all kinds of cans of worms by simply disallowing questionable characters in filenames (as fossil does), then it's i'm all for it. Ok, we have no slash and null-character. More, there are the OS filename restrictions, but those shouldn't be the SCM's problem since it's OS's problem to enforce them prior to SCM file addition. What if i, on Linux, commit a file named a:b:c and you (on WIndows, i presume) try to check it out? You can't. double check if added files respect the OS rules. It's redundant! But portable! Those files under the revision control may never reach another platform to cause problems. And if problems will eventually occur, it will because the multiplatform ambition, not because something else. Nonono - as a programmer i generally write code based on a standardized doc describing _the language_ (C/C++), not the _platform_ on which the language will run. Such details like which characters are legal in filenames are _platform_ properties, and fossil aims to be as platform-independent as feasible. Thus, for this particular case, it has to restrict certain characters. It arguably errs on the side of safety, but not enough that it hinders average use-cases. Having such ambitions will obviously require respecting more rules and submit to common denominator restriction. To get back to my point: a standards-conforming programmer does not have to know (and very often does not know) platform-level restrictions. (i don't know a damned thing about such limits on Mac systems, and i don't care to.) One of the joys of publishing open source is when someone writes you and says, i just built your code on Platform XYZ, and you've never even heard of Platforms XYZ before. That's portability, which is achieved largely via standards-compliance supplemented by following conventional wisdom and experience (both of oneself and others). Doing that by default means carrying unnecessary burden that hurt adoption. IMO this is a tiny limitation. As a long-time Unix user it would never occur to me to use [ or ] or ? or * in a filename - doing so is just _asking_ for trouble. So I'm ending up in the same questions - why does it have to be an blocking error and not a simple warning? Because if it is not fatal then it becomes possible to deny (possibly without the user realizing it) access to the file to users of a specific platform. if, only if, it will be the case (most likely not). For now, the entire architectural decision appears to me like trying to cure a disease by shooting the patient dead! In it's current state, Fossil is not a keeper, sorry. To each his own. i think you're reaction to this particularly small wart is a bit exaggerated, however. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] problem with illegal characters
I remember having tried to fossilize files in the Ms Office 2007 formats; the docx, xlsx, etc. formats are merely zips containing mainly XML files. The root file is called [Content-Types].xml Even if it is not sane to include such characters in file names, those characters happen to exist. On Tue, Mar 6, 2012 at 19:24, Leo Razoumov slonik...@gmail.com wrote: On Tue, Mar 6, 2012 at 10:14, Ștefan Fulea fulea.ste...@gmail.com wrote: So I'm ending up in the same questions - why does it have to be an blocking error and not a simple warning? The problem that makes sense reporting as an error might be at information retrieval, and that's if, only if, it will be the case (most likely not). For now, the entire architectural decision appears to me like trying to cure a disease by shooting the patient dead! In it's current state, Fossil is not a keeper, sorry. After giving it a second thought I am fine with avoiding [*^] characters as part of filenames for two reasons: (1) fossil glob patterns use [*^] for special purposes (2) [abc123] syntax designates an artifact's SHA1 hash prefix --Leo-- P.S. Each SCM system has its own arbitrary limitations. In GIT, for example, :~^ cannot be used in tag/branch names. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Benoit Mortgat ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] problem with illegal characters
On Wed, 7 Mar 2012 07:11:58 +0100
Benoit Mortgat mort...@gmail.com wrote:
I remember having tried to fossilize files in the Ms Office 2007
formats; the docx, xlsx, etc. formats are merely zips containing
mainly XML files.
When I need to track such files (e.g. Gnucash, Gnumeric), I save them as
uncompressed xml.
Even if it is not sane to include such characters in file names, those
characters happen to exist.
It's not, in general, sane to track binaries as regular files, those
have to be marked as binaries since there is no use of trying to
diff/merge 'em.
Sincerely,
Gour (who does not have need to use [}${łłħ]* in filenames...)
--
As a blazing fire turns firewood to ashes, O Arjuna, so does the
fire of knowledge burn to ashes all reactions to material activities.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
signature.asc
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
