Re: [fossil-users] [PATCH] Remove unused option from settings page

[bytevolcano]

Ping.

On Thu, 21 Jun 2018 22:18:37 +1000
 wrote:

> It appears the "show-version-diffs" setting was abandoned in commit 
> 0a1f4ed6aa.
> 
> Index: src/setup.c
> ==
> --- src/setup.c
> +++ src/setup.c
> @@ -1463,19 +1463,10 @@
>@ in a separate box (using CSS class "timelineDate") whenever the date 
> changes.
>@ With the "-MM-DDHH:MM" and "YYMMDD ..." formats, the complete 
> date
>@ and time is shown on every timeline entry using the CSS class 
> "timelineTime".
>@ (Preperty: "timeline-date-format")
> 
> -  @ 
> -  onoff_attribute("Show version differences by default",
> -  "show-version-diffs", "vdiff", 0, 0);
> -  @ The version-information pages linked from the timeline can either
> -  @ show complete diffs of all file changes, or can just list the names of
> -  @ the files that have changed.  Users can get to either page by
> -  @ clicking.  This setting selects the default.
> -  @ (Property: "show-version-diffs")
> -
>@ 
>entry_attribute("Max timeline comment length", 6,
>"timeline-max-comment", "tmc", "0", 0);
>@ The maximum length of a comment to be displayed in a timeline.
>@ "0" there is no length limit.
> ___
> 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] [PATCH] Remove unused option from settings page

[bytevolcano]

It appears the "show-version-diffs" setting was abandoned in commit 0a1f4ed6aa.

Index: src/setup.c
==
--- src/setup.c
+++ src/setup.c
@@ -1463,19 +1463,10 @@
   @ in a separate box (using CSS class "timelineDate") whenever the date 
changes.
   @ With the "-MM-DDHH:MM" and "YYMMDD ..." formats, the complete 
date
   @ and time is shown on every timeline entry using the CSS class 
"timelineTime".
   @ (Preperty: "timeline-date-format")

-  @ 
-  onoff_attribute("Show version differences by default",
-  "show-version-diffs", "vdiff", 0, 0);
-  @ The version-information pages linked from the timeline can either
-  @ show complete diffs of all file changes, or can just list the names of
-  @ the files that have changed.  Users can get to either page by
-  @ clicking.  This setting selects the default.
-  @ (Property: "show-version-diffs")
-
   @ 
   entry_attribute("Max timeline comment length", 6,
   "timeline-max-comment", "tmc", "0", 0);
   @ The maximum length of a comment to be displayed in a timeline.
   @ "0" there is no length limit.
___
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] The legacy of FOSSIL_ENABLE_LEGACY_MV_RM

[bytevolcano]

That makes sense, but what I'm saying is, why bother with the
compile-time flag?

It seems desirabe to allow the user to configure this behavior with
repository settings, rather than using a flag to determine if it is
hard-coded or not.

Are there a lot of legacy scripts out there that are difficult to
modify? Perhaps keeping the new behaviour (overridden with --soft) is
worth it at this stage. 

On Wed, 20 Jun 2018 21:49:18 -0400
Richard Hipp  wrote:

> It ought to be the case that the default action of "fossil rm" and
> "fossil mv" is to actually change the filesystem, in addition to
> changing the way files are stored in the repository.  But early
> versions of Fossil did not behave that way.  They required you to do
> it in two steps:
> 
>  fossil rm abc.c
>  rm abc.c
> 
> We talked about fixing Fossil so that "fossil rm abc.c" actually
> removed the file.  But the feeling was that would break too many
> legacy scripts.  So the less desirable legacy behavior remains, to
> this day.
> 
> On 6/20/18, bytevolc...@safe-mail.net  wrote:
> > Hello,
> >
> > I am trying to understand the idea behind FOSSIL_ENABLE_LEGACY_MV_RM.
> >
> > It has been around for a while, and it is the only compile-time flag that
> > determines if a setting is hard-coded or if it is obtained from the
> > repository config.
> >
> > It appears that if this is not defined, the "mv" and "rm" commands will
> > modify the file system under all circumstances.
> >
> > Given the "--hard" option in these commands anyway, this seems superfluous.
> > So what is the idea behind the FOSSIL_ENABLE_LEGACY_MV_RM flag?
> >  
> 
> 

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

[fossil-users] The legacy of FOSSIL_ENABLE_LEGACY_MV_RM

[bytevolcano]

Hello,

I am trying to understand the idea behind FOSSIL_ENABLE_LEGACY_MV_RM.

It has been around for a while, and it is the only compile-time flag that
determines if a setting is hard-coded or if it is obtained from the repository 
config.

It appears that if this is not defined, the "mv" and "rm" commands will
modify the file system under all circumstances.
 
Given the "--hard" option in these commands anyway, this seems superfluous.
So what is the idea behind the FOSSIL_ENABLE_LEGACY_MV_RM flag?
___
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] Show time...

[bytevolcano]

On Mon, 4 Jun 2018 03:43:19 +0200
Stephan Beal  wrote:

> On Mon, Jun 4, 2018, 03:33 Richard Hipp  wrote:
> 
> > On 6/3/18, Richard Hipp  wrote:  
> > >
> > > So, if anybody sees any last minute tidying up that we need to do...  
> >
> > For example, on the front page
> > (https://fossil-scm.org/index.html/doc/trunk/www/index.wiki), what if
> > I add some text to item 8 to talk about how Fossil is "Independent and
> > not beholden to venture capitalists".  Too snarky?
> >  
> 
> Murphy's Law suggests that the moment you post that the moment you post
> that, Microsoft, Google, or Oracle will make you an offer you can't refuse
> (and that statement will remain part of the fossilized record).

It is already on the mailing list now, probably already archived by
various list archivers, so good luck with that one.
___
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] Show time...

