Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Andy Bradford]

Thus said Warren Young on Mon, 27 Mar 2017 10:21:42 -0600:

> Explain to me how someone deciding between Fossil and Git gets down to
> automatic pagination  as the  key differentiator,  the one  that seals
> their decision.

While it may not be used as a determining factor in deciding between Git
and Fossil, it most certainly is  a confusing factor for people who have
never used a pager before. I cannot  recall how many times I have had to
tell people that to exit the pager they can press q. Or how many times I
have had to tell  them that they cannot use the  mouse to scroll through
the output  because the pager  doesn't work that  way. Or how  to search
through the output because ctrl-f doesn't work, etc.

Andy
-- 
TAI64 timestamp: 400058d9c0c2


___
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 interprets plain-text file as a binary file

[Byron Sanchez]

That was it!

I ran the command and received the output:

Starts with UTF-8 BOM: no
Starts with UTF-16 BOM: no
Looks like UTF-8: no
Has flag LOOK_NUL: yes
Has flag LOOK_CR: no
Has flag LOOK_LONE_CR: no
Has flag LOOK_LF: yes
Has flag LOOK_LONE_LF: yes
Has flag LOOK_CRLF: no
Has flag LOOK_LONG: no
Has flag LOOK_INVALID: no
Has flag LOOK_ODD: no
Has flag LOOK_SHORT: no

I deleted the null characters. I didn't have to address any of the other
flags in my case, just the null characters. After that, fossil recognized
the file as plain text again.

Thank you for the help!


On Mon, Mar 27, 2017 at 9:09 PM, Ross Berteig  wrote:

>
> On 3/27/2017 5:44 PM, Byron Sanchez wrote:
>
>> I'm tracking several plain-text files in a repository. These are emacs
>> org-mode files.
>>
>> Fossil sees most of the files in this repo as normal plain-text files and
>> as such, they can be diffed via the fossil web interface.
>>
>> Recently, however, fossil has started interpreting one of these org-mode
>> files as a binary file. Now, fossil prompts with it's binary-file warning
>> each time I update the file. In addition, this file can no longer be diffed
>> in the web interface, since fossil believes it to be a binary file.
>>
>> I'm wondering what steps I should take to debug this, or if there are any
>> common causes for this sort of thing? Very long lines perhaps or possibly
>> unicode characters?
>>
>
> Try the command "fossil test-looks-like-utf" to see the conditions that
> fossil tests for your file. That should help narrow down what to look for
> in the file that caused it to suddenly smell binary. It usually decides a
> file is binary if it has a line that is "too long", or has a NUL byte and
> is not UTF-16.
>
> I believe that a line is too long if it is more than about 8191 ASCII
> characters, a restriction based on the size of the buffer used in the diff
> engine.
>
> The other thing that can happen is to accidentally save a text file in an
> encoding other than UTF-8, with some character not included in the base
> 7-bit ASCII set. In my experience this was usually some accented letter
> from LATIN1, or a symbol such as 'µ' or '°'. Your editor will likely calmly
> edit and save the file, everything looks fine, but the saved file has bytes
> that make an invalid UTF-8 sequence. That does have a different warning
> message than binary data (likely "invalid UTF-8") so isn't your problem
> with this file.
>
>
> The file in question is about 3.3 megabytes in size, and as far as I am
>> aware, a normal plain-text org-mode file.
>>
>> Any ideas would be very appreciated!
>>
>>
> --
> 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] Fossil interprets plain-text file as a binary file

[Richard Hipp]

On 3/27/17, Ross Berteig  wrote:
>
> I believe that a line is too long if it is more than about 8191 ASCII
> characters, a restriction based on the size of the buffer used in the
> diff engine.

Technically, that restriction is due to the way hashes are computed on
individual lines during the diff.  For diffing, the file is broken up
into individual lines, and every line is given a 32-bit hash that
helps to speed up locating the differences.  The lower 13 bits of the
hash are the length of the line in bytes.  The upper 19 bytes are the
actual hash.
-- 
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] Fossil interprets plain-text file as a binary file

