Re: [fossil-users] painful merge
On Aug 11, 2015, at 12:49 PM, arnoldemu mem...@arnoldemu.freeserve.co.uk wrote: I think the real problem is that I am used to a different merge program and I can't get along with kdiff3. As Richard says, you should let Fossil be your “merge program.” :) It is true I am using Windows and Linux. I never had a problem with line endings with fossil. It just works! Some VCSes are so dependent on line ending style that they basically break down if you don’t enforce a common style. (e.g. CVS) While it is true that Fossil’s binary diff algorithm will cope with constantly swapping line ending styles, that doesn’t mean there is no problem. All it means is that Fossil is perfectly willing to check a bunch of CR/LF diffs into the repo along with your substantive changes. The problem comes during merge, when a CR/LF style change means that every line in the file has changed, so that Fossil can’t safely merge automatically. I don’t know what Fossil’s rule for “safe” is, but Subversion’s is that two nearby changes have to be separated by at least 3 lines before it will auto-merge. Otherwise, it considers the changes potentially overlapping, and makes the human do the merge. When a file changes in line ending style, every line has a diff, which makes automatic merges impossible. On perforce, at work, when I get latest it automatically converts line endings, Someone asks for that feature every several months, but the request has always been rejected so far, since there are logical counterarguments against auto-conversion. This isn’t so much about Fossil as about general design principles: https://en.wikipedia.org/wiki/DWIM https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Autocorrection#Disadvantages Search the list archives if you want to read the arguments specific to Fossil. Me, I can go either way on the issue. Both sets of arguments are sensible, and both have disadvantages. It isn’t a choice between right and wrong, it’s a choice of which bag of problems you want. I use scite to edit my code on Linux and Microsoft Developer Studio 2013 (Community edition) on Windows. scite doesn't care about line endings. Some testing here with VS 2013 Professional says it will preserve existing line ending styles. The docs agree: https://msdn.microsoft.com/en-us/library/dd409797(v=vs.120).aspx Beware the warning on that page that the editor will preserve the line ending style of pasted text, potentially created mixed line endings. I have run into this in the past, which is one of several reasons I recommended running “fossil diff” before every checkin. Unless you actually need the compilers in Visual Studio, you might be better of switching from VS + SciTE to some cross-platform editor that preserves line endings. Microsoft recently came out with Visual Studio Code, which runs on OS X, Linux, and Windows: http://code.visualstudio.com/ There are other good cross-platform non-mangling programmer’s text editors: Vim, Sublime Text, Emacs... ./arngui/arnguiApp.cpp contains CR/NL line endings. Use --no-warnings or the crnl-glob setting to disable this warning. Commit anyhow (a=all/c=convert/y/N)? . I answer a for all. You shouldn’t be ignoring this warning. It is warning you about a real problem, which may either be a one-off case (e.g. accidental mixed line endings) or a chronic one (e.g. line ending style inconsistent with Fossil settings.) You should either: 1. Decide that the project’s line ending style is CR+LF to cater to Visual Studio, then set the crnl-glob setting so that Fossil knows which files are text files, and thus don’t need this warning; or 2. Choose LF instead, and use text editors that don’t rewrite LF files as CR+LF, and which visually warn you about mixed line endings. (e.g. Vim, which shows colored “^M” characters when you have a file with mixed line endings.) * What is the default/server line ending? Fossil comes out of the Unix world, so when in doubt, it assumes LF. But, beware that Fossil’s diff algorithm is a binary diff, not a line-by-line diff. That means it isn’t storing the whole line when LF changes to CR+LF or vice versa, it is only storing info needed to describe the addition/removal of the CR byte. * What does convert do? Convert from native (e.g. \n on linux and \r\n on windows) to... what line ending??? To LF, regardless of platform. See line 1551 in src/checkin.c. The crnl-glob setting suppresses this, saying that “any CR” is legal in files that match the glob pattern(s) in the setting. Beware that this means it will happily accept a file with mixed line ending styles, or classic Mac (CR-only) text files. This is a strong argument in favor of choosing option 2 above, by the way. :) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] Suggestion: new TH1 command 'dir' similar to cli 'ls'
On Mon, Aug 10, 2015 at 6:05 PM, Chris ckolum...@ac-drexler.de wrote: I had the need for a very simple blog-like page within the embedded doc functionality where a th1 page (with enabled th1-doc feature) displays a list with links to all documents within a specific folder. Whenever a new file gets added to the folder the script will automatically pick it up and display a link to it. Who can complain about feature requests with patches :). In addition I added 'index.th1' to the automatically searched index files if TH1-DOC are enabled during compile time. +1 The code can be reviewed at https://server.ac-drexler.de/fossil/fossil/ci/adcc95e64d?sbs=1 Please let me know if you think that could be helpful for a wider audience and/or if you have improvement ideas. Thanks for this cool piece of software and for any feedback you might have :-) We (unfortunately) can't copy/paste it as-is without a copyright waiver on file: http://www.fossil-scm.org/index.html/doc/trunk/www/copyright-release.html but if you can get that filled out and mailed to Richard, we can integrate it. Alternately, someone who has a waiver on file might take your idea and re-implement it. Gruss aus Muenchen, -- - 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] Suggestion: new TH1 command 'dir' similar to cli 'ls'
Hi Stephan, thanks for the Feedback :-) On Tue, 11 Aug 2015 08:43:28 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, Aug 10, 2015 at 6:05 PM, Chris ckolum...@ac-drexler.de wrote: I had the need for a very simple blog-like page within the embedded [...] Who can complain about feature requests with patches :). That's what i hoped for ;-) We (unfortunately) can't copy/paste it as-is without a copyright waiver on file: Waiver is already waiting, just wanted to check with the ML before on whether the idea/code is OK. I'll send it out today. Greetings from Frankonia, Chris ___ 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] painful merge
That's a painful way to do it. Unless you have conflicts, merging should be painless. It sounds to me like you are using 'fossil gdiff' to resolve your merges manually instead of using 'fossil merge'? This was only a work around because I couldn't use meld to resolve my merge. I do always use fossil gdiff before I commit after a merge to double check the results. If I can't use meld, can anyone suggest a merge tool which shows it's differences like meld/p4merge do, and allow me to edit and works with fossil's gmerge-command as it currently stands? Thanks Kevin ___ 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] quick poll: do you generally use add/rm or mv
I would use mv. Having had bad experiences with other source control systems where you loose history with add/rm type commands, I would use mv to retain 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] painful merge
On 8/11/15, arnoldemu mem...@arnoldemu.freeserve.co.uk wrote: That's a painful way to do it. Unless you have conflicts, merging should be painless. It sounds to me like you are using 'fossil gdiff' to resolve your merges manually instead of using 'fossil merge'? This was only a work around because I couldn't use meld to resolve my merge. I do always use fossil gdiff before I commit after a merge to double check the results. If I can't use meld, can anyone suggest a merge tool which shows it's differences like meld/p4merge do, and allow me to edit and works with fossil's gmerge-command as it currently stands? Can you provide a more detailed description of your workflow? I don't really understand your problem, but I would like to. I think if you explain it in more detail I might be able to catch on. I've never used a merge tool. Usually when we do merges in Fossil or in SQLite, there are no conflicts. We just type fossil merge BRANCH and everything works. Rarely, a conflict will show up, in which case fossil just leaves marks in the source file: BEGIN MERGE CONFLICT: local copy shown first === COMMON ANCESTOR content follows === MERGED IN content follows == END MERGE CONFLICT So then I use an ordinary text editor to go in and sort out the conflict. I'm trying to understand what it is that you are doing that makes the procedure above impractical. Are you somehow getting an avalanche of merge conflicts? What's going on to make you think you need a merge tool? -- 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] AFL. Was: check-in-edit branch ready?
On 8/12/15, jungle Boogie jungleboog...@gmail.com wrote: Did anyone else have any problems instrumenting Fossil with afl like I did? I've been busy with other things and haven't tried yet. -- 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] Fossil UI: g_slice_set_config: assertion 'sys_page_size == 0' failed
Hello All, On a Linux 3.13.0-57-generic #95-Ubuntu SMP machine running fossil ui results in: (process:32380): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Trying this on a freebsd -stable machine does not result in this error. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 compile errors
Gcc likes to warn about such constructs, too. If Michai doesn't beat me to it, i will patch this when i get to work (about an hour from now). - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Aug 12, 2015 7:19 AM, jungle Boogie jungleboog...@gmail.com wrote: On 11 August 2015 at 22:16, Michai Ramakers m.ramak...@gmail.com wrote: which compiler/version? (Clang?) Yes, correct. FreeBSD clang version 3.4.1 -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] fossil compile errors
On 12 August 2015 at 07:18, jungle Boogie jungleboog...@gmail.com wrote: On 11 August 2015 at 22:16, Michai Ramakers m.ramak...@gmail.com wrote: which compiler/version? (Clang?) Yes, correct. FreeBSD clang version 3.4.1 fwiw, builds clean with 3.6.2 and 3.5.2 here (I don't have your version here). Michai ___ 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] AFL. Was: check-in-edit branch ready?
On 31 July 2015 at 17:48, jungle Boogie jungleboog...@gmail.com wrote: On 31 July 2015 at 04:16, Richard Hipp d...@sqlite.org wrote: Rebuild Fossil using the AFL tool-chain: CC=afl-gcc configure; make Then run: afl-fuzz -i in -o out -- fossil http readonly-repo.fossil Then start fixing the bugs that are reported Doing all of those steps: [-] Looks like the target binary is not instrumented! The fuzzer depends on compile-time instrumentation to isolate interesting test cases while mutating the input data. For more information, and for tips on how to instrument binaries, please see /usr/local/share/doc/afl/README. When source code is not available, you may be able to leverage QEMU mode support. Consult the README for tips on how to enable this. (It is also possible to use afl-fuzz as a traditional, dumb fuzzer. For that, you can use the -n option - but expect much worse results.) [-] PROGRAM ABORT : No instrumentation detected Location : check_binary(), afl-fuzz.c:6567 And when substituting fossil with sqlite3 (same steps applied), it starts the application. I don't have anything to test but it's at least instrumented itself and prepared for take off. Did anyone else have any problems instrumenting Fossil with afl like I did? I tried on 3.13.0-57-generic #95-Ubuntu SMP as using afl on BSD will require a bit more work to get afl working properly. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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 compile errors
On 11 August 2015 at 22:16, Michai Ramakers m.ramak...@gmail.com wrote: which compiler/version? (Clang?) Yes, correct. FreeBSD clang version 3.4.1 -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil compile errors
Hello All,
Sorry for the spam to the list tonight...
I noticed a compile warning generated while building Fossil from latest:
./src/main.c:902:18: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
while( zOption = find_option(zLong, zShort, 1) ){
^~~
./src/main.c:902:18: note: place parentheses around the assignment to
silence this warning
while( zOption = find_option(zLong, zShort, 1) ){
^
( )
./src/main.c:902:18: note: use '==' to turn this assignment into an
equality comparison
while( zOption = find_option(zLong, zShort, 1) ){
^
==
1 warning generated.
--
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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 compile errors
On 12 August 2015 at 06:32, jungle Boogie jungleboog...@gmail.com wrote:
I noticed a compile warning generated while building Fossil from latest:
./src/main.c:902:18: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
while( zOption = find_option(zLong, zShort, 1) ){
^~~
./src/main.c:902:18: note: place parentheses around the assignment to
silence this warning
while( zOption = find_option(zLong, zShort, 1) ){
^
( )
./src/main.c:902:18: note: use '==' to turn this assignment into an
equality comparison
while( zOption = find_option(zLong, zShort, 1) ){
^
==
1 warning generated.
which compiler/version? (Clang?)
Michai
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