[bytevolcano]

 - Paleo
 - Jurassic
 - Diatom
 - Trilobyte

Better yet, find a term begining with 'C' so that you can have the
'C Versioning System.'

On Wed, 6 Jun 2018 21:26:22 -0400
Eduard  wrote:

> I might enable public registration 'soon'. Now all I need is a catchy 
> name, like `chiselapp` :p
___
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 delete user

[bytevolcano]

I think Peter is referring to deleting users from the "user" table.

Fossil keeps the commit history forever, and each manifest has the name
of the user that made the commit. In the database, this is recorded in
the user column of the "event" table as the name of the user that made
the commit.

The only thing that refers to the UID, that may present an issue, is the
"rcvfrom" table. This can easily be changed to use the user name
rather than the UID.

There is no reason why users cannot be deleted from the "user"
table, since the user names would still show up in the history even if
users were deleted from this table.

On Tue, 15 May 2018 15:41:53 +0300
Victor Wagner  wrote:

> Fossil keeps history forever. How would it do so, if author of some
> commits or wiki edits disappears from the repository completely.
> 
> Disable access, revoke privileges, but keep the user in the DB,
> because it has log of his activity.

___
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] Unused artifact view

[bytevolcano]

Given over half of a typical repository is a delta, this is not a bad
idea. It will allow you to optimize some of the SQL for delta lookups.

On Mon, 22 Jan 2018 21:04:26 -0500
Richard Hipp  wrote:

> On 1/22/18, bytevolc...@safe-mail.net  wrote:
> > In rebuild.c (commit 1a95af721e467a6e3321c1557c4f0cdfa353ef4a):
> >
> > Ln 168:
> >
> >   db_multi_exec(
> > "CREATE VIEW IF NOT EXISTS "
> > "  repository.artifact(rid,rcvid,size,atype,srcid,hash,content) AS "
> > "SELECT blob.rid,rcvid,size,1,srcid,uuid,content"
> > "  FROM blob LEFT JOIN delta ON (blob.rid=delta.rid);"
> >   );
> >
> > It appears that this view is not in use at all. What is this for?  
> 
> At one point I was going to try to combine the BLOB and DELTA tables
> into a single table named ARTIFACT.  This was a stepping stone toward
> that goal.

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

[fossil-users] Unused artifact view

[bytevolcano]

In rebuild.c (commit 1a95af721e467a6e3321c1557c4f0cdfa353ef4a):

Ln 168:

  db_multi_exec(
"CREATE VIEW IF NOT EXISTS "
"  repository.artifact(rid,rcvid,size,atype,srcid,hash,content) AS "
"SELECT blob.rid,rcvid,size,1,srcid,uuid,content"
"  FROM blob LEFT JOIN delta ON (blob.rid=delta.rid);"
  );

It appears that this view is not in use at all. What is this for?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Forgotten "Fossil 1.x" comment in add.c

[bytevolcano]

What's up with this comment in add.c starting at line 27:

/*
** WARNING: For Fossil version 1.x this value was always zero.  For Fossil
**  2.x, it will probably always be one.  When this value is zero,
**  files in the checkout will not be moved by the "mv" command and
**  files in the checkout will not be removed by the "rm" command.
**
**  If the FOSSIL_ENABLE_LEGACY_MV_RM compile-time option is used,
**  the "mv-rm-files" setting will be consulted instead of using
**  this value.
**
**  To retain the Fossil version 1.x behavior when using Fossil 2.x,
**  the FOSSIL_ENABLE_LEGACY_MV_RM compile-time option must be used
**  -AND- the "mv-rm-files" setting must be set to zero.
*/
#ifndef FOSSIL_MV_RM_FILE
#define FOSSIL_MV_RM_FILE(0)
#endif

It appears this has been unchanged since it was introduced back in
April 2015: http://fossil-scm.org/index.html/info/3c941ddc3674cd0f
___
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] [PATCH] Improve symlink following of file_wd_isdir()

[bytevolcano]

Looks like this resolves the issue.

On Thu, 30 Nov 2017 13:10:09 -0500
Richard Hipp  wrote:
> Can you rebuild using the latest check-in on the symlink-refactor
> branch (https://www.fossil-scm.org/fossil/info/b2594738460036b9) and
> let me know whether or not this problem is resolved?
___
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] [PATCH] Improve symlink following offile_wd_isdir()

[bytevolcano]

On Thu, 30 Nov 2017 13:19:38 +0100
Jan Nijtmans  wrote:

> This patch has no relation to fossil's symlink support, it's just part
> of the code to find a suitable temporary directory to write some
> intermediate file. It's unfortunate it's that complicated, but useful
> because sometimes the working directory or the current directory
> is read-only, That's what this code is about.

That is my initial impression when I wrote the patch; it was to do with
Fossil creating the temp folder before writing to the file. This issue
is a showstopper for those who use recent OpenBSD versions, as OpenBSD
now has a symlink from /var/tmp to "../tmp", which confuses Fossil.

The patch fixes this situation:

 $ cd /home/test/fossil/wdir1
 $ fossil uv edit 
  (try to create directory /home/test/fossil/wdir1/../tmp
  i.e. /home/test/fossil/tmp)
 
