Re: [fossil-users] fast-export to git produces unimportable dump

2016-10-09 Thread Osamu Aoki 
On Mon, Oct 10, 2016 at 10:38:45AM +0900, Osamu Aoki wrote:
...
> commit refs/heads/test_ticket_d17d6e5b17
> mark :37455
> committer jan.nijtmans  1353531216 +
> data 82
> Just commit some weird filenames, even one with a newline in it, to
^^^
> test the code.
  ^

Now I realize.

> from :37577
> M 100644 :1050 :abc
> M 100644 :37588 abc
> def.txt

I see this should have been "abc\ndef.txt" instead of "abc", real NL
and "def.txt".

I tested "git fast-export" with filename with NL in it.

| commit refs/heads/master
| mark :4
| author Osamu Aoki  1476073435 +0900
| committer Osamu Aoki  1476073435 +0900
| data 7
| update
| from :2
| M 100644 :3 "foo\nbar.txt"

It generate file like this.  So when ever you see NL, this escaping
needs to happen and they are always double quoted (normally there are no
double quote).  Quick check indicates:

NL QUOTED "\n"
TABQUOTED "\t"
\  QUOTED "\\"
SPACE  QUOTED " "

For example
| M 100644 :8 "space space.txt"

"fossil export" and "fossil import" need to support these features.

As I read git-ls-files manpage, its OUTPUT has following content:

 When -z option is not used, TAB, LF, and backslash characters in
 pathnames are represented as \t, \n, and \\, respectively.

So at least addressing above 4 cases should do good.

  if filename_has_specials(filenamestring)
filenamestring = quote_and_escape(filenamestring);

Osamu

PS: Immediately after posing here, I got many replies from SPAM :-(
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fast-export to git produces unimportable dump

2016-10-09 Thread Osamu Aoki 
Hi,

This happens with version 1.35 I just uploaded to Debian :-)

Fast-export to git produces unimportable dump.

| fatal: Unsupported command: def.txt
| fast-import: dumping crash report to .git/fast_import_crash_11901

How to reproduce this bug.
 $ fossil clone https://www.fossil-scm.org/ fossil.fsl
  ...
 $ ls -l fossil.fsl
-rw-r--r-- 1 * * 37855232 Oct 10 08:50 fossil.fsl
 $ git init fossil
 $ cd fossil
 $ fossil export --git ../fossil.fsl | git fast-import
fatal: Unsupported command: def.txt
fast-import: dumping crash report to .git/fast_import_crash_11901
 $ cd ..
 $ fossil export --git fossil.fsl >fossil.export
 $ vim fossil.export

(Slow to start but I see following by searching "/def\.txt" at 99% point)

commit refs/heads/test_ticket_d17d6e5b17
mark :37455
committer jan.nijtmans  1353531216 +
data 82
Just commit some weird filenames, even one with a newline in it, to test the 
code.
from :37577
M 100644 :1050 :abc
M 100644 :37588 abc
def.txt
M 100644 :1050 str"i"ng.h
M 100644 :1050 str[ing.txt
M 100644 :1050 xyz<5.x

This problem can be worked around by removing offending line with vim with
minor issue:

error: Multiple updates for ref 'refs/tags/json_add_tag_test' not allowed.

Regards

Osamu

PS: This is reported as https://bugs.debian.org/840251

___
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 on HN

2016-10-09 Thread Richard Hipp 
https://news.ycombinator.com/item?id=12673229

-- 
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] Pedagogy Think Tank or Documentation Framework RFC

2016-10-09 Thread Adam Jensen 
Given the vast technical resources that are available (and becoming
available), documentation creation and refinement seems like a keystone
technology. Dedicating weeks or months to evaluate a piece of technology
is increasingly becoming a less viable practice. It's something that
I've thought about occasionally during the last year, and I recall
making plenty of notes on the subject but those notes are buried in an
~30GB pile of files with other notes. (I record my contemplative,
speculative, insightful notes in speech form in audio/mp3 files).

I've noticed that "Fossil is a distributed NoSQL database"[1].

[1]: https://www.fossil-scm.org/fossil/doc/trunk/www/theory1.wiki

And that there are "fourteen application-defined SQL functions and two
table-valued functions that are useful for managing JSON content stored
in an SQLite database"[2].

[2]: https://www.sqlite.org/json1.html

[1] is not easy to find, and [2] is not easy to understand or use. But
with this it seems like I could create annotations for the multimedia
data, stored in plain text files in JSON format. Those JSON files could
be periodically scraped and assimilated into an SQLite database and then
used to search/mine the multimedia corpus. If the JSON files are under
distributed revision control, multiple people could create/modify
annotations (this probably doesn't apply to my notes but the technique
could be applied to any media archive).

Anyway, the point is that this would be a nifty little set of scripts
utilizing Tcl/Tk-SQLite-Fossil that would be tremendously useful [to me]
and would be well within my ability to put together,,, if there were a
different quality and style of documentation/reference-material.

It's a little ironic that I don't have access to my notes on
documentation style, structure, and generation methods because the
current documentation is impeding the development of the tools I need to
search the notes. Good times.

Off the top of my head, and following Unix man page style somewhat, what
if commands were documented like this:

Relevant Definitions
Description
Example
Explanation
Rationale

Were the Example is comprehensive and provides a complete context and is
a demonstration of the 'best practices' and conventions. (A picture is
worth a thousand words, so is an example/demonstration. Let people see
it work. Give them what they need to experiment with it).

If the Example is executable with a known outcome, its execution could
be included (automated) in the Release Engineering process to determine
the points where the documentation needs to be updated so that it
maintains traction with the core software.

The other big component is community involvement, but I suspect this
post is already too long to digest.

Has anyone else thought about these issues?


___
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] Cutting fossil repository

2016-10-09 Thread Richard Hipp 
On 10/9/16, Zeev Pekar  wrote:
> I sent two examples and asked whether they were correct. A simple "yes"
> or "no" would be enough...

I don't know.  I don't remember.  In order to find out, I would either
(1) consult the documentation or (2) try the commands out to see what
happened, or (3) both.  But you can do that as easily as I can.

-- 
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] Cutting fossil repository

2016-10-09 Thread Zeev Pekar 
I sent two examples and asked whether they were correct. A simple "yes"
or "no" would be enough...

1) Is the following correct?

fossil purge artifacts 86848307235407

2) can I  delete several commits like this?

fossil purge artifacts 86848307235407 563453457234 56488921223

Thanks.


On Sat, 2016-10-08 at 18:40 -0400, Richard Hipp wrote:
> On 10/8/16, Adam Jensen  wrote:
> >
> > The reluctance of some programmer communities to provide examples has
> > always surprised me.
> 
> In this case, the documentation
> (https://www.fossil-scm.org/fossil/help?cmd=purge) consists of a
> series of examples, each followed by an explanation of what that
> example does.
> 
> I do not know how to make the documentation any clearer.
> Contributions from others who do know how to make better documentation
> will be greatly appreciated.
> 

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users