[Ross Berteig]

On 3/27/2017 5:44 PM, Byron Sanchez wrote:
I'm tracking several plain-text files in a repository. These are emacs 
org-mode files.


Fossil sees most of the files in this repo as normal plain-text files 
and as such, they can be diffed via the fossil web interface.


Recently, however, fossil has started interpreting one of these 
org-mode files as a binary file. Now, fossil prompts with it's 
binary-file warning each time I update the file. In addition, this 
file can no longer be diffed in the web interface, since fossil 
believes it to be a binary file.


I'm wondering what steps I should take to debug this, or if there are 
any common causes for this sort of thing? Very long lines perhaps or 
possibly unicode characters?


Try the command "fossil test-looks-like-utf" to see the conditions that 
fossil tests for your file. That should help narrow down what to look 
for in the file that caused it to suddenly smell binary. It usually 
decides a file is binary if it has a line that is "too long", or has a 
NUL byte and is not UTF-16.


I believe that a line is too long if it is more than about 8191 ASCII 
characters, a restriction based on the size of the buffer used in the 
diff engine.


The other thing that can happen is to accidentally save a text file in 
an encoding other than UTF-8, with some character not included in the 
base 7-bit ASCII set. In my experience this was usually some accented 
letter from LATIN1, or a symbol such as 'µ' or '°'. Your editor will 
likely calmly edit and save the file, everything looks fine, but the 
saved file has bytes that make an invalid UTF-8 sequence. That does have 
a different warning message than binary data (likely "invalid UTF-8") so 
isn't your problem with this file.


The file in question is about 3.3 megabytes in size, and as far as I 
am aware, a normal plain-text org-mode file.


Any ideas would be very appreciated!



--
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] Fossil interprets plain-text file as a binary file

[Scott Robison]

On Mar 27, 2017 6:44 PM, "Byron Sanchez"  wrote:

Recently, however, fossil has started interpreting one of these org-mode
files as a binary file. Now, fossil prompts with it's binary-file warning
each time I update the file. In addition, this file can no longer be diffed
in the web interface, since fossil believes it to be a binary file.

I'm wondering what steps I should take to debug this, or if there are any
common causes for this sort of thing? Very long lines perhaps or possibly
unicode characters?


Long lines, invalid unicode sequences, or many control codes.

What type of data is it? Source code, poetry?
___
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 interprets plain-text file as a binary file

[Byron Sanchez]

I'm tracking several plain-text files in a repository. These are emacs
org-mode files.

Fossil sees most of the files in this repo as normal plain-text files and
as such, they can be diffed via the fossil web interface.

Recently, however, fossil has started interpreting one of these org-mode
files as a binary file. Now, fossil prompts with it's binary-file warning
each time I update the file. In addition, this file can no longer be diffed
in the web interface, since fossil believes it to be a binary file.

I'm wondering what steps I should take to debug this, or if there are any
common causes for this sort of thing? Very long lines perhaps or possibly
unicode characters?

The file in question is about 3.3 megabytes in size, and as far as I am
aware, a normal plain-text org-mode file.

Any ideas would be very appreciated!

Thanks,

Byron Sanchez
___
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-users Digest, Vol 110, Issue 51

[Ron W]

On Sun, Mar 26, 2017 at 2:56 PM, 
wrote:

>
> Date: Sun, 26 Mar 2017 20:50:38 +0200
> From: Jan Danielsson 
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] GitLab v. Fossil. Was: Eric Raymond
> (a.k.a. ESR) has published an SCM
> Message-ID: <45ad044c-1bcd-3a67-bfb3-4e06688d9...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> On 03/26/17 19:18, Richard Hipp wrote:
> [---]
> > (i)  With Fossil, one can click on two nodes of the graph to see a
> > diff between those two nodes.  With GitLab, you apparently have to go
> > to the separate "Compare" screen, then many type in (or paste in) hash
> > name prefixes of the two check-ins you want to compare.  This seems
> > rather clumsy.  But maybe I'm missing something.
>
>This is the same in Bitbucket.
>
...

