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
[fossil-users] Side-by-side with checked out content
Is it possible to see a side-by-side difference between the last checkin and the currently changed file on disk? It would be a great alternative to fossil diff and fossil gdiff This would be much like the wiki preview using /doc/ckout/ -- Jos Groot Lipman ___ 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] Side-by-side with checked out content
On Fri, 9 Mar 2012 11:37:37 +0100 Jos Groot Lipman donts...@home.nl wrote: Is it possible to see a side-by-side difference between the last checkin and the currently changed file on disk? It would be a great alternative to fossil diff and fossil gdiff This would be much like the wiki preview using /doc/ckout/ Sorry for nitpicking, but I maintained an impression wiki pages are unversioned, only embedded documentation pages are and such preview of the checked out version is rather implemented for embedded documentation. ___ 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] Side-by-side with checked out content
On Fri, Mar 9, 2012 at 4:24 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Sorry for nitpicking, but I maintained an impression wiki pages are unversioned, only embedded documentation pages are and such preview of the checked out version is rather implemented for embedded documentation. Wiki pages are versioned, but with embedded docs you can get a preview of a locally-edited checked-out copy (which wiki can't do). http://www.fossil-scm.org/index.html/whistory?name=Fossil -- - 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] Side-by-side with checked out content
On Fri, Mar 9, 2012 at 10:24 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 9 Mar 2012 11:37:37 +0100 Jos Groot Lipman donts...@home.nl wrote: Is it possible to see a side-by-side difference between the last checkin and the currently changed file on disk? It would be a great alternative to fossil diff and fossil gdiff This would be much like the wiki preview using /doc/ckout/ Sorry for nitpicking, but I maintained an impression wiki pages are unversioned, Wiki pages are versioned. But each wiki page has its own DAG which is separate from the DAG used by project files and embedded documentation. It is theoretically possible to display a graph of changes to the wiki page, similar to the graphs that display on a timeline. And it is possible to have branches on a wiki page and to merge, etc. The underlying data format supports all these things, but I've never implemented them in the fossil binary, not having seen a need or demand for such features. only embedded documentation pages are and such preview of the checked out version is rather implemented for embedded documentation. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ 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] Side-by-side with checked out content
On Fri, Mar 9, 2012 at 5:05 PM, Richard Hipp d...@sqlite.org wrote: It is theoretically possible to display a graph of changes to the wiki page, similar to the graphs that display on a timeline. And it is possible to have branches on a wiki page and to merge, etc. The underlying data format supports all these things, but I've never implemented them in the fossil binary, not having seen a need or demand for such features. Just out of curiosity: what happens on a wiki page edit collision? Last one wins or is the a would fork error? -- - 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] Side-by-side with checked out content
On Fri, Mar 9, 2012 at 11:12 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Mar 9, 2012 at 5:05 PM, Richard Hipp d...@sqlite.org wrote: It is theoretically possible to display a graph of changes to the wiki page, similar to the graphs that display on a timeline. And it is possible to have branches on a wiki page and to merge, etc. The underlying data format supports all these things, but I've never implemented them in the fossil binary, not having seen a need or demand for such features. Just out of curiosity: what happens on a wiki page edit collision? Last one wins or is the a would fork error? Last change wins, is how we do it at the moment. -- - 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 -- D. Richard Hipp d...@sqlite.org ___ 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] Side-by-side with checked out content
I believe I was not clear: I am looking for a side-by-side diff for files in the 'normal' repository and their check-out counterparts, I am no interested in the wiki here. (I just mentioned the wiki as an example where Fossil presents information from files that are not yet checked in so the technology is there) -- Jos _ From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp Sent: vrijdag 9 maart 2012 17:21 To: Fossil SCM user's discussion Subject: Re: [fossil-users] Side-by-side with checked out content On Fri, Mar 9, 2012 at 11:12 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Mar 9, 2012 at 5:05 PM, Richard Hipp d...@sqlite.org wrote: It is theoretically possible to display a graph of changes to the wiki page, similar to the graphs that display on a timeline. And it is possible to have branches on a wiki page and to merge, etc. The underlying data format supports all these things, but I've never implemented them in the fossil binary, not having seen a need or demand for such features. Just out of curiosity: what happens on a wiki page edit collision? Last one wins or is the a would fork error? Last change wins, is how we do it at the moment. -- - 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 -- D. Richard Hipp d...@sqlite.org ___ 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] clearsign, so what
I'm trying to follow along here, and have a few abstract questions. If an attacker takes control over a repository, then that repository is compromised, and would need to be restored from a non-compromised back up. By compromised we mean someone deleted it, defaced it, or worse tries to hide malicious code in it. The issue is then being able to notice / discover that a given fossil project has been compromised by an unauthorized user trying to hide malicious code in something? (this is a question) The only way to ever know such a thing (from a technology point of view), would be: -to either compare the entire project.fossil file with a known good copy for changes (totally unrealistic since the project would almost always be newer than a backup file. plus how do you know one is good to archive as a known good copy) -Algorithmically verify that changes are signed by trusted users on push/pull operations. (this is also a question) So from the ideal scm features point of view, what is suppose to happen? Just verify that diffs and/or complete project versions are signed by a user? As in a property of a user being a public key? Or as in some sort of hook script check this externally before allowing a sync? If a signing key is later found to be compromised, then changes made with that signature need to be flagged for inspection? www.thomasstover.com ___ 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] clearsign, so what
On Fri, Mar 9, 2012 at 13:02, Thomas Stover c...@thomasstover.com wrote: -Algorithmically verify that changes are signed by trusted users on push/pull operations. (this is also a question) Theoretically, it is sufficient to sign a leaf manifest so that entire part of the DAG that grows out of this leaf by following the parent links becomes fortified. A manifest contains SHA1 hashes of all the files in the commit and of all its parent manifests. Assuming that intruder cannot break the signature private key and cannot forge SHA1 hash collisions we trust the commit and its parents. Then recursively we trust grand-parents and so on until we traverse a subset of the DAG connected to the initial leaf. In practice I would advocate a policy that fossil already has -- auto sign every manifest. So from the ideal scm features point of view, what is suppose to happen? Just verify that diffs and/or complete project versions are signed by a user? As in a property of a user being a public key? Or as in some sort of hook script check this externally before allowing a sync? If a signing key is later found to be compromised, then changes made with that signature need to be flagged for inspection? If signing key itself is compromised (intruder knows private key) all bets are off. Manual labor is the only remedy:-) --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
