Re: [fossil-users] Missing highlighted space changes in diff?
2014-03-05 7:51 GMT+01:00 Andy Bradford amb-fos...@bradfords.org: Also, clicking the button to reveal the non-whitespace change is no more ``correct'' than if Joel had instead changed ``Listening'' to ``listening'' on one of those lines. It would still show Joel as the ``author'' of that line, but really he simply made a minor modification to it while drh was the original author. Should Fossil be concerned about authors of bytes in annotate/blame? Sorry, I respectfully disagree. Changing Listening to listening is a real change inside the string, indentation (sol-whitespace) and eol-whitespace (such as \r preceding \n) is generally considered irrelevant for annotation, because it is before/after the 'actual' line. In-between spacing, that's a different issue: Git's blame command has a -w option for that purpose which is much different from what you are proposing). Actually, the -w option added to the diff commands/pages is not 100% equal to git's -w option either: In git it means --ignore-all-space, which is more forgiving than the sum of -ignore-space-at-sol and --ignore-space-at-eol. Fossil could be extended to handle the --ignore-all-space and --ignore-space-change options too, but I don't think anyone would note the difference. I consider this out-of-scope for the diff-eolws branch (which should have been named diff-solws-and-eolws..) I think the diff-eolws is good to be merged to trunk (the annotation indenting bug is fixed now), but I wait for Joel (and possible other people interested)'s judgement. Happy testing! Regards, Jan Nijtmans ___ 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] Missing highlighted space changes in diff?
On Wed, Mar 5, 2014 at 10:08 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014-03-05 7:51 GMT+01:00 Andy Bradford amb-fos...@bradfords.org: Also, clicking the button to reveal the non-whitespace change is no more ``correct'' than if Joel had instead changed ``Listening'' to ``listening'' on one of those lines. It would still show Joel as the ``author'' of that line, but really he simply made a minor modification to it while drh was the original author. Should Fossil be concerned about authors of bytes in annotate/blame? Sorry, I respectfully disagree. Changing Listening to listening is By removing the if, Joel changed the semantics (not only the indentation) of the code. i would argue that he is indeed the one who should be blamed in that case. -- - 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] Missing highlighted space changes in diff?
2014-03-05 12:39 GMT+01:00 Stephan Beal sgb...@googlemail.com: On Wed, Mar 5, 2014 at 10:08 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014-03-05 7:51 GMT+01:00 Andy Bradford amb-fos...@bradfords.org: Also, clicking the button to reveal the non-whitespace change is no more ``correct'' than if Joel had instead changed ``Listening'' to ``listening'' on one of those lines. It would still show Joel as the ``author'' of that line, but really he simply made a minor modification to it while drh was the original author. Should Fossil be concerned about authors of bytes in annotate/blame? Sorry, I respectfully disagree. Changing Listening to listening is By removing the if, Joel changed the semantics (not only the indentation) of the code. i would argue that he is indeed the one who should be blamed in that case. I can see both arguments very well. What's a pity is that the diff-eolws branch started with diff behavior correction. Annotation uses the diff logic, but I would like to keep this separate from the work that has been done on this branch. Therefore I reverted the diff-eolws branch diffFlags to what they are in trunk now: DIFF_IGNORE_EOLWS. Question to anyone interested: What should be the diffFlags used for blame/annotate 1) DIFF_IGNORE_EOLWS (the current behavior, ignoring all end-of-line spacing) 2) DIFF_IGNORE_SOLWS|DIFF_IGNORE_EOLWS (my preference, ignoring all start-of-line and end-of-line spacing) 3) 0: Any difference in spacing is considered different 4) Any other flag, to-be-implemented. Thanks for all reactions! Regards, Jan Nijtmans ___ 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] Missing highlighted space changes in diff?
Le 2014-03-05 04:08, Jan Nijtmans a écrit :
2014-03-05 7:51 GMT+01:00 Andy Bradford amb-fos...@bradfords.org:
Also, clicking the button to reveal the non-whitespace change
is no more ``correct'' than if Joel had instead changed ``Listening'' to
``listening'' on one of those lines. It would still show Joel as the
``author'' of that line, but really he simply made a minor modification
to it while drh was the original author. Should Fossil be concerned
about authors of bytes in annotate/blame?
Sorry, I respectfully disagree. Changing Listening to listening is
a real change inside the string, indentation (sol-whitespace) and
eol-whitespace (such as \r preceding \n) is generally considered
irrelevant for annotation, because it is before/after the 'actual' line.
In-between spacing, that's a different issue: Git's blame command
has a -w option for that purpose which
is much different from what you are proposing).
May be I'm a bit pedantic on those kind of thing, but I really think a
diff and blame should show all the diff by default.
I like to keep the code clean, with uniform line ending and no extra
space at the end of lines etc... Per example, on the fossil project
itself, there's a style guideline: 2 spaces indentation, no tabs, unix
line ending etc... If someone commit and all indentation become 4
spaces, I want to know right away and blame/annotate page should
consider it like a change.
Sometimes space at the end of the line can break the code and generate
compilation error.
Example: multi-lines macros in C.
#define MY_MACRO(a, b) do { \
int var=0; \
if ( .. ) { \
...;\
} \
while(0)
Or when using EOT markers on shell script, I want to know if It's gonna
produce extra space on the output or if there's an extra space before the
EOT marker (which break the script)
cat EOT
some text
on multiple lines
EOT
[snip]
In those 2 cases, it's not only esthetics's changes, so how fossil can
make the difference without re-implementing all language parser of the
world ?
Regards,
--
Martin G.
___
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] Missing highlighted space changes in diff?
On 2014-03-05 6:39, Stephan Beal wrote: By removing the if, Joel changed the semantics (not only the indentation) of the code. i would argue that he is indeed the one who should be blamed in that case. In Python, changing that indentation does indeed change the semantics. It changes which block contains the line. -- Thanks, DougF (KG4LMZ) ___ 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] Missing highlighted space changes in diff?
Thus said Jan Nijtmans on Wed, 05 Mar 2014 10:08:00 +0100: Sorry, I respectfully disagree. Changing Listening to listening is a real change inside the string, indentation (sol-whitespace) and eol-whitespace (such as \r preceding \n) is generally considered irrelevant for annotation, because it is before/after the 'actual' line. With respect to what Fossil blame/annotate should be concerned about, I don't see any difference. Blame/annotate show a list of checkins that affect a given artifact and hiding some checkins because they have particular data in them seems antithetical to change tracking software. I agree that \r and \n are genrally considered irrelevant for compilers, and other tools that might interpret those files, but should a tool that is designed to track changes ignore some changes by default? Certainly, some people might prefer to not see those changes, which is why I think it's a good idea to have the ``ignore'' options. In-between spacing, that's a different issue: Git's blame command has a -w option for that purpose which is much different from what you are proposing). I don't think Fossil needs to have feature parity with Git. :-) I started using Fossil because I couldn't stand the way Git does some things. I think the diff-eolws is good to be merged to trunk (the annotation indenting bug is fixed now), but I wait for Joel (and possible other people interested)'s judgement. Thank you for the work on this. It certainly turned out more than I originally envisioned when I first saw the difference in behavior between diff --tk and the UI. Cheers, Andy -- TAI64 timestamp: 400053174696 ___ 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] Missing highlighted space changes in diff?
On Wed, Mar 5, 2014 at 4:44 PM, Andy Bradford amb-fos...@bradfords.orgwrote: With respect to what Fossil blame/annotate should be concerned about, I don't see any difference. Blame/annotate show a list of checkins that ...is designed to track changes ignore some changes by default? Certainly, some people might prefer to not see those changes, which is why I think it's a good idea to have the ``ignore'' options. +1 on all points (except that i'm ambivalent about the ignore globs). In-between spacing, that's a different issue: Git's blame command has a -w option for that purpose which is much different from what you are proposing). I don't think Fossil needs to have feature parity with Git. :-) +1 I started using Fossil because I couldn't stand the way Git does some things. i used fossil before git and simply don't get along with git - we always fight like cats and dogs. git makes me feel really dumb, and i don't like that ;). -- - 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] Missing highlighted space changes in diff?
Jan Nijtmans wrote: Therefore I reverted the diff-eolws branch diffFlags to what they are in trunk now: DIFF_IGNORE_EOLWS. Sounds good. Let's get this bug-fix-turned-feature branch into trunk! :) Question to anyone interested: What should be the diffFlags used for blame/annotate 1) DIFF_IGNORE_EOLWS (the current behavior, ignoring all end-of-line spacing) 2) DIFF_IGNORE_SOLWS|DIFF_IGNORE_EOLWS (my preference, ignoring all start-of-line and end-of-line spacing) 3) 0: Any difference in spacing is considered different 4) Any other flag, to-be-implemented. My personal preference is for (1), as EOL whitespace is practically never worth caring about in any way (although, as Martin pointed out, that isn't always the case). I'd also guess that it makes blame/annotate more useful for the majority of users than (3), but maybe I'm wrong on that. I wouldn't argue against (3) as the default, though. ___ 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] Missing highlighted space changes in diff?
On Wed, Mar 5, 2014 at 8:37 PM, Joel Bruick j...@joelface.com wrote: Jan Nijtmans wrote: Question to anyone interested: What should be the diffFlags used for blame/annotate My personal preference is for (1), as EOL whitespace is practically never worth caring about in any way (although, as Martin pointed out, that isn't always the case). I'd also guess that it makes blame/annotate more useful for the majority of users than (3), but maybe I'm wrong on that. I wouldn't argue against (3) as the default, though. On the principal of least surprise, i've got to go with #3 (any change is-a change). i suspect that doing otherwise will lead to confusion downstream at point. -- - 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] Missing highlighted space changes in diff?
I can agree to treat space at the end of line as a difference. However, the end of line marker, be it \n or \r\n should be treated as equal. I really cannot imagine a situation where this difference can be significative. Please note that languages like C, C++ or TCL do not distinguish between these markers when reading a text file. They return exactly the same. RR 2014-03-05 21:26 GMT+01:00 Stephan Beal sgb...@googlemail.com: On Wed, Mar 5, 2014 at 8:37 PM, Joel Bruick j...@joelface.com wrote: Jan Nijtmans wrote: Question to anyone interested: What should be the diffFlags used for blame/annotate My personal preference is for (1), as EOL whitespace is practically never worth caring about in any way (although, as Martin pointed out, that isn't always the case). I'd also guess that it makes blame/annotate more useful for the majority of users than (3), but maybe I'm wrong on that. I wouldn't argue against (3) as the default, though. On the principal of least surprise, i've got to go with #3 (any change is-a change). i suspect that doing otherwise will lead to confusion downstream at point. -- - 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] Missing highlighted space changes in diff?
2014-03-05 21:26 GMT+01:00 Stephan Beal sgb...@googlemail.com: On the principal of least surprise, i've got to go with #3 (any change is-a change). i suspect that doing otherwise will lead to confusion downstream at point. Since that seems to be the mostly preferred option, that's on trunk now. (it's easy to change anyway) Happy continued testing. Regards, Jan Nijtmans ___ 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] Missing highlighted space changes in diff?
2014-03-05 22:39 GMT+01:00 Ramon Ribó ram...@compassis.com: I can agree to treat space at the end of line as a difference. However, the end of line marker, be it \n or \r\n should be treated as equal. I really cannot imagine a situation where this difference can be significative. I can: It allows to detect when people use an editor which changes all LF's to CRLF and then commit this change without realizing that that's an unnecessary burden to fossil. Much better is allowing fossil to warn for this situation and even letting fossil do the CRLF-LF conversion for you. Regards, Jan Nijtmans ___ 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] Missing highlighted space changes in diff?
2014-03-05 22:39 GMT+01:00 Ramon Ribó ram...@compassis.com: I can agree to treat space at the end of line as a difference. However, the end of line marker, be it \n or \r\n should be treated as equal. http://fossil-scm.org/index.html/info/4e6cfaf8f8 Rather easy to implement, I couldn't resist myself doing that. Making that the annotate/blame default could be option #4. Regards, Jan Nijtmans ___ 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] importing/forking from Git
On Wed, Mar 5, 2014 at 2:21 AM, Chad Perrin c...@apotheon.net wrote: I'm talking about a distributed team, where not everyone has SSH shell access or the ability to directly change anything on the filesystem, but they all have commit access to a specific set of repositories. This means, for instance, that they could clone from, and sync with, an existing repository -- but not all could create or delete entire repositories. Presumably the server admin (you?) would be the one creating new repositories on the server, so would be able to use fossil clone or fossil import either via SSH or directly on the server. I tried experimenting with the --incremental option. It appears to work for keeping a Fossil repository up to date after the initial import. I don't know if that is an intended limitation or a bug. Right now, I don't have more time to experiment with it as it is not a feature I use. ___ 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] nginx fronting fossil best practices?
I'll tinker with scgi tomorrow, but even if I get it working, I don't yet
see how scgi ensures fossil generates correct links to it's gui and
route back user url's similar to
http://somewhere.mydomain.com/partner/repo-name/...
...SNIP...
I've only used nginx once, and that was to test the SCGI code of Fossil
when I was writing it. I didn't have to do anything special, other than
setting the SCRIPT_NAME scgi_param. The links that the GUI generates are
either relative, or else they are use the HTTP_HOST scgi_param, depending
on context.
http://www.fossil-scm.org/fossil/doc/tip/www/server.wiki#scgi shows my
complete setup. It just works. Don't try to over-think it.
Here's a summary of an scgi config that rewards me with a 502 from nginx.
How do you run `fossil server` in verbose/debug mode and/or have it
log out detailed info? Any obvious config mistakes or other debugging
ideas?
$ /usr/local/sbin/fossil version
This is fossil version 1.28 [3d49f04587] 2014-01-27 17:33:44 UTC
$ nginx -v
nginx version: nginx/1.5.11
# start fossil server like so (or via `exec` in an upstart script)
$ sudo /usr/local/sbin/fossil server --scgi /srv/fossils/partner
# relevant /etc/nginx/conf.d/default.conf entry
location ~ ^/partner/ {
include scgi_params;
scgi_pass 127.0.0.1:8080;
scgi_param SCRIPT_NAME /partner;
}
# fossil repos live in this structure
# have used both `root` and `nginx` ownership; no difference wrt error
$ ll /srv/fossils
total 4
drwxr-xr-x 2 root root 4096 2014-03-02 10:05:12 partner/
$ ll /srv/fossils/partner
total 88
-rw-r--r-- 1 root root 89088 2014-03-02 10:05:12 logicalmaps.fossil
# client requests get HTTP 502 errors
curl -I http://stimpy/partner/logicalmaps/
HTTP/1.1 502 Bad Gateway
Server: nginx
Date: Thu, 06 Mar 2014 01:25:08 GMT
Content-Type: text/html
Content-Length: 537
Connection: keep-alive
ETag: 5315ce33-219
# nginx error message corresponding to HTTP 502 error to client request
$ tail -1 /var/log/nginx/errors.log
2014/03/05 20:57:43 [error] 2054#0: *1 upstream prematurely closed
connection while reading response header from upstream, client:
10.0.2.2, server: stimpy, request: GET /partner/logicalmaps/
HTTP/1.1, upstream: scgi://127.0.0.1:8080, host: stimpy
___
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] importing/forking from Git
On Wed, Mar 05, 2014 at 07:25:31PM -0500, Ron Wilson wrote: On Wed, Mar 5, 2014 at 2:21 AM, Chad Perrin c...@apotheon.net wrote: I'm talking about a distributed team, where not everyone has SSH shell access or the ability to directly change anything on the filesystem, but they all have commit access to a specific set of repositories. This means, for instance, that they could clone from, and sync with, an existing repository -- but not all could create or delete entire repositories. Presumably the server admin (you?) would be the one creating new repositories on the server, so would be able to use fossil clone or fossil import either via SSH or directly on the server. As I said in another response within this extended thread: . . . there may be a fair number of similar import/fork needs in the future, which means that it makes a lot more sense for me to figure out how to get the import into an existing repository to work -- especially because people who do not have scp access to the server at the moment may also be doing some of this work. If I just do it the way you describe, I would need to do all of this work for every instance, which is not a very reasonable state of affairs here. The result is that, yes, if it was *just me*, and/or I was willing to *do everything all the time*, it would be possible for me to do things in a *more difficult way* every time, but I'm not likely to do any of: 1. give everyone in the world the ability to make these changes on the server directly 2. screw around endlessly with ssh key configuration to limit privileges to a particular set of commands that will probably end up changing regularly so that I have to do that again, then again, and so on 3. do a bunch of extra work on top of extra work other people need to do -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Missing highlighted space changes in diff?
Thus said Jan Nijtmans on Wed, 05 Mar 2014 22:52:04 +0100: Happy continued testing. I've been testing on the diff-eolws branch and it all looks and works very nice. Thanks for fixing the button that I introduced and didn't realize it didn't honor the Show Log button. Andy -- TAI64 timestamp: 40005317f5e2 ___ 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] fossil/stunnel question
It looks like the relevant portion of the stunnel log is: 2014.03.06 06:40:52 LOG6[18041:3073944384]: Local mode child started (PID=18055) 2014.03.06 06:40:52 LOG7[18041:3073944384]: Remote FD=1 initialized 2014.03.06 06:40:52 LOG3[18041:3073944384]: TCP_NODELAY: Socket operation on non-socket (88) 2014.03.06 06:40:52 LOG5[18041:3073944384]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket Does this mean something to someone? It's as though stunnel is trying to set a socket option on stdout or something... any help with this would be appreciated, I'm surely not the only person with this issue. Thanks, Ron On 03/05/2014 08:28 AM, Ron Aaron wrote: Actually, it's really an stunnel question. I am experimenting with using stunnel on my server for fossil access (I currently use Apache+SSL). If the stunnel is configured to run in foreground, everything is fine; but if not, it fails with a read error. I assume this is a technical problem I can fix in the stunnel.conf, but so far I haven't had success. Any suggestions? Thanks, Ron ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- For confidential messages, please use my GnuPG key http://ronware.org/gpg_key.html ___ 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] Missing highlighted space changes in diff?
2014-03-06 5:12 GMT+01:00 Andy Bradford amb-fos...@bradfords.org: Thus said Jan Nijtmans on Wed, 05 Mar 2014 22:52:04 +0100: Happy continued testing. I've been testing on the diff-eolws branch and it all looks and works very nice. Well, it was your idea adding this button! I'm +1 for merging this to trunk (leaving you the honor, so blame/annotate will show the right info). I tested it too, and it indeed works fine. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