>Anyway, I searched around to see if it was available in an alpha
> version or something somewhere, and quickly realized others wanted the
> feature as well.  However, no good news on that front:  The idea was
> apparently "No, you use tool X for that.".  (As it happens, this tool X
> was a desktop application for the local checkout, which - in my mind -
> kind of defeated the purpose).
>

To be fair, Bitbucket, github and gitlab are hosting services for a tool
that is otherwise run on the local user's PC. those services focus on
features more directly related to repository hosting than to a developer's
versioning operations, which are done on the user's PC.

Fossil, however, has a built-in GUI. Even though that GUI is based on web
technology (so is remotely operable), it is still the primary GUI for the
local user. As such, it is natural for it to provide features more expected
in a desktop application than in a web application.

In many ways, chiselapp.com is much simpler than gitlab.com et al, but
Fossil itself provides features for interacting with individual
repositories so chiselapp gets those features for "free",

   Maybe this is tangentially related to the cathedral vs bazaar
> discussion; with Fossil, you typically have a central point where "all"
> the useful checkins end up.
>

Most projects using a DVCS, whether Fossil, git, Hg or other, have a master
repository. However, it is possible to use a DVCS in a peer-to-peer style,
where, typically, each of the core developers maintains a "co-master"
repository for the project. Fossil's own master repository is actually 3
(last I read) co-equal repositories that are periodically sync'ed with each
other. Granted those 3 repositories are owned and controlled by the primary
developer, it still illustrates the concept of peer-to-peer operation.
___
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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Ross Berteig]

On 3/27/2017 2:29 PM, Christophe Gouiran wrote:


Someone wanting to get the list or current branch without relying on 
raw Fossil output could use "fossil json branch list" for that purpose.


But only if fossil was configured with JSON support. Which is not 
configured by default, or in the pre-built binary distributions. I would 
argue that for scripting around fossil, JSON support should be 
configured and used, but that will only work for environments where it 
is acceptable to configure and build a fossil as needed rather than 
depending on upstream packages or official builds.


--
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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Christophe Gouiran]

>
>
> While the addition of a subcommand seems like a good idea, changing
> default behaviour will no doubt break existing workflows.
>

I agree on this point.
However I have learned (where possible) to never rely on raw commands
outputs in my wrappers.
Indeed, I took over several years ago a Python script used to extract debug
informations and the like from elf objects.
This script relyed on outputs of 'nm' and 'readelf' commands.
When we upgraded from Debian 6 to Debian 7, the outputs of those commands
changed a bit and the script didn't work anymore.
We then decided to rewrite the script in plain C using directly libdwarf
and libelf.

Someone wanting to get the list or current branch without relying on raw
Fossil output could use "fossil json branch list" for that purpose.



> ___
> 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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Warren Young]

On Mar 27, 2017, at 12:07 PM, Warren Young  wrote:
> 
> It isn’t always clue to newbies

s/clue/clear/
___
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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Marc Simpson]

On Mon, Mar 27, 2017 at 10:40 AM, Christophe Gouiran
 wrote:
>
> please find an attached patch which implements a new "current" subcommand for 
> "branch".
> This is now the default subcommand if one executes "fossil branch" without 
> any subcommand.

While the addition of a subcommand seems like a good idea, changing
default behaviour will no doubt break existing workflows.
___
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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Warren Young]

On Mar 27, 2017, at 11:50 AM, bch  wrote:
> 
> > executing "fossil branch" to get the current branch is not very convenient 
> > to me.
> 
> Note that "fossil info" gives information about the current checkout, 
> including the branch name.

That info is also given in “fossil status”, a command you may be using 
regularly anyway.

If you’ve got the VISUAL or EDITOR environment variables set, you also get this 
info in the commented-out part of a commit message in the editor, giving one 
last clue to the programmer that they’re about to commit something to the wrong 
branch.