> I sometimes use symlink support in fossil, but it shouldn't be fancy
> at all. When committing a symlink, someone else checking it out
> should get the same symlink. This - generally - only makes sense
> when the symlink is relative and points to somewhere else in
> the working directory. Otherwise - indeed - it doesn't make sense.
> This is the way that - for example - Subversion handles symlinks,
> it would be a loss to remove it from fossil. It's just like the 'x'
> (executable) flag: unfortunate that Windows doesn't handle it the way
> UNIX does, that's the reason why fossil has to do tricky things 

What Fossil should do is have a reliable way to determine what should
be written first. A "racish" condition can exist with symlink support
where files that go into a symlinked directory are written first, and
when it's time to create the symlink, the name of the link itself is
taken because Fossil has written the directory.

> 
> That said, symlinks are actually a UNIX-only feature: I don't
> mind that - on Windows - symlinks check-out as being a file with
> the link path as content (that's what Subversion does as well ...)

Since Windows Vista and Windows Server 2008:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363866%28v=vs.85%29.aspx

> 
> Regards,
>Jan Nijtmans
> ___
> 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-NG Bloat?

[bytevolcano]

On Mon, 27 Nov 2017 13:58:14 -0700
Warren Young  wrote:

> On Nov 23, 2017, at 5:19 AM, bytevolc...@safe-mail.net wrote:
> > 
> > They want maximum results for minimum effort? That may be normal, but
> > it's still whiney.  
> 
> If “normal” is “whiney”, it ceases to be a useful disparagement unless you 
> intend to change society.  This mailing list is not a good place to start 
> doing that; few take social cues from geeks. :)

If your users want Git support, odds are they know how to use Git, and that's 
not something a "normal" person can do, or care about. ;)

> That should be tried, too.  I suspect it will make Git faster, at least up to 
> repo sizes that fit easily within a single process’s ability to grab 
> hard-wired RAM, based on the benchmark I pointed you to up-thread.
> 
> Interesting point about that benchmark: if you force it to create a DB much 
> larger than RAM, performance goes in the tank on the SQLite side.  And that 
> in turn may well be materially interesting to this very discussion.  Maybe 
> it’s why Git holds up better under load as repo size grows into the gigs.

May be worth testing that out on a restricted VM.

> VAX != “super unusual.”  It was one of the most popular computers of the 
> 1980s, dominating an entire market segment.  Therefore, a lot of software got 
> ported to it, including recent versions of GCC.  A huge hobbyist community 
> still exists for it, which also helps.

Although these days, it isn't very mainstream. When I say "unusual" I am 
talking about things that are either rare or not popular/mainstream in today's 
modern (and somewhat broken) world.

> 
> You want unusual, let’s talk about the Intel Paragon, based on the ill-fated 
> i860 microprocessor:
> 
> https://en.wikipedia.org/wiki/Intel_Paragon
> 
> I suspect it’s difficult to find a GCC fully supporting C99 on that, yet they 
> were powerhouses in their day, even grabbing the #1 spot in TOP500 list at 
> one point:
> 
> 
> https://www.top500.org/featured/systems/intel-xps-140-paragon-sandia-national-labs/
> 
> Now, let us say that I’m an underfunded government laboratory sharing time on 
> a third-hand Paragon that is still powered on only because it’s cheaper to 
> pay the power and cooling bill than buy a new massively parallel 
> supercomputer.  Do I not get to run the latest SQLite now?  Do I not get to 
> pull from public Fossil repos?

And how many systems like that require SQLite/Fossil in the first place? Let's 
be realistic here. If you spend time focusing on evey what-if/corner case when 
developing software, you are bound to become the next open-source Adobe sooner 
or later. There's an even better chance they run old archaic (versions of) 
software as well, and don't care much for SQLite/Fossil or anything that uses 
it.

> [citation needed]
> 
> I’m quite serious.  Who says C11 is a major factor in the maintainability of 
> C code, and by what measured factor?

Using standard types (uintXX_t, uint_fastXX_t, bool), and moving variables down 
scope makes it clearer as to where they are used.
I notice in a lot of the Fossil code, you have this situation:

void a_function(int this, int that)
{
  int i, variable1, variable2;
  /* long block of code */
  variable1 = this * that;
  /* long block of code */
  variable2 = that / this;
  /* long block of code */
  for( i = 0; i < variable1; i++ ) {
do_something(i);
  }
}

Now in this example, you can see that variable1 isn't used until after the 
first long block of code, and variable2 isn't used until the second one.
The variable i is only ever used in the for loop. With C99 you can write this 
as follows:

void a_function(int this, int that)
{
  /* long block of code */
  int variable1 = this * that;
  /* long block of code */
  int variable2 = that / this;
  /* long block of code */
  for( int i = 0; i < variable1; i++ ) {
do_something(i);
  }
}

Here it is clear where the variable is first used, particular in the situation 
of the for loop. Of course this is a case-by-case thing, up to the developer.

I should point out that I am not advocating use of C99/C11 just for the sake of 
using it, but why restrict to an obsolete standard when a better standard has 
been present since 18 years ago? Why penalize the development of Fossil just 
for a few corner cases?

> Ditto.  I suspect you’re chasing microoptimizations, which might amount to 
> single-digit percentage speed increases, all in.
> 
> Even at today’s far slower single-core speed increase rates, you’ll probably 
> get all of that performance and more from Intel just in the time it takes to 
> do the “upgrade.”  Why not spend the time elsewhere and let Intel deliver the 
> goods?

It's not about chasing microoptimizations, but does it hurt if you get even 
just a bit of performance for free, if code is more readable and workable?

