[fossil-users] SVN-fs-dump-format-version: 3 will produce unusable blobs

Hello developers, I've played around with a most recent version of trunk https://www.fossil-scm.org/fossil/info/dabb08e9b31bb0b2 and I think I've found a bug in fossil's svn import feature. Um, I'm not so skilled on the command line and hope that the translation is some kind of understandable.

[fossil-users] just a bug report

Hello, here some testing result output's from tester.tcl... I'm sorry, I could find no wiki page with instructions on how to submit bug reports. Thanks for your time, Kain DL-Version: https://www.fossil-scm.org/download/fossil-w32-20150223162734.zip --8-- * Final

[fossil-users] compiling on branches svn-import* are broken

I've used a src-zip from branch svn-import_no-svn-rev HEAD (f273714ebf6400b99b225ad463293f7c174102a5) and trying to compile it with msvc 2012. The process was terminated due to syntax error's in file src\import.c. Sorry, I do not post compiler messages because the language is localized. Thank

Re: [fossil-users] compiling on branches svn-import* are broken

Many thanks to you both. Best regards, Kain Abel 2015-02-22 16:37 GMT+01:00 Jan Nijtmans jan.nijtm...@gmail.com: 2015-02-22 16:17 GMT+01:00 Martin Gagnon eme...@gmail.com: I don't know for msvc 2012, but it compile fine on MinGW. (with small warning that have to be fixed) Unfortunately

Re: [fossil-users] SVN-fs-dump-format-version: 3 will produce unusable blobs

Thanks for the investment of their time. 2015-03-23 23:06 GMT+01:00 Baruch Burstein bmburst...@gmail.com: Version 3 should be understood, too. I definitely remember testing version 3 dumps thoroughly with my fist revision of the svn import. I don't remember how thoroughly I tested it after

Re: [fossil-users] SVN-fs-dump-format-version: 3 will produce unusable blobs

...@gmail.com: 2015-03-20 16:55 GMT+01:00 Kain Abel isoru...@gmail.com: I hope someone can reproduce this behavior: Yes, I can reproduce that. See: https://svn.apache.org/repos/asf/subversion/branches/1.5.x/notes/dump-load-format.txt The conclusion is that fossil import --svn only understands version

Re: [fossil-users] About the help command

Thank you for opening this thread. I've found some other items on command line help... Here are a few things perhaps worthy to discuss: - exposing abbreviation like ci, co on default help page (the currently only listed with 'fossil help -a') to avoid unexpected results (co (checkout) vs.

Re: [fossil-users] Rejected JSON tests

Hi Ross, sorry for the late reply. My day job ate all the time. Thanks for the tip. 'apt-get install tcllib' solved the problem. Best regards and thanks, Kain 2016-05-27 22:52 GMT+02:00 Ross Berteig : > The issue here is that you don't have the json package installed in

Re: [fossil-users] Rejected JSON tests

Hi Stephan, again, I beg your pardon. My work ate all the time. I've slightly modified your line from the top: lm@um:~/src/fossil$ gcc -c -pedantic -I./src -Wall -Werror -fPIC -Wstrict-aliasing -g -Wno-long-long -std=c89 ./src/cson_amalgamation.c -DFOSSIL_ENABLE_JSON -Og lm@um:~/src/fossil$ gcc

[fossil-users] Rejected JSON tests

Dear devs, dear users, the script tester.tcl don't like the JSON support?. lm@um:/tmp$ ./fossil version -v This is fossil version 1.35 [893905c83e] 2016-05-23 01:05:08 UTC Compiled on May 27 2016 12:36:50 using gcc-5.3.1 20160413 (64-bit) SQLite 3.13.0 2016-05-18 10:57:30 fc49f556e4 Schema

[fossil-users] Detection of OpenSSL sources in the tree (--with-openssl=tree)

Hello developers, dear users, I've played around with a most recent version of trunk and the detection of the OpenSSL sources (in the tree of fossil) shows unexpected behavior for me. openssl-1.0.2*.tar.gz was unpacked to compat/openssl and I used the following options (on a Debian Jessie):

Re: [fossil-users] Detection of OpenSSL sources in the tree(--with-openssl=tree)

Thank you for your quick response. With regards, Kain ___ 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] some uglifications for diff.tcl