All of these say “tags” instead of “branch”, though, which may be the actual 
problem here.  It isn’t always clue to newbies that branches and tags are 
nearly the same thing in Fossil, and that it is correct to talk about “trunk” 
as a tag, for example.
___
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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[bch]

On Mar 27, 2017 10:40, "Christophe Gouiran"  wrote:

Hello everybody,

Amount of branches may be quite important (in Fossil code itself, there are
now about 100 branches).
In this case, executing "fossil branch" to get the current branch is not
very convenient to me.


Note that "fossil info" gives information about the current checkout,
including the branch name.

-bch



please find an attached patch which implements a new "current" subcommand
for "branch".
This is now the default subcommand if one executes "fossil branch" without
any subcommand.

All other subcommands (info, list|ls, info) are left unmodified.


___
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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Umgeher Torgersen]

Nice!

--
//twitter: @umgeher
//xmpp: m...@umgeher.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] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[Christophe Gouiran]

Hello everybody,

Amount of branches may be quite important (in Fossil code itself, there are
now about 100 branches).
In this case, executing "fossil branch" to get the current branch is not
very convenient to me.

please find an attached patch which implements a new "current" subcommand
for "branch".
This is now the default subcommand if one executes "fossil branch" without
any subcommand.

All other subcommands (info, list|ls, info) are left unmodified.
Index: src/branch.c
==
--- src/branch.c
+++ src/branch.c
@@ -186,13 +186,14 @@
 ** Allows bits in the mBplqFlags parameter to branch_prepare_list_query().
 */
 #define BRL_CLOSED_ONLY  0x001 /* Show only closed branches */
 #define BRL_OPEN_ONLY0x002 /* Show only open branches */
 #define BRL_BOTH 0x003 /* Show both open and closed branches */