> You’re going to change a bunch of variables’ locality and you think I can fix 
> it with a few #defines?  I don’t 

Re: [fossil-users] [PATCH] Improve symlink following offile_wd_isdir()

[bytevolcano]

On Mon, 27 Nov 2017 09:52:19 -0500
Richard Hipp  wrote:

> I am in receipt of your patch.  I have not evaluated it yet because
> the entire symbolic-link mechanism in Fossil is confused and very
> difficult to manage.  It mostly works now, but is brittle.  A
> seemingly simple patch like what you sent could cause breakage.

Perhaps a separate function "make_path()" just to create any
directories that may not exist, rather than stuffing it all in
blob_write_to_file(). It can be called as follows if needed:

  make_path(zFile);
  blob_write_to_file(, zFile);

> 
> I am very sorry that I allowed symbolic link support into Fossil in
> the first place.   (Symbolic link support was neither designed nor
> written by me - it is contributed code.)  I would really like to get
> rid of symbolic link support.  Symbolic links seem out-of-place in a
> version control system.  As implemented, symbolic links are a point of
> confusion which (as far as I can see) adds no useful capabilities.

Are you referring to symlinks inside a working directory, or Fossil's
ability to "follow" them? If so have a survey of users, or a
disabled-by-default policy to see if any users need it.
___
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] [PATCH] Improve symlink following offile_wd_isdir()

[bytevolcano]

Ping.

On Sat, 25 Nov 2017 11:42:29 +
bytevolc...@safe-mail.net wrote:
Index: src/file.c
==
--- src/file.c
+++ src/file.c
@@ -327,24 +327,30 @@
 ** zFilename is a directory -OR- a symlink that points to a directory.
 ** Return 0 if zFilename does not exist.  Return 2 if zFilename exists
 ** but is something other than a directory.
 */
 int file_wd_isdir(const char *zFilename){
-  int rc;
+  int rc, nFN;
   char *zFN;


   zFN = mprintf("%s", zFilename);
-  file_simplify_name(zFN, -1, 0);
+  nFN = file_simplify_name(zFN, -1, 0);
   rc = getStat(zFN, 1);
   if( rc ){
 rc = 0; /* It does not exist at all. */
   }else if( S_ISDIR(fileStat.st_mode) ){
 rc = 1; /* It exists and is a real directory. */
   }else if( S_ISLNK(fileStat.st_mode) ){
 Blob content;
+char *zFullName;
 blob_read_link(, zFN); /* It exists and is a link. */
-rc = file_wd_isdir(blob_str()); /* Points to directory? */
+if(*blob_str() != '/') {
+  while( nFN>0 && zFN[nFN-1]!='/' ){ nFN--; }
+} else { nFN = 0; }
+zFullName = mprintf("%.*s%s", nFN, zFN, blob_str());
+rc = file_wd_isdir(zFullName); /* Points to directory? */
+free(zFullName);
 blob_reset();
   }else{
 rc = 2; /* It exists and is something else. */
   }
   free(zFN);

___
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] More timeline changes

[bytevolcano]

On Sat, 25 Nov 2017 18:46:52 -0600
Zakero  wrote:

> To help make the ellipses more visible, you could put them in their
> own   and let the skin figure out what looks best.  Also,
> instead of using "...", what about "[+]"?

If it's going at the end of the text, how about ">>>"?
___
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] [PATCH] Improve symlink following offile_wd_isdir()

[bytevolcano]

Fixed a typo resulting in absolute cases not being picked up well.

Index: src/file.c
==
--- src/file.c
+++ src/file.c
@@ -327,24 +327,30 @@
 ** zFilename is a directory -OR- a symlink that points to a directory.
 ** Return 0 if zFilename does not exist.  Return 2 if zFilename exists
 ** but is something other than a directory.
 */
 int file_wd_isdir(const char *zFilename){
-  int rc;
+  int rc, nFN;
   char *zFN;


   zFN = mprintf("%s", zFilename);
-  file_simplify_name(zFN, -1, 0);
+  nFN = file_simplify_name(zFN, -1, 0);
   rc = getStat(zFN, 1);
   if( rc ){
 rc = 0; /* It does not exist at all. */
   }else if( S_ISDIR(fileStat.st_mode) ){
 rc = 1; /* It exists and is a real directory. */
   }else if( S_ISLNK(fileStat.st_mode) ){
 Blob content;
+char *zFullName;
 blob_read_link(, zFN); /* It exists and is a link. */
-rc = file_wd_isdir(blob_str()); /* Points to directory? */
+if(*blob_str() != '/') {
+  while( nFN>0 && zFN[nFN-1]!='/' ){ nFN--; }
+} else { nFN = 0; }
+zFullName = mprintf("%.*s%s", nFN, zFN, blob_str());
+rc = file_wd_isdir(zFullName); /* Points to directory? */
+free(zFullName);
 blob_reset();
   }else{
 rc = 2; /* It exists and is something else. */
   }
   free(zFN);
___
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] [PATCH] Improve symlink following of file_wd_isdir()

[bytevolcano]

Fixed patch, an '{' had escaped the other patch somehow.

