Re: [fossil-users] [GitLab, Inc.] Update: GitLab v. Fossil. Was: Eric Raymond (a.k.a. ESR) has published an SCM
On Tue, 28 Mar 2017 00:33:02 + "Matija Čupić (GitLab, Inc.)" 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. > Yup, it's in Ruby. That doesn't relate to it being self-hostable or > not, at all. I meant self-hosting in the sense Fossil folks understand it: Fossil comes in the form of a single executable file (possibly even statically linked) which you can drop anywhere, run `fossil serve` and be done with it. That same binary also hosts its own web UI through running `fossil ui`. Of course, the same binary also performs its "regular" SCM tasks. These days, different communities overloaded the term "self-hosted" to mean a whole range of things including "we have a Docker container with it". ;-) Sure, possibly those are valid overloadings but I meant "self-hosting" in a very narrow primordial sense. If I'm wrong on this and GitLab indeed may be used in the form of a single executable enabled for the so-called "xcopy deployment" then please excuse me for spreading FUD and I'm OK with standing corrected ;-) ___ 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
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
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
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
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
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
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
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
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
> > > 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
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
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
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
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
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
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
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
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
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?
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
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?
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