-#define BRL_OPEN_CLOSED_MASK 0x003
-#define BRL_MTIME0x004 /* Include lastest check-in time */
-#define BRL_ORDERBY_MTIME0x008 /* Sort by MTIME. (otherwise sort by name)*/
+#define BRL_CURRENT_ONLY 0x004 /* Show only current branch */
+#define BRL_MASK 0x007
+#define BRL_MTIME0x008 /* Include lastest check-in time */
+#define BRL_ORDERBY_MTIME0x009 /* Sort by MTIME. (otherwise sort by name)*/
 
 #endif /* INTERFACE */
 
 /*
 ** Prepare a query that will list branches.
@@ -200,11 +201,11 @@
 ** If (which<0) then the query pulls only closed branches. If
 ** (which>0) then the query pulls all (closed and opened)
 ** branches. Else the query pulls currently-opened branches.
 */
 void branch_prepare_list_query(Stmt *pQuery, int brFlags){
-  switch( brFlags & BRL_OPEN_CLOSED_MASK ){
+  switch( brFlags & BRL_MASK ){
 case BRL_CLOSED_ONLY: {
   db_prepare(pQuery,
 "SELECT value FROM tagxref"
 " WHERE tagid=%d AND value NOT NULL "
 "EXCEPT "
@@ -235,10 +236,20 @@
 "   AND NOT %z"
 " ORDER BY value COLLATE nocase /*sort*/",
 TAG_BRANCH, leaf_is_closed_sql("tagxref.rid")
   );
   break;
+}
+case BRL_CURRENT_ONLY: {
+  db_prepare(pQuery,
+"SELECT DISTINCT value FROM tagxref"
+" WHERE tagid=%d AND rid=%d"
+"   AND rid IN leaf"
+" ORDER BY value COLLATE nocase /*sort*/",
+TAG_BRANCH, db_lget_int("checkout", 0)
+  );
+  break;
 }
   }
 }
 
 /*
@@ -284,10 +295,14 @@
 **year-month-day form, it may be truncated, the "T" may be
 **replaced by a space, and it may also name a timezone offset
 **from UTC as "-HH:MM" (westward) or "+HH:MM" (eastward).
 **Either no timezone suffix or "Z" means UTC.
 **
+**fossil branch current
+**
+**Display current branch.
+**
 **fossil branch list|ls ?-a|--all|-c|--closed?
 **
 **List all branches.  Use -a or --all to list all branches and
 **-c or --closed to list all closed branches.  The default is to
 **show only open branches.
@@ -299,23 +314,31 @@
 ** Options:
 **-R|--repository FILE   Run commands on repository FILE
 */
 void branch_cmd(void){
   int n;
-  const char *zCmd = "list";
+  const char *zCmd = "current";
   db_find_and_open_repository(0, 0);
   if( g.argc>=3 ) zCmd = g.argv[2];
   n = strlen(zCmd);
   if( strncmp(zCmd,"new",n)==0 ){
 branch_new();
-  }else if( (strncmp(zCmd,"list",n)==0)||(strncmp(zCmd, "ls", n)==0) ){
+  }else if( (strncmp(zCmd,"list",n)==0)||(strncmp(zCmd, "ls", n)==0)||
+(strncmp(zCmd,"current", n)==0) ){
 Stmt q;
 int vid;
 char *zCurrent = 0;
 int brFlags = BRL_OPEN_ONLY;
-if( find_option("all","a",0)!=0 ) brFlags = BRL_BOTH;
-if( find_option("closed","c",0)!=0 ) brFlags = BRL_CLOSED_ONLY;
+if( strncmp(zCmd,"current", n)==0 ){
+  brFlags = BRL_CURRENT_ONLY;
+  if( !g.localOpen ){
+fossil_fatal("must be within a local checkout to use 'current'");
+  }
+}else{
+  if( find_option("all","a",0)!=0 ) brFlags = BRL_BOTH;
+  if( find_option("closed","c",0)!=0 ) brFlags = BRL_CLOSED_ONLY;
+}
 
 if( g.localOpen ){
   vid = db_lget_int("checkout", 0);
   zCurrent = db_text(0, "SELECT value FROM tagxref"
 " WHERE rid=%d AND tagid=%d", vid, TAG_BRANCH);
@@ -342,11 +365,11 @@
 fossil_print("%s: open as of %s on %.16s\n", zBrName, zDate, zUuid);
   }
 }
   }else{
 fossil_fatal("branch subcommand should be one of: "
- "info list ls new");
+ "current info list ls new");
   }
 }
 
 static const char brlistQuery[] =
 @ SELECT

___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Martin S. Weber]

On 03/27/17 01:55, Roy Marples wrote:
Pager output disappearing with the pager (I assume when asking the 
pager to exit) is an issue with the pager.


I disagree. Disappearing output uses the "alternate screen" of a 
terminal so that the pager's output does not interfere with your 
non-reading session. It most certainly is a feature, and one with a long 
history to lean on as well.


Regards,
-Martin
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Warren Young]

On Mar 27, 2017, at 10:19 AM, Martin S. Weber  wrote:
> 
> On 03/27/17 01:55, Roy Marples wrote:
>> Pager output disappearing with the pager (I assume when asking the pager to 
>> exit) is an issue with the pager.
> 
> I disagree. Disappearing output uses the "alternate screen" of a terminal so 
> that the pager's output does not interfere with your non-reading session. It 
> most certainly is a feature, and one with a long history to lean on as well.

Not all terminal/pager/OS combos do this correctly.  Thus this Super User post:

https://superuser.com/questions/106637

As far as Fossil goes, though, this issue is not relevant.  If you want to use 
a pager, point Fossil at a decent one, configure the pager correctly, and run 
it under a reasonable terminal program.
___
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] [PROPOSED FEATURE] Fossil commands output sent through a pager

[Warren Young]

On Mar 26, 2017, at 11:49 AM, Tomasz Konojacki  wrote:
> 
> On Sun, 26 Mar 2017 19:25:25 +0200
> Christophe Gouiran  wrote:
> 
>> I see that most of you complain about this proposed feature.
> 
> TBH, many members of this list live in the UNIX greybeard bubble, and
> that's why there is so much opposition to this feature. They're used to
> the original UNIX way and they have different expectations than most of
> users.