Index: src/file.c
==
--- src/file.c
+++ src/file.c
@@ -327,24 +327,30 @@
 ** zFilename is a directory -OR- a symlink that points to a directory.
 ** Return 0 if zFilename does not exist.  Return 2 if zFilename exists
 ** but is something other than a directory.
 */
 int file_wd_isdir(const char *zFilename){
-  int rc;
+  int rc, nFN;
   char *zFN;

   zFN = mprintf("%s", zFilename);
-  file_simplify_name(zFN, -1, 0);
+  nFN = file_simplify_name(zFN, -1, 0);
   rc = getStat(zFN, 1);
   if( rc ){
 rc = 0; /* It does not exist at all. */
   }else if( S_ISDIR(fileStat.st_mode) ){
 rc = 1; /* It exists and is a real directory. */
   }else if( S_ISLNK(fileStat.st_mode) ){
 Blob content;
+char *zFullName;
 blob_read_link(, zFN); /* It exists and is a link. */
-rc = file_wd_isdir(blob_str()); /* Points to directory? */
+if(*blob_str() != '/') {
+  while( nFN>0 && zFN[nFN-1]!='/' ){ nFN--; }
+} else { nFN == 0; }
+zFullName = mprintf("%.*s%s", nFN, zFN, blob_str());
+rc = file_wd_isdir(zFullName); /* Points to directory? */
+free(zFullName);
 blob_reset();
   }else{
 rc = 2; /* It exists and is something else. */
   }
   free(zFN);
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] [PATCH] Improve symlink following of file_wd_isdir()

[bytevolcano]

On OpenBSD 6.1, running "fossil uv edit" will result in the
following error:

 unable to create directory /var/tmp

Upon digging through this, I found Fossil was following the "/var/tmp"
symlink that recent OpenBSD versions create:

 lrwxrwx---  1 root  wheel  6 Apr  1  2017 /var/tmp -> ../tmp

Of course, Fossil was trying to find a folder called ../tmp", but
it doesn't exist, and so the code cascades into the above error.

This change allows the symlink to be followed correctly, and Fossil
will attempt to test "/var/../tmp" (ie. /tmp) in the above example.

This succeeds, and also has a check in case the symlink points to
an absolute path (beginning with '/').

Index: src/file.c
==
--- src/file.c
+++ src/file.c
@@ -327,24 +327,30 @@
 ** zFilename is a directory -OR- a symlink that points to a directory.
 ** Return 0 if zFilename does not exist.  Return 2 if zFilename exists
 ** but is something other than a directory.
 */
 int file_wd_isdir(const char *zFilename){
-  int rc;
+  int rc, nFN;
   char *zFN;

   zFN = mprintf("%s", zFilename);
-  file_simplify_name(zFN, -1, 0);
+  nFN = file_simplify_name(zFN, -1, 0);
   rc = getStat(zFN, 1);
   if( rc ){
 rc = 0; /* It does not exist at all. */
   }else if( S_ISDIR(fileStat.st_mode) ){
 rc = 1; /* It exists and is a real directory. */
   }else if( S_ISLNK(fileStat.st_mode) ){
 Blob content;
+char *zFullName;
 blob_read_link(, zFN); /* It exists and is a link. */
-rc = file_wd_isdir(blob_str()); /* Points to directory? */
+if(*blob_str() != '/')
+  while( nFN>0 && zFN[nFN-1]!='/' ){ nFN--; }
+} else { nFN == 0; }
+zFullName = mprintf("%.*s%s", nFN, zFN, blob_str());
+rc = file_wd_isdir(zFullName); /* Points to directory? */
+free(zFullName);
 blob_reset();
   }else{
 rc = 2; /* It exists and is something else. */
   }
   free(zFN);
___
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-NG Bloat?

[bytevolcano]

On Wed, 22 Nov 2017 21:35:31 -0700
Warren Young  wrote:

> The Fossil vs Git UI situation has been studied before.  There’s a
> tremendous amount of logical mismatch between the two, such that
> commands for one often cannot be translated 1:1 to the other.
> 
> Just as a single example:
> 
> $ fossil ci
> 
> is not at all the same thing as 
> 
> $ git commit
> 
> A better approximation is:
> 
> $ git commit -a && git push
> 
> And even then I’m sure I’m missing some details.
> 
> Now, here we have an example where Fossil is far clearer, as is the
> typical case, but that won’t make all the Git fans you show this to
> squee and insist that their projects switch to Fossil.
> 
> I’m reporting results here, not speculating.  I’ve tried it, and some
> kind of dismissal is almost always the result.  Why do you suppose
> that is?

I'm not saying there's anything wrong with the UI. In fact one of the
biggest reasons I started off with Mercurial was that Git was unusable
for me at the time. Then I came across Fossil which worked even better
than Mercurial. UI wise, Fossil is a clear winner in my books. However
my books aren't someone elses' books.
 
> What keeps these people using Git are network effects.  Most people
> decide that it’s better to put up with its horrible CLI or tie
> themselves to proprietary GUIs/web services — most prominently,
> GitHub — rather than lose out on all the benefits they get by being
> in the Git world.
> 
> We’ve been to this party before.  Linux vs Windows,
> Pascal/D/ObjC/Go/Rust/... vs C, etc., etc.  “Better” doesn’t always
> win.

And in that case, adding Git support to Fossil is unlikely to increase
its user base much. I vaguely recall Mercurial trying that, and this
didn't help them much, even though Mercurial is much easier to use than
Git.

> I’d say I have normal users: they want maximum results for minimum
> effort.
> 
> As do I.  Since I run the project server, what I say generally goes,
> but I ignore my users’ wishes at peril of losing my user base, thus
> risking a waste of my time writing software that no one will use.
> 
> There is not black or white here.  There is only gray.

They want maximum results for minimum effort? That may be normal, but
it's still whiney. Everyone wants this (that's normal), but it's a
difficult balance here between maintainability and servicing users
properly.

