Re: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-18 Thread Ross Berteig 


On 12/17/2015 11:45 PM, Stephan Beal wrote:

On Thu, Dec 17, 2015 at 9:28 PM, Ross Berteig > wrote:


Build fossil with JSON support, then you get access to a bunch of
features with data transported in JSON with suitable quoting. I'm
not sure why JSON is not enabled in the official distributions, it
works for me.


It's historical: Richard said, way back when, that he'd enable it if it
got full-featured testing, including fuzzy input tests (to check against
external exploits using invalid inputs). i never did that, and my
ongoing arm nerve damage (from too much/sustained typing!) is keeping me
from meaningfully contributing to any software for the foreseeable
future, so i'm not likely to ever get around to it :/. Contributions
would be welcomed!


I really should sign and mail that contributor agreement perhaps 
this is as good a reason as any. Then I can probably find some time to 
attack test cases for JSON, and maybe with you 
nagging^H^H^H^H^H^Hmentoring me it could become an official feature.


I swiftly realized that while the existing "fossil ticket" commands 
allowed for easy access to summary reports, there was no good way to get 
the full body of a ticket and its commentary out in a way that could be 
used for automating their publication. I needed that, and you added JSON 
at exactly the moment I was looking for it.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-18 Thread Stephan Beal 
i would be tickled pink to see you take that on :). i am more than happy to
help/support in any way, just can't currently commit (no pun intended) to
more than moderate amounts of typing, as my arm just can't do it. (That
doesn't rule out Skype or similar, though.)

- stephan
Sent from a mobile device, possibly from bed (a train station bench, in
this case). Please excuse brevity, typos, and top-posting.
On Dec 18, 2015 20:02, "Ross Berteig"  wrote:

>
> On 12/17/2015 11:45 PM, Stephan Beal wrote:
>
>> On Thu, Dec 17, 2015 at 9:28 PM, Ross Berteig > > wrote:
>>
>>
>> Build fossil with JSON support, then you get access to a bunch of
>> features with data transported in JSON with suitable quoting. I'm
>> not sure why JSON is not enabled in the official distributions, it
>> works for me.
>>
>>
>> It's historical: Richard said, way back when, that he'd enable it if it
>> got full-featured testing, including fuzzy input tests (to check against
>> external exploits using invalid inputs). i never did that, and my
>> ongoing arm nerve damage (from too much/sustained typing!) is keeping me
>> from meaningfully contributing to any software for the foreseeable
>> future, so i'm not likely to ever get around to it :/. Contributions
>> would be welcomed!
>>
>
> I really should sign and mail that contributor agreement perhaps this
> is as good a reason as any. Then I can probably find some time to attack
> test cases for JSON, and maybe with you nagging^H^H^H^H^H^Hmentoring me it
> could become an official feature.
>
> I swiftly realized that while the existing "fossil ticket" commands
> allowed for easy access to summary reports, there was no good way to get
> the full body of a ticket and its commentary out in a way that could be
> used for automating their publication. I needed that, and you added JSON at
> exactly the moment I was looking for it.
>
> --
> Ross Berteig   r...@cheshireeng.com
> Cheshire Engineering Corp.   http://www.CheshireEng.com/
> +1 626 303 1602
> ___
> 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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-17 Thread Ross Berteig 


On 12/16/2015 6:42 PM, Ron W wrote:


Actually, I think it's "spread sheets". In the company I work for, it's
customers and it's suppliers, when we meet with "project managers" about
the status of issues, the PMs are presenting from their spread sheets
and updating them as we disuss the issues.


As a consultant, I deal frequently with external customers who hired my 
company because they don't do (or often understand) software themselves. 
Getting them to use tickets directly is worse than herding cats.


We usually resort to spread sheets containing summary reports, often 
backed by printing the hot tickets so they can be discussed by email or 
across a table.