Unix greybeard here: I like automatic pagination, and I expect to use this 
feature if it manages to land in a Fossil release.

Be careful how you swing that broad brush around, you might hit someone.

Automatic pagination comes out of the Unix greybeard world.  As suggested 
up-thread, it was done during the transition from paper teletypes to glass ttys 
without scrollback buffers in the mid to late 1970s, since in that new world 
you couldn’t:

a) read the output in real time as it printed at 110 bps on your Teletype Model 
33 ASR, since glass terminals generally ran at least 10x faster, too fast for a 
human to read in real time; or

b) lift the continuous-feed paper up and read what the computer printed 
previously

Although the original Unix man pages were ruthlessly edited and features culled 
and consolidated to keep man pages to a single printed page, that’s still about 
twice as many lines as allowed on a glass tty of the day.  It was also about 
this time that man pages started to creep beyond single printed pages.

Unix greybeards invented automatic pagination, by necessity.

> there is *nothing* nice about
> fossil dumping thousands of lines to the terminal.

As you’ve seen, that’s debatable.  I happen to fall on your side, but I can see 
the point of those who prefer to just use the terminal scrollback feature or 
manual pipe-thru-pager.

> In fact, I think it scares off newbies who only used git before.

Explain to me how someone deciding between Fossil and Git gets down to 
automatic pagination as the key differentiator, the one that seals their 
decision.
___
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] Old fossil (1.29) accessing current fossil trunk?

[Stephan Beal]

On Mon, Mar 27, 2017 at 9:19 AM, Stefan Bellon  wrote:

> would have to take a backup of the fossil in version 1 state? Or is
> there any "go back to version 1 format" emergency way?
>

fossil 1 has a strict "artifact" format which v2 breaks (in that the hash
lengths differ), so v1 cannot read artifacts (checkins, tickets, etc.)
which were created in v2, and trying to do so will cause a fatal error for
most commands. Thus there is no way back for data generated with an sha3
hash. There "might" (i don't know) be a way to revert up to the point just
before where the first sha3 hash was introduced to a repo.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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] GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM

[Konstantin Khomoutov]

On Sun, 26 Mar 2017 13:18:08 -0400
Richard Hipp  wrote:

> > http://esr.ibiblio.org/?p=7448
> > http://www.catb.org/esr/src/
> 
> Thanks for pointing this out, Stephan.
> 
> What intrigues me most here is not ESR's python-script wrapper around
> RCS/SCCS, but rather the GitLab interface.  I had heard of GitLab, but
> had never before taken the time to look into it.  My first impression
> is that it seems much nicer than GitHub.
[...]

JFTR GitLab is written in Ruby, so it's not at all self-hosting.
Fossil has a clear upper hand in this.
___
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] Old fossil (1.29) accessing current fossil trunk?

[Stefan Bellon]

On Mon, 13 Mar, Richard Hipp wrote:
>
> The upgrade is simple.  Just replace your current fossil executable
> with a new one.  Everything should work exactly as it did before.
> There are no incompatibilities.  The only difference is that Fossil
> 2.1 will read and write the latest repositories whereas Fossil 1.x
> will not.

Thanks for the encouragement, it turned out that it exactly worked like
this. We did not yet find any breakage in command line usage or output.
Nice job. :-)

However one concern was raised: What, if for some reason, some fossil
user has to go back to version 1.x from 2.x. I just did a short test
with a "fossil-1 rebuild" on a fossil-2 repository. The only thing that
in my quick test survived was the initial empty checkin, but not the
following content checkins. Another "fossil-2 rebuild" however brought
back the contents.

So, do I assume that once you start working with fossil-2 on the
repository, you cannot "rebuild back" to version 1, even if you do not
(intent to) use new fossil 2 features? So, to be on the safe side one
would have to take a backup of the fossil in version 1 state? Or is
there any "go back to version 1 format" emergency way?

Greetings,
Stefan

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