> 
> > Fossil supports downloading entire
> > checkins in zip and tarball archives  
> 
> I often end up hand-constructing such URLs for my users to click,
> because they can’t be bothered to dig through the UI to figure it out.
> 
> Here we have a case where Git is actually faster and clearer:
> 
>$ git clone https://example.com
> 
> vs.
> 
> 1. Visit https://example.com
> 2. Click Timeline (and how would my users know to do that?)
> 3. Click checkin ID.
> 4. Find and click Tarball link
> 5. Unpack the tarball
> 
> Then they must do all 5 steps again every time there is a new version
> they want, vs:
> 
>$ git pull

I agree with Zoltan's assessment, in that this is exaggerated.

You can just give users a direct link: https://example.com/tarball
This gives them the latest tarball every time.
The second step on the user's part is extracting the tarball:

  $ curl https://example.com/tarball | tar xzf -
 
> Fossil often can’t get to the simplicity of Git here for two reasons:
> 
> 1. Fossil may not be in the end user’s stock OS package repo.  (e.g.
> RHEL, CentOS.)
> 
> 2. If it is, it may be far too outdated to even work with the central
> repo.  (e.g. Debian, Raspbian.)
> 
> Thus we have to point users at precompiled binaries or instruct them
> in building from source, all of which makes Fossil look even more
> complicated than Git, when day-to-day, the reverse is true.  But you
> only realize that *after* you get Fossil up and running on your
> system.

With all these odds stacked up against Fossil's favor, adding Git/Hg
support as per the proposal is not going to help at all.

> I’m just cheerleading here.  It’s drh’s call what he spends his time
> on.  I trust his judgement.

As much as I agree, this kind of attitude does very little if gaining
extra users is what he wants to do. Then again, perhaps he's not too
bothered, which isn't a bad thing per se.

> By controlling variables, as any good scientific experiment does.
> Here, that means using the same filesystem, disks, etc.  If Fossil is
> reworked to use a Git-compatible pile-of-files repository format and
> performance doesn’t improve, then either:
> 
> 1. That wasn’t the source of the difference, so now we can check it
> off the list of things to look at; or
> 
> 2. There is an important difference in the implementations, which
> will now be easier to find, since both code bases are trying to
> achieve precisely the same end.
> 
> Contrast the state of things today, where comparisons are almost
> pointless, because Git and Fossil are comparable only at a skin-deep
> level.  They’re 

[fossil-users] Redirect capability in test_env page

[bytevolcano]

I noticed this curious gem in the test_env web page, which doesn't have
any obvious use case, and I cannot find any mentions of
"test_env?redirect=..." anywhere in the Fossil code base.

Index: src/style.c
==
--- src/style.c
+++ src/style.c
@@ -1665,14 +1665,10 @@
 @ 
 @ 
 @ %h(blob_str())
 @ 
   }