To make that process less painful, I built a tool that uses the optional 
JSON support to run ticket reports and present them in PDF created via 
Markdown and Pandoc. It is at Chiselapp, but I haven't touched it in a 
while.


  https://chiselapp.com/user/rberteig/repository/Ticketer/home


Fossil already has a way to "export" in a "flat file" format: "fossil
ticket show". It's basically TAB separated values. The fields shown are
driven by selecting a report that has been defined via the Fossil GUI.


There is also a built-in report number 0 which dumps all fields of all 
tickets.



Would be nice if there was a "fossil ticket export" command that would
produce a "proper" CSV file. While "proper" is still something of a
debate, most spread sheet apps (Excel, LibreCalc, GnomeCalc, etc) seem
to adequately digest CSV files where fields that contain comas or
newlines are enclosed in double quotes, with any contained double quote
escaped (I think by doubling - ie. like "has ""quote"" inside").


A problem with CSV is that there really isn't a clear definition of it 
at its edge cases other than testing what Excel will import correctly.


But it is true that the existing options supported by "fossil ticket 
show" do not even attempt to create valid CSV other than for simple 
reports where the columns are known to contain only "safe" characters.


Build fossil with JSON support, then you get access to a bunch of 
features with data transported in JSON with suitable quoting. I'm not 
sure why JSON is not enabled in the official distributions, it works for me.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/

___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-17 Thread Stephan Beal 
On Thu, Dec 17, 2015 at 9:28 PM, Ross Berteig  wrote:

>
> Build fossil with JSON support, then you get access to a bunch of features
> with data transported in JSON with suitable quoting. I'm not sure why JSON
> is not enabled in the official distributions, it works for me.


It's historical: Richard said, way back when, that he'd enable it if it got
full-featured testing, including fuzzy input tests (to check against
external exploits using invalid inputs). i never did that, and my ongoing
arm nerve damage (from too much/sustained typing!) is keeping me from
meaningfully contributing to any software for the foreseeable future, so
i'm not likely to ever get around to it :/. Contributions would be welcomed!

-- 
- 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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-17 Thread Eric Rubin-Smith 
>
> > >> Would be nice if there was a "fossil ticket export" command that would
> > >> produce a "proper" CSV file. {snip}
> > > A problem with CSV is that there really isn't a clear definition of it
> at
> > > its edge cases other than testing what Excel will import correctly.
> >
> > Which is a sorry state of things, in itself. Reading an article about
> support
> > of CSV files in PostgreSQL {snip}
>
> If you want to get files with newlines etc into Excel, your best bet is
> always the libreoffice round. Alternatively, creating Office XML might
> also be an option.{snip}


Maybe JSON is a better bet.  Fossil could support a JSON ticket dump in
some standard form.  And hey, we can reuse someone's work who has already
figured out a decent way to represent a ticket database in JSON:

https://confluence.atlassian.com/jira/importing-data-from-json-495976468.html

So if you follow that form, then you get your Jira export capability for
free. :-)

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

[fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-17 Thread Richie Adler 
Scott Robison decía, en el mensaje "Re: [fossil-users] Rewrite of
fossil-v-git.wiki. Was: Fossil mentioned on HN" del 17/12/2015 21:12:09:

> Microsoft software has been exporting and importing CSV files for multiple
> decades. The CSV "standard" is just over one decade old. There are plenty of
> reasons to object to Microsoft, but this doesn't seem like one of them, 
> really.

Please, read 1.1 at http://www.pg-versus-ms.com/ in full if you haven't done
so. I think the argument they make there is compelling.

Microsoft has also been creating operating systems for many years now. That
doesn't seem to make them particularly good at it, though. But if you think
that might makes right and that a de facto standard trumps a better designed
one, by all means, say so explicitly so I can adjust my e-mail filters
accordingly.

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

[fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-17 Thread Richie Adler 
El 17/12/2015 a las 17:28, Ross Berteig escribió:

> On 12/16/2015 6:42 PM, Ron W wrote:

>> Would be nice if there was a "fossil ticket export" command that would 
>> produce a "proper" CSV file. While "proper" is still something of a 
>> debate, most spread sheet apps (Excel, LibreCalc, GnomeCalc, etc) seem to
>> adequately digest CSV files where fields that contain comas or newlines
>> are enclosed in double quotes, with any contained double quote escaped (I
>> think by doubling - ie. like "has ""quote"" inside").
> 
> A problem with CSV is that there really isn't a clear definition of it at
> its edge cases other than testing what Excel will import correctly.

Which is a sorry state of things, in itself. Reading an article about support
of CSV files in PostgreSQL (at http://www.pg-versus-ms.com/), I learned that
there is somewhat of a standard of CSV defined as a RFC at
http://tools.ietf.org/html/rfc4180; I also learned that no Microsoft product
(including MSSQL Server, Excel and Access) can import the standards-compliant
file linked in the article. So apparently your use of JSON was the safest
course of action.

___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-16 Thread Stephan Beal 
might not be fault tolerant in the Enterprise marketing sense of the term,
but it's fairly tolerant of faults at various levels. ;) In any case, it's
undisputedly more tolerant of storage-system failures than git is.

- stephan beal, sgb...@googlemail.com
Written on a keyboard attached to a telephone attached to a TV screen, via
an app written for use on touchscreens. Please excuse brevity, typos, and
whatnot.
On Dec 16, 2015 6:09 PM, "Scott Robison"  wrote:

> Is a sql database fault tolerant? I guess so, but think that is not what
> most people consider fault tolerant.
> On Dec 16, 2015 9:36 AM, "Stephan Beal"  wrote:
>
>> Section 4.1: in fossil, but not git: fault-tolerant storage.
>>
>> - stephan beal, sgb...@googlemail.com
>> Written on a keyboard attached to a telephone attached to a TV screen,
>> via an app written for use on touchscreens. Please excuse brevity, typos,
>> and whatnot.
>> On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:
>>
>>> Based on comments on HN and on this mailing list, I have attempted to
>>> rewrite the fossil-v-git.wiki document
>>> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
>>> better summarize the differences between the two products.
>>>
>>> Your feedback on the rewrite, and especially suggestions for improving
>>> it, are welcomed.
>>>
>>> --
>>> 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
>>
>>
> ___
> 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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-16 Thread Eric Rubin-Smith 
On Wed, Dec 16, 2015 at 11:16 AM, Richard Hipp  wrote:

> Based on comments on HN and on this mailing list, I have attempted to
> rewrite the fossil-v-git.wiki document
> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
> better summarize the differences between the two products.
>
> Your feedback on the rewrite, and especially suggestions for improving
> it, are welcomed.
>

The doc says:

> If you start out using one DVCS and later decide you like the other
better, it is easy to change
.

DRH and crew have defined "easy to change" (meaning easy to migrate away
from) in a way that is misleadingly narrow for many people.  The reason is
that if you are using Fossil with its ticket tracker, then there is no
simple way to export those tickets to any current member of the Git
ecosystem that does ticket tracking (e.g. Jira).

Providing an outbound export interface to at least one such tool would
further strengthen the claim that it is easy to migrate away from Fossil.
Otherwise, users will be "locked in" in the sense that their tickets are
stuck in Fossil, where it is hard to properly cross-reference them with the
ongoing stream of check-ins after export to Git.

In the past, DRH has criticized my above observations by saying that since
Fossil is backed by an SQLite database which the user may query at his or
her leisure, this should suffice for an export capability for tickets.
This criticism does not hold much water, however, since we can observe the
following:

(1) The raw check-in data is *also* backed by an SQLite database.  But the
Fossil dev team saw fit to write an export-to-git capability on top of
that.  This is an internal inconsistency in DRH's argument, since
ostensibly the devs don't think the git export capability was a mistake.

(2) The reasons for having written an export-to-git capability are good
reasons.  Analogously to Word's ability to export to PDF, the application
in question knows both the source and target data formats and how to do the
relevant translations.  Indeed, the whole purpose of export can be seen as
relieving the user of the burden of understanding the source and target
data formats and performing the conversions.  (In a prior thread on this
topic, someone criticized this point by saying that Microsoft has more
developer power than does Fossil.  This, while true, is irrelevant to
questions about whether such an export feature would be useful.)  And in
particular, merely having a well-understood data format does not suffice:
Word cannot claim to have the ability to export to PDF *merely* because its
internal data format is public.

(3) The reasons in (2) generalize to the case of tickets.

DRH has made another criticism of my observations which was that no other
ticket manager permits easy export of its tickets to a 3rd-party ticket
manager.  Whether this is true or not, it is again irrelevant to my claim
that Fossil's ticket system is not, in fact, easy to migrate away from.

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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-16 Thread Scott Robison 
Is a sql database fault tolerant? I guess so, but think that is not what
most people consider fault tolerant.
On Dec 16, 2015 9:36 AM, "Stephan Beal"  wrote:

> Section 4.1: in fossil, but not git: fault-tolerant storage.
>
> - stephan beal, sgb...@googlemail.com
> Written on a keyboard attached to a telephone attached to a TV screen, via
> an app written for use on touchscreens. Please excuse brevity, typos, and
> whatnot.
> On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:
>
>> Based on comments on HN and on this mailing list, I have attempted to
>> rewrite the fossil-v-git.wiki document
>> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
>> better summarize the differences between the two products.
>>
>> Your feedback on the rewrite, and especially suggestions for improving
>> it, are welcomed.
>>
>> --
>> 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
>
>
___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-16 Thread Steve Stefanovich 
This ‎reads better then previous version and more detail is given, thanks.
‎
The ve‎ry last bit (4.2 - Fossil inability to push/pull single branch) sounds 
somewhat weak, though. 
‎
Perhaps it could be strengthened by mentioning bundle command as a way to 
export a branch, but I also think bundle command should be extended to make it 
truly useful for scenarios like these. 

What needs to be additionally done is:

1. Ensure --standalone option extracts the full artifact, not just the last 
delta which will make a bundle, well, a standalone repo  - unless I'm wrong 
what standalone is supposed to mean. 

2. (Optional) Extend the bundle export command ‎so 
‎a new repo can be created with export contents automatically imported into it. 
For example, this way people can export a single check-in as the root before 
adding further bundles to it.  This is useful because cross-merges between 
repos could be done this way with --force option.
‎
Richard, what do you think? 

Cheers,
Steve‎

---
‎
  Original Message  
From: Richard Hipp
Sent: Thursday, 17 December 2015 03:16
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned 
on HN

Based on comments on HN and on this mailing list, I have attempted to
rewrite the fossil-v-git.wiki document
(https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
better summarize the differences between the two products.

Your feedback on the rewrite, and especially suggestions for improving
it, are welcomed.

-- 
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

[fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-16 Thread Richard Hipp 
Based on comments on HN and on this mailing list, I have attempted to
rewrite the fossil-v-git.wiki document
(https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
better summarize the differences between the two products.

Your feedback on the rewrite, and especially suggestions for improving
it, are welcomed.

-- 
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

2015-12-16 Thread Stephan Beal 
Section 4.1: in fossil, but not git: fault-tolerant storage.

- stephan beal, sgb...@googlemail.com
Written on a keyboard attached to a telephone attached to a TV screen, via
an app written for use on touchscreens. Please excuse brevity, typos, and
whatnot.
On Dec 16, 2015 5:16 PM, "Richard Hipp"  wrote:

> Based on comments on HN and on this mailing list, I have attempted to
> rewrite the fossil-v-git.wiki document
> (https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
> better summarize the differences between the two products.
>
> Your feedback on the rewrite, and especially suggestions for improving
> it, are welcomed.
>
> --
> 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