Hi David, Thanks for fixing and pushing it. With regards, Kain ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] unlocks the usage of: fossil diff --to foo (without --from)

Hi, it's IMHO a comfort feature in 'do what I say' style and it will allow $ fossil diff --to tip That is logical the same as: $ fossil diff --from tip --invert I think it will be useful to compare your local changes (of current checkout) against a more recent checkin. With regards, Kain In

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

HI, 2016-08-13 19:45 GMT+02:00 Richard Hipp : > But you still have not made your case for why growth of the stash id > is a bad thing. I know, it would be purely cosmetic. What is largest possible stash id on 32 bit systems? My stash ID's after testing are now $ fos pool

Re: [fossil-users] ambiguities and inconsistencies in --help

Hi Ross, thanks for your reply. 2016-08-13 0:12 GMT+02:00 Ross Berteig : > For fun, you can try feeding things to the test-date-format command: > > $ fossil test-date-format now > now -> 2016-08-12T21:51:51.775 > > $ fossil test-date-format "2016-08-01 09:00:00-07:00" #

[fossil-users] Fix for stash-next pointer

Dear developers, after $ fossil stash pop or $ fossil stash rm is the pointer for the next stash id (stash-next in table vvar) untouched. Here a tiny patch hopefully without side effects. With regards, Kain stash-next_fix.patch Description: Binary data

Re: [fossil-users] Fix for stash-next pointer

Hi, 2016-08-13 16:38 GMT+02:00 Richard Hipp : > > And thus each new stash has a unique id. Is that a problem? not really, but the id is growing up. Uh, my patch doesn't work, when the last stash will be dropped. if( stashid==0 ) fossil_fatal("empty stash"); in line 401 will

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

The next try: another version. (Prevents the growth from stash id after many push and pop operations.) Just for the sake of completeness, Kain stash-next_fix_fix.patch Description: Binary data ___ fossil-users mailing list

[fossil-users] ambiguities and inconsistencies in --help

Dear developers, dear contributors, dear users, I've found some gaps and inconsistencies in the documentation on command line. I am not a native speaker and programmer. Thus, unfortunately, I can't contribute to a better documentation. But some nuances obstructs IMHO the painless usage of

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

Hi Warren, 2016-08-17 17:43 GMT+02:00 Warren Young <w...@etr-usa.com>: > On Aug 16, 2016, at 6:45 AM, Kain Abel <isoru...@gmail.com> wrote: >> Oh, that surprises me now. This implicit behavior is not explicit >> documented. There is no warning that all stashed changes w

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

Just a crude thought: I know, fossil is not git ... but both was designed to preserve informations and to track their changes. (That is a absolute simplification.) Git has no open and close, but also stash. A former ;) git user would lose the stash without asking if he uses close (out of

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

Dear Stephan, 2016-08-18 9:12 GMT+02:00 Stephan Beal: > i'm guessing that few people ever use 'close'? (i have never - in over 8 > years - used it except when testing fossil.) In my case very rarely and often with 'close --force' and 'open -keep'. With regards, Kain

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

2016-08-18 9:12 GMT+02:00 Stephan Beal <sgb...@googlemail.com>: > On Thu, Aug 18, 2016 at 1:21 AM, Kain Abel <isoru...@gmail.com> wrote: >> >> Git has no open and close, but also stash. > > > git combines clone/open into a single operation, and each clone is t

Re: [fossil-users] Fix for stash-next pointer (fix for the fix)

Hi Warren, 2016-08-15 17:58 GMT+02:00 Warren Young : > > [...] All stashes go away when you close the repo. Oh, that surprises me now. This implicit behavior is not explicit documented. There is no warning that all stashed changes will be also dropped when repository will be

Re: [fossil-users] How to import a few commits from a git mirror?

Dear Natacha, 2016-08-27 18:46 GMT+02:00 Natacha Porté: > Short version: I have a git repository built a mirror of a main > repository, a few changes happened to the git repository, and I would > like to find a way to bring these changes back to the fossil repository > so that the git repository

[fossil-users] fossil rebuild on new version(s)?

of 'academic' question, but it's a missing part (and hopefully not overseen) in FAQ and Quick Start Guide [in the On upgrade section]. Thank you for your attention and time, Kain Abel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http

Re: [fossil-users] fossil rebuild on new version(s)?

Thanks for the quick clarification and the useful tips. With regards, Kain ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users