-  if( g.perm.Setup ){
-const char *zRedir = P("redirect");
-if( zRedir ) cgi_redirect(zRedir);
-  }
   style_footer();
   if( g.perm.Admin && P("err") ) fossil_fatal("%s", P("err"));
 }

 /*

___
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-NG Bloat?

[bytevolcano]

On Wed, 22 Nov 2017 23:43:07 +
Javier Guerra Giraldez  wrote:

> i _have_ used fossil running in a very small MIPS system.  as
> mentioned, it's really nice to pull versioned stuff like
> configurations, HTML, binary blobs.  yes, i used gcc to compile it,
> but what was small two years ago now might be in the same boat as
> that.

GCC has C99 support for a long time: https://gcc.gnu.org/c99status.html

> all those features have zero impact on the generated machine code.

Apart from inline functions and postponed variable declarations. Even
if other features don't have impact on generated machine code, they can
make the code neater.

> > What sort of weird targets does SQLite run on which require the use
> > of a very old (or broken) compiler that can't handle any C99
> > features?  
> 
> MS Visual Studio

That compiler will only work on Windows, and only compiles for Windows.
Hardly a weird target that requires a compiler that can't handle the
basic C99 feature set I mentioned earlier.

In fact the latest MS Visual Studio has been gaining C99 support since
2013, and IIRC is fully compatible since 2015. There are still better
compilers out there such as Pelles C and Open Watcom (which also has
Win16/MS-DOS support) can do better.
___
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-NG Bloat?

[bytevolcano]

On Wed, 22 Nov 2017 17:30:10 +
Javier Guerra Giraldez  wrote:
> why not?  fossil makes for a neat deployment client!  yes, it can also
> be done with just an http client, but still is a nice option to have.

Because people do not use compilers on such systems, but rather, they
use other systems that can compile for the target system.

> but i haven't seen any reason to promote a language switch.   nice as
> they are, C11 features make only easier development; not better code,
> much less any performance improvement or any user-visible advantage.

I am not suggesting a language switch (C11 is still C) and I'm also
not suggesting just use C11 for the sake of it. Rather, I am suggesing
using modern C features to clean up the code and allow the compiler to
optimise it better. For example, postponed variable declarations,
inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
it's all basic C99 functionality which has been around for 18 years.

> SQLite _is_ used on lots of weird targets, and there's much shared
> code, and most importantly, shared code style.  introducing an
> artificial split between them doesn't seem a good use of developer
> time.

What sort of weird targets does SQLite run on which require the use of
a very old (or broken) compiler that can't handle any C99 features?
___
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-NG Bloat?

[bytevolcano]

On Tue, 21 Nov 2017 16:42:56 -0700
Warren Young  wrote:

> > This seems more like a complaint about the user interface.  
> 
> How does that observation get us to a different solution?

Because you then focus on tweaking the UI to make it better, rather
than just stuffing support for other VCSes because of a few complaints
about the UI.
 
> If someone has been using Git for years and I point them at my fine
> Fossil repository, they’re not going to be happy switching, even if
> they do eventually agree that Fossil is better.  That transition cost
> must still be paid.
> 
> What many of my public repos’ users want is Git, and I’m refusing
> (today) to give it to them.
> 
> This proposed feature set might well fix that problem, with zero
> effort on my part.

You clearly have very whiney users. Fossil supports downloading entire
checkins in zip and tarball archives, so your users can just do that.
As far as I can tell, there is no problem. They can just download
Fossil and clone, then export to Git. It may be lossy, but Git!=Fossil.

> 
> What is your alternative?  Force the world to switch to Fossil?  Tell
> the Git fans to pound sand?

My alternative is to just use the right tools for the job. Sometimes
that is Fossil, sometimes that is Git, and sometimes that is Subversion.

> This proposal seems like a good way to enlarge the Fossil user base
> by leveraging the same network effects that today work against Fossil.

So you are suggesting compromise Fossil's code maintainability and
simplicity just for the sake of marketing values?

> 
> > Subversion should implement native Git support,
> > and Mercurial should implement native CVS support.  
> 
> The other VCSes will have to come to whatever accommodation with the
> realities of the Git network effects their developer communities are
> willing to strive for.

And Fossil is no different.

> Someone probably once told him it’s too difficult to implement a
> SQL92 compatible RDBMS, too.

I never said it would be too difficult for him, but rather it would
introduce unneeded code complexity and bloat. If people want to use
Git, they can use Git. Use the right tool for the job.

> > You will also find that tool developers may just get rid of existing
> > Fossil support (if it ever existed) because oh well, Fossil can
> > support Git so no problem.  
> 
> I’d bet there are many more tools that support Git but not Fossil
> today than those that support Fossil, irrespective of whether they
> also support Git.
> 
> If so, it’s a net win, even if it shakes out exactly like you
> suppose, which it won’t.

What I was trying to say here is that just implementing support for
every rinky-dink VCS out there won't expand Fossil's user base by much.
Those that want Git will use Git, those that want Subversion will use
Subversion.

> 
> > Let's face it, the SQLite single-file storage mechanism has a
> > number of other advantages over the pile-of-files methods, even if
> > performance isn't one of them.  
> 
> I didn’t mean to imply that I thought that was the case, only that we
> can’t know until it’s tested, because science.
> 
> We have some science that shows it’s the other way around:
> 
> https://www.sqlite.org/fasterthanfs.html
> 
> The thing is, we don’t yet know how well that test corresponds to the
> way Git uses the filesystem.  All we know today is that Git tends to
> be faster than Fossil for equal workloads, even when things like
> repo-cksum are accounted for.

And how will you test this out anyway? Git uses the file system,
meaning any performance comparison with Git will depend entirely on
what file system is in use.

> If that seems like a non sequitur with respect to Fossil, I’d be
> interested to see benchmark results that show any common use case
> where Fossil’s performance is dominated by time spent *outside*
> SQLite code.  Lacking such data, I’ll continue to assume that there’s
> little point optimizing Fossil proper.  The same effort spent
> optimizing SQLite and the SQL that Fossil gives to SQLite is time
> better spent.

You make a good point here, and I agree. SQLite is the majority of
Fossil's code base. It may be worth looking at queries to see how they
can be optimised as well.

> If you do come up with such a benchmark, and it involves the network,
> then be sure to account for the time spent waiting for network I/O
> separately, unless reworking Fossil somehow reduces time spent
> waiting on the network.  A 10 ms HTTP transaction where 999 µs of
> that is spent in Fossil and 1 µs is spent in SQLite doesn’t count as
> “dominated by Fossil code.”   Until you get the network time down
> from the 9 ms in this made-up example to more like 3 ms, there’s
> little point worrying about the Fossil contribution to the
> transaction time.

True, but I was thinking more in terms of local working directories
(commit/merge/etc rather than pull/push/sync/etc).

> Infrastructure software like Fossil generally needs to be able to
> 

Re: [fossil-users] Fossil-NG Bloat?

[bytevolcano]

On Mon, 20 Nov 2017 17:44:49 -0700
Warren Young  wrote:

> On Nov 20, 2017, at 4:57 PM, bytevolc...@safe-mail.net wrote:
> > 
> > Why add more complexity and bloat to the Fossil core?  
> 
> Because interoperability.  One of the major arguments against using
> Fossil is that it’s largely a one-way transition today, which messes
> up muscle memory for both Fossil partisans and for partisans of other
> VCSes.

This seems more like a complaint about the user interface.

> I’ve had people wish for Git access to my largest public Fossil
> repository multiple times, and it’s got a pretty small community.  I
> imagine providers of large public Fossil repos get this complaint all
> the time.

Of course. So next up, Subversion should implement native Git support,
and Mercurial should implement native CVS support.

> 
> fossil export solves this to only a limited extent.  The translation
> is lossy in the primary direction and even lossier in the reverse
> direction.
> 
> I assume the idea here is to reduce the impedance mismatch between
> the formats.

The idea being proposed appears to be that Fossil repositories should
be able to store artifacts in multiple different formats, which will
only be a disaster since the "legacy" Git/SVN/CVS clients cannot read
that kind of repository anyway. Thus, this idea is just bloat.

> 
> Also valuable is that developer tool support generally goes git > hg
> > svn > cvs > fossil, often stopping at git or hg.  If Fossil could
> > offer a Git or Hg view of the same data and take pushes losslessly
> > via that same format, we wouldn’t have to keep blindly hoping that
> > tool developers would add Fossil support.

You will also find that tool developers may just get rid of existing
Fossil support (if it ever existed) because oh well, Fossil can support
Git so no problem.

> 
> There’s precedence for having multiple backends, most notably svn.
> If nothing else, this will let us make apples-to-apples performance
> comparisons.  Is git’s speed advantage due in any meaningful part to
> its use of a pile-of-files repo format, or is SQLite’s single-file
> indexed declarative access approach superior?  We can largely only
> speculate today.  With this change, we can KNOW.

Adding tightly integrated support for other VCS software may just give
you an apples-to-gorillas comparison instead, since the overhead of the
proposed feature set will slow Fossil down even more and skew the
result. Let's face it, the SQLite single-file storage mechanism has a
number of other advantages over the pile-of-files methods, even if
performance isn't one of them.

There are other means of optimisation that can be used first.

Profiling and optimising the most frequently called routines will help.
Not coding like it's 1989 and use modern C99/C11 (eg. postpone variable
declarations, declaring variables in a for(...) loop, uint_XX_t,
inline, etc) will also help.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] [PATCH] Populate user category "Last Change" properly.

[bytevolcano]

In setup_ulist web page, the "Last Change" column will never be
populated because of an off-by-one error.

Index: src/setup.c
==
--- src/setup.c
+++ src/setup.c
@@ -178,11 +178,11 @@
 );
 while( db_step()==SQLITE_ROW ){
   int uid = db_column_int(, 0);
   const char *zLogin = db_column_text(, 1);
   const char *zCap = db_column_text(, 2);
-  const char *zDate = db_column_text(, 4);
+  const char *zDate = db_column_text(, 3);
   @ 
   @ %d(uid)
   @ %h(zLogin)
   @ %h(zCap)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] [PATCH] Move #ifdef guards up

[bytevolcano]

One of the #ifdef guards in src/utf8.c can be moved up since the
fossil_utf8_to_console() function is only ever called on WIN32
platforms anyway.

BTW, many guards are "#if defined(_WIN32)" rather than "#ifdef _WIN32"
but I'm not sure what is preferred here.


Index: src/utf8.c
==
--- src/utf8.c
+++ src/utf8.c
@@ -305,16 +305,16 @@
 ** Display UTF-8 on the console.  Return the number of
 ** Characters written. If stdout or stderr is redirected
 ** to a file, -1 is returned and nothing is written
 ** to the console.
 */
