Re: [fossil-users] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Nico Williams n...@cryptonector.com writes: I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. You put it very nicely together!! I also want the power of SQL for history, and so on. +1 Sincerely, Gour -- Many, many births both you and I have passed. I can remember all of them, but you cannot, O subduer of the enemy! ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
Hey Nico -- Some thought-provoking comments. Thanks. -bch On 6/7/14, Gour g...@atmarama.net wrote: Nico Williams n...@cryptonector.com writes: I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. You put it very nicely together!! I also want the power of SQL for history, and so on. +1 Sincerely, Gour -- Many, many births both you and I have passed. I can remember all of them, but you cannot, O subduer of the enemy! ___ 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] Schizophrenic fossil users?
Hi, all, i just got the idea that i might want to add a separate user to one of my repos so that i can easily see which commits come from my ODroid machine (an ARM platform) as opposed to anywhere else (Intel platforms), so that i can more easily narrow down any potential portability bugs made on one or the other platform. Before i do this, though, i wanted to ask if anyone out there is using multiple Fossil users for one physical user, what their use cases are, and whether or not it's worth the effort. :-? An alternative solution would be to tag them, of course. Ah, and the commit command seems to have added a --tag feature, which would make that trivial to do, but also requires re-training years of muscle memory :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] autosync from GUI
Is it reasonable to ask that the 'autosync' setting cause artifacts created from the GUI to also be autosynced? I know this would likely increase the latency of the GUI, and would possibly create a series of error cases and/or user interactions that do not need to be handled in the GUI today. But I believe that today's behavior nevertheless violates the principle of least astonishment. ___ 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] Schizophrenic fossil users?
I just got the idea that i might want to add a separate user to one of my repos so that i can easily see which commits come from my ODroid machine (an ARM platform) as opposed to anywhere else (Intel platforms), so that i can more easily narrow down any potential portability bugs made on one or the other platform What about if each machine had its own randomly generated machine ID (from /dev/urandom, perhaps?) and this unique ID was included with each commit? Not sure where the best place to store this ID would be (somewhere in the filesystem)? Then you could run an SQL query against all the commits and use the machine ID to filter. Just a thought. ___ 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)
On Fri, Jun 6, 2014 at 10:51 PM, Nico Williams n...@cryptonector.com wrote: On Saturday, June 7, 2014, Andy Bradford amb-sendok-1404710677.ahchkeilcibgninda...@bradfords.org wrote: Thus said Nico Williams on Fri, 06 Jun 2014 18:45:13 -0500: I should add that it's not always possible or desirable to test all commits in a bundle that will be pushed together. A goal of breaking up large commits into smaller ones is to make it easier to understand and backport them, but an engineer working on a backport will have to retest anyways. This workflow certainly seems like a lot of time spent playing with the tool and less time working on code. Do Git users typically make such large commits? Why don't they just use branches to separate different lines (as in tracks) of development rather than bundling a bunch of unrelated checkins all at once? Not git users. Engineers who work on codebases with maintenance releases. For example: Solaris, Windows, ... but also a number of smaller projects, like MIT Kerberos, Heimdal, and so on. When you have a bug that needs to be fixed in older releases, you want to be able to cherry-pick it, and sometimes you don't know this until after you've integrated a fix for it in the main trunk. This is one reason that clean history is appreciated. And when investigating a bug it's also nice to be able to look back through the history and understand what was done (as opposed to how a programmer got there, which is ticket/comment fodder). (For years i worked on codebases where we used Teamware -an ancient, ancient VCS now- and we'd worked out how to implement a rebase-heavy workflow, in a team of thousands. This isn't about git. Git just happens to be the first modern VCS that made this workflow possible with little pain. If i had to use Fossil in such a workflow, I'd do the sorts of things i was used to doing with Teamware, as meantioned earlier in this thread.) The first case is easy to drop: never keep maintenance releases. Mostly that's the right thing to do, especially if in the process you can train your users to stay on the bleeding edge instead of worrying about upgrading with every critical security bugfix. But it's not always possible or easy to do this, or perhaps having older releases on maintenance is part of the vendor's business model. Either way, there's still the matter of clean, comprehensible history -- reasonable people can disagree about this, of course, and precisely because of that there are codebases where the gatekeeprs force a rebase heavy workflow on contributors. I wouldn't, don't, and won't demand that anyone follow such a workflow for any codebase I don't own, and possibly not for codebases I own either (depends). I only want to be able to do it myself easily when working on codebases where i have to or want to. I also want the power of SQL for history, and so on. So I can get this neither from Fossil nor git. Well, so be it. I won't be adding writing a VCS to my bucket list, we each have our priorities, and I wouldn't likely do a very good job of it; at most I will pursue minor extensions (or hooks) to git to get me the query power and recovery semantics I need. I think it best now for me to let this poor dead horse be. Thanks for listening and engaging me on this subject, and my apologies for taking so much of your time (especially since I love SQLite and want to do nothing to slow down your efforts there), Would not adding an incremental stash meet this need? In fact I think that an incremental stash would actually not only meet the need but be more flexible and easier to work with than the index approach because you can use update to take a snapshot and quickly and easily apply it to another branch. Having read though this thread again I really think that a way to work with stashes incrementally would be extremely useful. It might be too disruptive a change but merely making the fossil stash snapshot default to incremental would work well. Alternatively add a switch: fossil stash snapshot -inc 3 # save the changes made from snapshot 3 to now as a new snapshot Matt Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Cannot determine user when using -A
Philip Bennefall wrote: I have been experimenting with Fossil for a few days now and am really liking it so far. I am in the process of switching all my old SVN repositories to Fossil and haven't had any trouble. However, I ran into an issue when creating a new repository today. To illustrate: fossil new dummy.fossil -A philip_bennefall fossil open dummy.fossil fossil add readme.txt fossil commit Then, I get the Cannot figure out who you are! message that I've read about in the archives. So I try: fossil user default philip_bennefall I think you can use: fossil user default philip_bennefall --user philip_bennefall And I get the same message again. It says that it cannot determine user. I don't want to use my computer username for the repository, but I can only get it working if I don't pass -A to fossil new. Any hints would be appreciated. Or you should be able to simply set the environment variable: $ USER=philip_bennefall and then you don't need to worry about the -A or --user options. -- Will ___ 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] Cannot determine user when using -A
On Sat, Jun 7, 2014 at 5:18 PM, Will Parsons varro@nodomain.invalid wrote: Or you should be able to simply set the environment variable: $ USER=philip_bennefall and then you don't need to worry about the -A or --user options. That would work, but note that many programs use $USER to create strings (paths) and such, so reassigning it is generally not a good idea. However... export FOSSIL_USER=philip_bennefall should do the trick without endangering any other apps. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] autosync from GUI
On Sat, Jun 7, 2014 at 3:44 PM, Eric Rubin-Smith eas@gmail.com wrote: I know this would likely increase the latency of the GUI, and would possibly create a series of error cases and/or user interactions that do not need to be handled in the GUI today. But I believe that today's behavior nevertheless violates the principle of least astonishment. OTOH, since you've obviously thought through the long tail of problems which come with having such a feature, you are probably not surprised that Fossil does not currently have that feature ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] Cannot determine user when using -A
Stephan Beal wrote: --===0473655165== Content-Type: multipart/alternative; boundary=047d7ba972dac592b704fb40f859 --047d7ba972dac592b704fb40f859 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 5:18 PM, Will Parsons varro@nodomain.invalid wrote: Or you should be able to simply set the environment variable: $ USER=philip_bennefall and then you don't need to worry about the -A or --user options. That would work, but note that many programs use $USER to create strings (paths) and such, so reassigning it is generally not a good idea. However... export FOSSIL_USER=philip_bennefall should do the trick without endangering any other apps. I didn't know about that one. Whether reassigning USER is dangerous or not depends I think on how one works. I generally work under X and would typically call up another terminal window for my fossil session. Since doing a one-time assignment of USER is transitory (as long as one doesn't add the assignment to something like .profile or .cshrc), and is only needed for the initial repository setup, there's really no danger. (But, of course, that depends on how I work - as they say, YMMV.) -- Will ___ 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] autosync from GUI
Stephan Beal wrote: I know this would likely increase the latency of the GUI, and would possibly create a series of error cases and/or user interactions that do not need to be handled in the GUI today. But I believe that today's behavior nevertheless violates the principle of least astonishment. OTOH, since you've obviously thought through the long tail of problems which come with having such a feature, you are probably not surprised that Fossil does not currently have that feature ;). Okay :) but I don't think the tail should be *that* long. Two of Fossil's self-proclaimed major benefits are: (a) its GUI and (b) its autosync feature. That the GUI does not attempt to implement autosync at all *is* surprising. Note that in non-tiny teams, there is often a project manager type whose job includes defining ticket reports, categorizing and prioritizing tickets, editing the wiki, and so on. This type of person might exclusively use the GUI. Forcing them to go use the CLI (even after they use the GUI Admin page to choose the 'autosync' setting) feels stranger still, since they would have no reason to use the CLI otherwise. We poor geeks who would like to pitch Fossil to our project teams will encounter less resistance as the number of such surprises shrinks. Perhaps a middle ground, instead of autosync, would be to have an indicator on all (or some) of the GUI pages that a push is necessary. I believe you can detect this using just the local repo clone in most of the key circumstances. (You could take it a step further and poll the remote clone to see if it has artifacts that the local clone does not have, so that you could also report to the user that a pull is necessary. But the devs will likely find that idea distasteful?) Eric ___ 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] autocrlf like in Git?
I know about crnl-glob. But it is a completely different issue than autocrlf (like with Git). As for the hash mismatch this is just a minor technical issue easily solved. The hash would have to calculated after stripping off all CRs (Win/DOS) or converting to LFs (Macs) in text files. Then it will always match the repo hash. On the other hand, having this capability allows for better cross-platform project support. Some tools (compilers, assemblers, editors) can deal with any type of line endings so text saved in a different platform is not an issue. But, this is not a universal rule. There are many cases where those tools will misbehave on unexpected line endings. And if one decides to convert the file to their own platform, and submit, it will look as if every single line has changed even if nothing’s changed. (I’ve mentioned this problem before.) Anyway, I hope fossil wasn’t only meant to be used by fossil and sqlite but has broader aspirations, and someone will see merit in putting this in todo list. Thanks. From: Stephan Beal Sent: Saturday, June 07, 2014 1:19 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] autocrlf like in Git? On Sat, Jun 7, 2014 at 12:15 AM, to...@acm.org wrote: Does fossil support or has plans to support autocrlf (like Git)? (Text files internally saved always with Linux line endings, but extracted as Win, Linux, Mac line endings depending on the platform FOSSIL runs on) Fossil does _no_ conversion of the content because doing so would change its hash compared to the on-disk file. But see: fossil help set ... crnl-globA comma or newline-separated list of GLOB patterns for (versionable) text files in which it is ok to have CR, CR+NL or mixed line endings. Set to * to disable CR+NL checking. Without that, fossil will notice and complain about mixed-mode files. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 8:03 PM, to...@acm.org wrote: As for the hash mismatch this is just a minor technical issue easily solved. The hash would have to calculated after stripping off all CRs (Win/DOS) or converting to LFs (Macs) in text files. Then it will always match the repo hash. It's unfortunately not a minor technical issue because of how fossil calculates the hash for the whole contents of a repository for manifest-creation (and comparison) reasons (namely its Z-card and R-card constructs). The on-disk and in-db copies have to be identical or higher-level hashing calculations which know nothing about the individual files (they just see one contiguous byte stream flying by) will have different results. Anyway, I hope fossil wasn’t only meant to be used by fossil and sqlite but has broader aspirations, and someone will see merit in putting this in todo list. Someone might see merit in it, but i'm not one of them ;). The conscious decision to use mixed-mode files is of no concern to fossil - it's not an error that files have mixed line modes, but it would be a grave error for fossil to think that it should change those for you. It would _have_ to change the copy on disk for hashing to work properly, which might destroy contents loaded in your editor or some other program. Commonly, mixed-mode is considered an error (at the developer level, not the tool level), so fossil offers to warn you if you do so, but it will not take it upon itself to convert the file for you. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 2:03 PM, to...@acm.org wrote: Some tools (compilers, assemblers, editors) can deal with any type of line endings so text saved in a different platform is not an issue. But, this is not a universal rule. Really? What tool are you using where the line ending makes a difference? -- 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 2:32 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Jun 7, 2014 at 8:03 PM, to...@acm.org wrote: As for the hash mismatch this is just a minor technical issue easily solved. The hash would have to calculated after stripping off all CRs (Win/DOS) or converting to LFs (Macs) in text files. Then it will always match the repo hash. It's unfortunately not a minor technical issue because of how fossil calculates the hash for the whole contents of a repository for manifest-creation (and comparison) reasons (namely its Z-card and R-card constructs). The on-disk and in-db copies have to be identical or higher-level hashing calculations which know nothing about the individual files (they just see one contiguous byte stream flying by) will have different results. Years ago (decades ago, actually), somebody rigged up fopen() so that it did automatic NL - CRNL conversions unless you used rb or wb as the type parameter. This seemed like a clever solution at the time and was warmly embraced by many developers. However, with the passage of time, this auto-convert-by-fopen idea was found to be a misfeature. An anti-pattern. It lead to a lot of bugs, and a lot of work-around code. It sometimes converts when you do not want it to. It sometimes fails to convert when you do want it to. It is a general nuisance and pain. Automatic conversion between NL and CRNL by the version control system strikes me as exactly the same thing. It seems clever at first glance. But if your goal is to precisely control the content of your project, having the VCS subtly change things under the covers is not a desirable feature. As Stephan point out, Fossil goes to a lot of effort to record your files *exactly* as you checked them in. Making an exception for NL-CRNL changes will only lead to a proliferation of special-case code, command-line options, and configuration parameters, resulting in confusion, errors, and bugs. -- 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] Cannot determine user when using -A
On Sat, Jun 7, 2014 at 11:52 AM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Jun 7, 2014 at 5:18 PM, Will Parsons varro@nodomain.invalid wrote: Or you should be able to simply set the environment variable: $ USER=philip_bennefall and then you don't need to worry about the -A or --user options. That would work, but note that many programs use $USER to create strings (paths) and such, so reassigning it is generally not a good idea. However... export FOSSIL_USER=philip_bennefall should do the trick without endangering any other apps. Also: env USER= philip_bennefall fossil command options etc Will run fossil will that value of USER but not affect other things (unless fossil invokes them, but fossil doesn't do that) ___ 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] autosync from GUI
On Sat, Jun 7, 2014 at 1:26 PM, Eric Rubin-Smith eas@gmail.com wrote: Two of Fossil's self-proclaimed major benefits are: (a) its GUI and (b) its autosync feature. That the GUI does not attempt to implement autosync at all *is* surprising. Note that in non-tiny teams, there is often a project manager type whose job includes defining ticket reports, categorizing and prioritizing tickets, editing the wiki, and so on. This type of person might exclusively use the GUI. Forcing them to go use the CLI (even after they use the GUI Admin page to choose the 'autosync' setting) feels stranger still, since they would have no reason to use the CLI otherwise. Because my team is using Fossil without support from IT, we made the Project Manager's PC (which is under his desk) our main server. But if not for this, we would have to setup his PC to run a scheduled sync many times per day. ___ 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] autosync from GUI
On Sat, Jun 7, 2014 at 2:23 PM, Stephan Beal sgb...@googlemail.com wrote: For the local UI case, sure, i can see it being useful, but people would also expect it to work remotely, and it often wouldn't. When running the local UI, that is seen as part of the local client, but when accessing a remote server the perception is different. I think it reasonable that the server Fossil not try to autosync to another server Fossil. Granted, in a large enough project to have a hierarchy of core developers, lack of server-to-server autosync might be inconvenient, but as far as I know, large projects using git worry about this. So, I think it would be worth it to have autosync for fossil ui without also having it for the various real server modes. ___ 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] autocrlf like in Git?
Well, I can give a couple of personal examples that you easily try yourselves: * Windows side: Copy/Paste in Windows can not deal with LF endings correctly. Example: PNotepad editor in Windows loads Linux files but copy-pasting from it (for example) to other apps messes up all text (puts it all in a single line). So, you first have to convert to CR/LF and then it will work OK. For example, try (Linux mode PNotepad): Hello there copy paste to Windows built-in notepad. It ends up: Hellothere * Linux side (vi): Have you tried editing a Windows text file under vi? It shows all ^M (CRs) at the end of each line. No problem you can see use the file. You either have to global delete them, or else pretend you don’t see them and continue editing the file until you end up having a text that some lines having LFs and some CR/LFs. Looks really nice. * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. At any rate, I suppose by your response that you don’t want this. Fine, you’re the boss! I also wrongly assumed the guys who maintain Git saw a reason for having this option. I can promise you it wasn’t me who asked for it, so they must have had nothing better to do than to add a useless feature in their app that nobody ever needs. (And, I don’t use Git, by the way. I only mentioned it as a popular reference because I noticed fossil has a lot in common with Git in terms of the commands.) Thanks anyway. From: Richard Hipp Sent: Saturday, June 07, 2014 9:32 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] autocrlf like in Git? On Sat, Jun 7, 2014 at 2:03 PM, to...@acm.org wrote: Some tools (compilers, assemblers, editors) can deal with any type of line endings so text saved in a different platform is not an issue. But, this is not a universal rule. Really? What tool are you using where the line ending makes a difference? -- 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 ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 2:32 PM, Richard Hipp d...@sqlite.org wrote: Really? What tool are you using where the line ending makes a difference? At least in my software team, no, but we do share test scripts with the test engineering team and their tools do care about line endings. Our work around, since those scripts have extensions that do not conflict with our source files, is to configure our editors to convert line endings on file write. (We don't like this, but it keeps the test team from whiling at their manager (and, therefore, the director of engineering from harassing us.) ___ 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] autosync from GUI
On Jun 7, 2014 1:27 PM, Ron Wilson ronw.m...@gmail.com wrote: On Sat, Jun 7, 2014 at 2:23 PM, Stephan Beal sgb...@googlemail.com wrote: For the local UI case, sure, i can see it being useful, but people would also expect it to work remotely, and it often wouldn't. When running the local UI, that is seen as part of the local client, but when accessing a remote server the perception is different. I think it reasonable that the server Fossil not try to autosync to another server Fossil. Please forgive what may be a stupid observation, but if there are users that need ticket or wiki access (workflows that are typically ui only), might not the best approach be to give them appropriate access to the master via http (as someone already says they do indirectly by making that the master copy)? SDR ___ 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] autocrlf like in Git?
On Jun 7, 2014 1:47 PM, to...@acm.org wrote: Well, I can give a couple of personal examples that you easily try yourselves: * Windows side: Copy/Paste in Windows can not deal with LF endings correctly. Example: PNotepad editor in Windows loads Linux files but copy-pasting from it (for example) to other apps messes up all text (puts it all in a single line). Yes, though this is more a deficiency with a particular program than with Windows at large. The fact is that the convention of newline only as EOL marker is just a convention. CRLF is arguably more correct, particularly given the era in which it was established. * Linux side (vi): Have you tried editing a Windows text file under vi? It shows all ^M (CRs) at the end of each line. I have, and agree it is annoying, but that is an issue of vi choosing not to handle alien text file formats. * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? I also wrongly assumed the guys who maintain Git saw a reason for having this option. I can promise you it wasn’t me who asked for it, so they must have had nothing better to do than to add a useless feature in their app that nobody ever needs. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their opinion that it doesn't belong in a particular DVCS whose primary overriding concern is store what I tell you to store exactly as I have stored it. To me this makes sense, particularly on a platform (unixen) that is notorious (to a fault maybe?) of advocating tools do one thing and do it well. I agree that there are tools that will do the wrong thing with mixed or alien EOL markers. My bread and butter is provided primarily by Windows development, so I have to use Visual Studio extensively. It detects mixed line endings on open and offers to normalize. Perhaps an email to vi or emacs or [insert editor of choice] devs might convince them to change their tools. :) I think one of two potential solutions are possible here though: 1. Convince the devs to support hooks (which have their own issues as argued in the past), particularly pre/post commit and post update hooks. In this way tooling (such as tr or dos2unix/unix2dos) could be made to normalize line endings after changes. 2. In the absence of hooks, relatively simple shell scripts could do the exact same thing. SDR ___ 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] autocrlf like in Git?
On Jun 7, 2014 12:44 PM, Richard Hipp d...@sqlite.org wrote: Years ago (decades ago, actually), somebody rigged up fopen() so that it did automatic NL - CRNL conversions unless you used rb or wb as the type parameter. This seemed like a clever solution at the time and was warmly embraced by many developers. However, with the passage of time, this auto-convert-by-fopen idea was found to be a misfeature. An anti-pattern. It lead to a lot of bugs, and a lot of work-around code. It sometimes converts when you do not want it to. It sometimes fails to convert when you do want it to. It is a general nuisance and pain. I would disagree to this extent: misuse of this feature is a problem, and by extension ignorance of it is a problem (by which I mean those unfamiliar with it, not that you are ignorant of it). It is a platform / portability concern feature, in that if you take pure C run time library based code that uses the C platform standard of newline for EOL markers, you can recompile it without modification and get a program that does the right thing for whatever system (newline on unixen, CRLF for DOS Windows, CR only on classic Mac systems). They will generate text that can easily be consumed on the platform and will be able to consume text created by other programs that follow the platform's standard EOL convention. I don't agree that the presence of the feature is a problem. If you meant that the way it was implemented (an optional modification to a parameter to fopen) is the misfeature, then I can agree that it would have been better to do it some other way with 20/20 hindsight, but it was a reasonable solution based on existing practice and standardization efforts of the 70s 80s. SDR ___ 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] autocrlf like in Git?
From: Scott Robison Sent: Sunday, June 08, 2014 12:05 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] autocrlf like in Git? * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? What is not clear? Old assembly source may still be updated, as needed, to support existing products. But the assembler used to convert this source to binary cannot itself be updated as its source is no longer available, only the binary survives. The assembly source is written for this assembler so you’re stuck using it. For old projects that will eventually die, it's not worth the effort creating a newer (better behaving) assembler, and possibly converting all target source code to a possibly incompatible new assembler's syntax introducing a whole bunch of new problems. I also wrongly assumed the guys who maintain Git saw a reason for having this option. I can promise you it wasn’t me who asked for it, so they must have had nothing better to do than to add a useless feature in their app that nobody ever needs. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their opinion that it doesn't belong in a particular DVCS whose primary overriding concern is store what I tell you to store exactly as I have stored it. To me this makes sense, particularly on a platform (unixen) that is notorious (to a fault maybe?) of advocating tools do one thing and do it well. In general, an SCM that is supposed to be used by various people each working on a their own ‘random’ platform should be able to give to all of them the impression that text files are normal text files, that is ‘normal’ according to their own system, not to the system of the person who initiated the repo. Otherwise, repos should be marked as ‘Linux-only’, ‘Windows-only’, ‘Mac-only’, etc. and trying to open them in the wrong platform should fail with a related error message. Do we agree so far? If not, there is no need to read further. Given that all text files contain their meaningful info in the part of the file that is not the EOL marker, and the EOL marker is only there to assist the underlying OS/library to be able to correctly load/process that text file, changing those EOL at will to be compatible with the user’s current platform is not a violation of any sanctity. If the platform’s tool cannot deal with a text file in its own native format, then that tool is at fault, nobody else. But if a tool cannot deal with a text file of a different platform, we cannot blame the tool. Finally, regarding a comment in another response about the complexity of this change, as for the hash values computation, a stream can easily be wrapped inside another routine that produces a normalized stream that is then fed into the hash calculator. I really do not see the complexity. Maybe I don't have enough decades in this job yet, who knows? From: Scott Robison Sent: Sunday, June 08, 2014 12:05 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] autocrlf like in Git? On Jun 7, 2014 1:47 PM, to...@acm.org wrote: Well, I can give a couple of personal examples that you easily try yourselves: * Windows side: Copy/Paste in Windows can not deal with LF endings correctly. Example: PNotepad editor in Windows loads Linux files but copy-pasting from it (for example) to other apps messes up all text (puts it all in a single line). Yes, though this is more a deficiency with a particular program than with Windows at large. The fact is that the convention of newline only as EOL marker is just a convention. CRLF is arguably more correct, particularly given the era in which it was established. * Linux side (vi): Have you tried editing a Windows text file under vi? It shows all ^M (CRs) at the end of each line. I have, and agree it is annoying, but that is an issue of vi choosing not to handle alien text file formats. * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? I also wrongly assumed the guys who maintain Git saw a reason for having this option. I can promise you it wasn’t me who asked for it, so they must have had nothing better to do than to add a useless feature in their app that nobody ever needs. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their
Re: [fossil-users] autocrlf like in Git?
On Sat, Jun 7, 2014 at 11:40 PM, to...@acm.org wrote: In general, an SCM that is supposed to be used by various people each working on a their own ‘random’ platform should be able to give to all of them the impression that text files are normal text files, that is ‘normal’ according to their own system, not to the system of the person who initiated the repo. Otherwise, repos should be marked as ‘Linux-only’, ‘Windows-only’, ‘Mac-only’, etc. and trying to open them in the wrong platform should fail with a related error message. Do we agree so far? If not, there is no need to read further. Disagree strongly. Repos in and of themselves are platform-neutral. What you put in them is _your_ business, and fossil puts _exactly_ in what you told it to. Likewise, it pulls _exactly_ out what you put in it. It's not there to do any sort of conversions for you (be they line endings or UTFBE to UTFLE), just as it does _no_ other transformation of the content (for purposes of importing/exporting, though it internally may store the data in delta/compressed form). Given that all text files contain their meaningful info in the part of the file that is not the EOL marker, and the EOL marker is only there to assist the underlying OS/library to be able to correctly load/process that text file, changing those EOL at will to be compatible with the user’s current platform is not a violation of any sanctity. If the platform’s tool cannot deal with a text file in its own native format, then that tool is at fault, nobody else. But if a tool cannot deal with a text file of a different platform, we cannot blame the tool. i think you are confusing the definition of platform as an OS (where the line endings are defined) and development platform, where the tools need to be able to work with both, simply for portability reasons. Software developers (by and large the target audience of fossil) tend to use development tools (as opposed to notepad), the vast majority of which can handle either line-ending in some way (even if it's annoying, like ^M in emacs/vi). (Notepad++ is excellent, for example.) The CRNL convention comes from line printers and related terminals, where the separation of CR and NL made a good deal of sense. However, it is only one of two major EOL standards, and dev tools need to be able to work with both. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 3:40 PM, to...@acm.org wrote: * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? What is not clear? Old assembly source may still be updated, as needed, to support existing products. But the assembler used to convert this source to binary cannot itself be updated as its source is no longer available, only the binary survives. The assembly source is written for this assembler so you’re stuck using it. For old projects that will eventually die, it's not worth the effort creating a newer (better behaving) assembler, and possibly converting all target source code to a possibly incompatible new assembler's syntax introducing a whole bunch of new problems. AH! That is what was not clear to me, and hence why I asked. You meant the assembler's source code was no longer available to edit, when I thought you meant the assembler's output was not editable. But in this case if you have the source for the program you want to assemble, and an assembler that only understands a single EOL marker, you can modify the EOL markers of your source via tr or dos2unix/unix2dos. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their opinion that it doesn't belong in a particular DVCS whose primary overriding concern is store what I tell you to store exactly as I have stored it. To me this makes sense, particularly on a platform (unixen) that is notorious (to a fault maybe?) of advocating tools do one thing and do it well. In general, an SCM that is supposed to be used by various people each working on a their own ‘random’ platform should be able to give to all of them the impression that text files are normal text files, that is ‘normal’ according to their own system, not to the system of the person who initiated the repo. Otherwise, repos should be marked as ‘Linux-only’, ‘Windows-only’, ‘Mac-only’, etc. and trying to open them in the wrong platform should fail with a related error message. Do we agree so far? If not, there is no need to read further. Given that all text files contain their meaningful info in the part of the file that is not the EOL marker, and the EOL marker is only there to assist the underlying OS/library to be able to correctly load/process that text file, changing those EOL at will to be compatible with the user’s current platform is not a violation of any sanctity. If the platform’s tool cannot deal with a text file in its own native format, then that tool is at fault, nobody else. But if a tool cannot deal with a text file of a different platform, we cannot blame the tool. Finally, regarding a comment in another response about the complexity of this change, as for the hash values computation, a stream can easily be wrapped inside another routine that produces a normalized stream that is then fed into the hash calculator. I really do not see the complexity. Maybe I don't have enough decades in this job yet, who knows? I completely agree with the points other than the one that the DVCS is the only tool that can effectively manage the EOL convention of the files. I use a text editor daily that is capable of normalizing EOL convention (though of course there are few things capable of starting a flame war as effectively as suggesting to any random group of people that their OS or text editor is inadequate to some task). :) As long as we're talking about features we'd like to see in a swiss army knife DVCS: a lot of time is spent telling people what the coding standards are for an individual project, things that make EOL conventions seem minor (but would certainly include such things). I'm surprised no one has grafted onto git (or some other DVCS, or maybe I'm just not aware of the one that does) an ability to reformat all source code to match the standards of the project before committing it to the repository. Plenty of programs exist to reformat source code (at least for C C++), and wouldn't it be awesome if we could always check out code formatted to our own preferences and always make sure that no matter what our preferences were out commits always matched the project standards? Hey, DRH, get right on this, will ya? ;) Also, I dislike editing Ruby. I need a DVCS that will convert it to Python automatically for me and then reverse that when I commit. :) Yes, I'm being ridiculous, and I apology. It's more because I found these last two thoughts amusing (particularly the last). I can see a use for tools / hooks that can do this. I don't always agree with DRH, and admit that I liked the idea of the svn ability to convert EOL markers even though I never
Re: [fossil-users] autocrlf like in Git?
The job of an editor is to edit files. So if an editor were to make NL - CRNL conversions, I could understand that. But what if, for example, your filesystem decided to be clever and do NL - CRNL conversions of files whose names ended in .TXT as you read and wrote those files to disk. I think that a lot of people would be very distressed by that behavior and argue that the job of a filesystem is to remember what you tell it and not try to fix things for you. I think a VCS is much closer to a filesystem than to an editor. It's job is to store things and not to second-guess and try to fix up what is stored. At least that is *my* view of what a VCS should be. --- 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] autocrlf like in Git?
From: Scott Robison Sent: Sunday, June 08, 2014 12:58 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] autocrlf like in Git? I completely agree with the points other than the one that the DVCS is the only tool that can effectively manage the EOL convention of the files. I use a text editor daily that is capable of normalizing EOL convention (though of course there are few things capable of starting a flame war as effectively as suggesting to any random group of people that their OS or text editor is inadequate to some task). :) I didn’t say that (“..only tool..”). But, using tools is all about convenience. Yes, we can use Python, Lua, or whatever other scripts to do whatever work isn’t done automatically. But, this loses on convenience. I could also keep (as I did until I started using FOSSIL) all my older versions in dated RAR files, and go back to any version I want to. But, at what cost in terms of convenience? But I can also see the point to the idea that this is the file I created and this is exactly what I want to see when I pull it out of a repo that I put it into. And that’s why those things should always be optional. I never said it should be imposed on everyone just because some like it this way. But not having the option is akin to the other side imposing their ‘right’ way on everybody else.___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 4:08 PM, to...@acm.org wrote: I completely agree with the points other than the one that the DVCS is the only tool that can effectively manage the EOL convention of the files. I use a text editor daily that is capable of normalizing EOL convention (though of course there are few things capable of starting a flame war as effectively as suggesting to any random group of people that their OS or text editor is inadequate to some task). :) I didn’t say that (“..only tool..”). But, using tools is all about convenience. Yes, we can use Python, Lua, or whatever other scripts to do whatever work isn’t done automatically. But, this loses on convenience. I could also keep (as I did until I started using FOSSIL) all my older versions in dated RAR files, and go back to any version I want to. But, at what cost in terms of convenience? Fair enough. I like fossil because of the convenience of having the wiki ticket systems integrated into the single file repository. I dislike git because of the inconvenience of needing to earn a post graduate degree to understand it. ;) Again, it doesn't seem overly inconvenient to add a little scripting, but agree that it is less convenient. But I can also see the point to the idea that this is the file I created and this is exactly what I want to see when I pull it out of a repo that I put it into. And that’s why those things should always be optional. I never said it should be imposed on everyone just because some like it this way. But not having the option is akin to the other side imposing their ‘right’ way on everybody else. Flexibility is a nice thing, I agree. I suspect that's why the CRNL glob was put in, to give flexibility to people who didn't want to see warnings because their platform didn't conform to the unixen EOL standard. Or that so much effort is spent to make fossil portable between Windows and posix platforms, or why there is a built in web based GUI interface where other tools would tell you to just use the command line terminal mode. There are ideological differences between git and fossil. It's why Linus created git as he felt the existing tools were inadequate for various reasons (be they centralized in the case of svn or pricey in the case of bitkeeper). It's why DRH created fossil, who wanted immutable history vs rewritten history, among other things. All software is going to tell you there is a right way to do certain things. git vs fossil, vi vs emacs, Windows vs unixen, c++ compilers vs python interpreters. In any case, my offer still stands to help script a solution that'll give you what you need! I'm by no means a fossil expert, but I'm confident I could help with something like this if you needed it. SDR ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 1:32 PM, Stephan Beal sgb...@googlemail.com wrote: It's unfortunately not a minor technical issue because of how fossil calculates the hash for the whole contents of a repository for ... The same is true for git, and Mercurial, and... It doesn't mean it can't be done, just that the VCS has to know how to canonicalize the file's contents, and that is awful. But sometimes someone has no choice. Like OS X's HFS+, which normalizes path components to NFD. Either the user, or the VCS, have to work around such problems. In the case of HFS+ that means never using characters where NFD form and the forms produced by the users' input modes differ... or having the VCS deal. In the case of CRLF vs. LF the VCS can be told to canonicalize those for specific files. (The HFS+ NFD thing first bit git years ago, and Linux Torvals ranted about it. His rant was about ZFS, which wasn't to blame -- the aborted Apple port of ZFS to OS X changed ZFS behavior to match HFS+'s. But for that he was quite right. A filesystem that does this is intolerable, especially when the Unicode form chosen happens to not match the form output by input modes most commonly (which isn't quite NFC, but usually is, at least for all Latin scripts).) Nico ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