+#ifdef _WIN32
 int fossil_utf8_to_console(
   const char *zUtf8,
   int nByte,
   int toStdErr
 ){
-#ifdef _WIN32
   int nChar, written = 0;
   wchar_t *zUnicode; /* Unicode version of zUtf8 */
   DWORD dummy;
   Blob blob;

@@ -352,9 +352,7 @@
 zUnicode + written, size, , 0);
 written += size;
   }
   fossil_free(zUnicode);
   return nChar;
-#else
-  return -1;  /* No-op on unix */
-#endif
 }
+#endif
___
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-NG Bloat?

[bytevolcano]

In light of the new wiki article:

https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG

I suggest not getting too carried away with adding features after
features. Most of the stuff here seems good, but everything under
"Support For Multiple VCS Formats" seems unnecessary.

Fossil should only work with Fossil's native format, and have
import/export tools do the rest. A repository with "a mixture of
artifacts in various formats" is asking for trouble. No other program
will be able to read such a repository anyway, so what is the point?

Why add more complexity and bloat to the Fossil core?
___
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] JSON API

[bytevolcano]

Hello Stephan,

On Sun, 12 Nov 2017 15:45:37 +0100
Stephan Beal  wrote:
> i'm the original developer of the JSON API, but a severe, long-term
> case of RSI (since Dec. 2014) has forced me to retire from my open
> source work (except for occasional tiny patches), thus i don't
> personally work on it any more. It's unclear if/when my damaged elbow
> nerves will ever recover, so i can't make any code-related
> commitments (my left elbow is still not fully recovered after an OP
> last May, and i've got a second operation planned for early 2018 to
> try to alleviate the problem in the right elbow).

Hopefully your recovery goes well. Good luck with next year's surgery.

> 
> That's not to say that the JSON API is off-limits to other
> developers! i would love to see someone take it over and actively
> work on it.

> Not abandoned, just not currently actively developed.

Sure, where I was coming from is that there are several unimplemented
interfaces, and the documentation isn't even on the Fossil wiki, and is
disabled at compile-time by default, so it just looked like a failed
experiment with its code still in Fossil, just in case.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] JSON API

[bytevolcano]

Good day to you all,

I have been trying to find up-to-date information about the JSON API
built into Fossil. Is there any plans on moving forward with this?

The latest information I could find is a link to a document on Google
Docs in a mail dated back in 2013 or so, and I cannot tell when the
document was last updated. The last time it was mentioned on the
official fossil-users mailing list was in March 2017
(https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24857.html)
but simply mentioned the same Google Docs document:
https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view

There is very little mention on the wiki hosted on the Fossil site, and
a handful of checkins from early 2017 regarding test cases and
regressions. It looks like these commits are just to allow Fossil to
build with the JSON API enabled at compile time.

Has this API been abandoned? It seems like a nice feature if you
want to develop a custom UI or application that uses Fossil as a
back-end, such as a full-blown wiki, for example.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users