Re: [fossil-users] New Tree-View feature requires newer sqlite.

[Joseph R. Justice]

On Tue, Jan 7, 2014 at 4:37 AM, Jan Nijtmans  wrote:

> 2014/1/7 Joseph R. Justice :
>


> > May I ask why that run-time check cannot or should not be made in the
> > release version of Fossil 1.28, rather than immediately after it is
> tagged
> > such that it will only take effect in a release version for Fossil 1.29?
>
> It's fully up to the Fossil-devs what should be the minimum SQLite
> version Fossil is supposed to work with, and when this minimum
> is updated to higher SQLite versions. My proposal is based on
> a SQLite 3.8.3 release in February 2014. If that changes or if
> the Fossil developers want to move forward faster than that,
> it is very well possible. For Cygwin that wouldn't be a problem, as
> SQLite 3.8.2 is already available now as Cygwin package. For
> other OS distributions I don't know, I'll leave it to others to comment on
> that.
>

I fully agree that it's up to the Fossil upstream devs as to what should be
the minimum version of SQLite supported with any given release version of
Fossil, and also as to when the minimum version of SQLite supported should
be changed (and what it should be changed to).

My thought here was that the devs (or at least Dr. Hipp as the architect)
seem to desire to make the minimum supported version of SQLite be 3.8.2
*now*.  If that's so, why make them wait for a full release version of
Fossil (e.g. until development begins for Fossil 1.29) before they can make
that change?  After all, it's the distributions' problem to provide the
SQLite library version Fossil upstream requires, or else to patch Fossil to
work with whatever version of SQLite the distribution is willing to
provide.  (But...  See below for a countervailing point.)



Ummm...  As a sort of aside, I'd like to point out one thing here for the
benefit of the Fossil upstream devs, on the off chance they have not yet
considered it.  It's something I think is a sort of corollary / consequence
of what we're talking about that's obvious when you think about it
carefully, but which might be easy to overlook at a first quick glance.
(Ron Wilson's message kind of refers to this, but does not state it
explicitly.)  I'd like to explicitly state it for the record.

Okay.  Again, Fossil upstream devs ARE NOT REQUIRED to support using a
given release version of Fossil with any random old version of SQLite a
end-user (or distribution) wishes to use.  The upstream devs have the right
to say "We only support using this release version of Fossil with at least
version XY.ZZ.Y of SQLite, and will not support using this version of
Fossil with any older version of SQLite".  The upstream devs are (in
general) all unpaid volunteers, and as such have the right to set whatever
limit on support they want to set.

However...  Just as are the Fossil upstream devs, the developers /
packagers of a given FOSS Unix/Linux distribution *are* *also* (in general)
unpaid volunteers, and as such *do* *also* have the right to set whatever
limit on support *they* (the distribution developers / packagers) want to
set!

In particular, *they* have the right to say "We only support SQLite with a
maximum release version of BL.EG.H, and any software which requires a
version of SQLite more recent than this version is not supportable by us
and we will not package and distribute it in our current version of the
distribution".  The distributions ARE NOT REQUIRED to support or distribute
software which needs any random new version of SQLite a developer wishes to
use!

This means that if the minimum supported version of SQLite the Fossil
upstream devs require for their new release version is XY.ZZ.Y, and the
maximum supported version of SQLite the distribution developers will
provide for their current release version of the distro is BL.EG.H, and
XY.ZZ.Y > BL.EG.H, then the new release version of Fossil will not be made
available for that version of the distribution (at least until they raise
their maximum supported version of SQLite), and the new release version of
Fossil may not even be *useable* on that version of the distribution!

Insofar as the Fossil upstream devs *desire* their current version of
Fossil to be packaged and distributed by the various distributions (as
opposed to requiring end-users to compile / install Fossil on their own),
*this* is the problem of Fossil upstream -- to limit themselves to using
only versions of libraries which are actually available within the various
distributions (the major ones anyway) they want to have distribute their
software.

Now, I'll grant that Fossil, by its intrinsic nature and primary intended
target audience (e.g. that it is a software development tool intended for
use by software developers), isn't as constrained by this as would be an
application intended for use by typical non-technical end-users, such as
say an office productivity application or a financial / bookkeeping
application, or a game, or whatever.  Fossil can say "you're a developer,
you know how to compile software on your ow

Re: [fossil-users] ckout for diff in web interface

[Richard Hipp]

On Tue, Jan 7, 2014 at 6:50 PM, Ron Wilson  wrote:

> The embedded document feature allows for previewing the checked out copy
> of the document in the web interface. How hard would it be to support
> similar capability in the file diff feature?
>
> Something like:
>
> http://localhost:8080/fdiff?v1=c26cba673fdfa670&v2=ckout&sbs=1
>

It ought to be easy.  But because of the way the diff logic is implemented
it is difficult.  There needs to be some refactoring of the diff logic
first.  Then this will be an easy addition.



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


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] ckout for diff in web interface

[Ron Wilson]

The embedded document feature allows for previewing the checked out copy of
the document in the web interface. How hard would it be to support similar
capability in the file diff feature?

Something like:

http://localhost:8080/fdiff?v1=c26cba673fdfa670&v2=ckout&sbs=1

Thanks
___
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] New Tree-View feature requires newer sqlite.

[Jan Nijtmans]

2014/1/6 Jan Nijtmans :
> (4) Immediately after the fossil 1.28 release, add a runtime-check
>  for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add
>  "WITHOUT ROWID" to whatever SQL statement it is useful.
>  Unconditionally!

Implementation here:
   

Thanks, Joe! That's exactly what I meant, and which allows
the (ugly) condition to be removed!

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

Re: [fossil-users] ChiselApp ChangeOver Complete

[Gour]

On Tue, 7 Jan 2014 19:48:25 +0100
Remigiusz Modrzejewski 
wrote:

> Why on earth would you give this kind of information in plaintext to
> any third party? Even when you trust the person, there are so many
> things that can go wrong in this setup...

Don't worry...it's not simple plaintext, but I agree, it can go wrong.


Sincerely,
Gour

-- 
He who is satisfied with gain which comes of its own accord, who 
is free from duality and does not envy, who is steady in both 
success and failure, is never entangled, although performing actions.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] ChiselApp ChangeOver Complete

[Remigiusz Modrzejewski]

On Jan 7, 2014, at 18:51 , Gour wrote:

> Hmm, in my case I'm considering repo having some of my config files
> which, among other things, contain my email passwords etc.

Why on earth would you give this kind of information in plaintext to any third 
party?
Even when you trust the person, there are so many things that can go wrong in 
this setup...


Kind regards,
Remigiusz Modrzejewski



___
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] OT: TH1 shell

[Ron Wilson]

Thanks. It is useful for testing logic interactively.


On Sun, Jan 5, 2014 at 1:15 PM, Sergei Gavrikov
wrote:

> Hi
>
>   http://chiselapp.com/user/sg/repository/thsh/index
>
> it is a tiny TH shell. Main goal was to keep original Fossil TH core
> (th.c and th_lang.c) without any changes and provide TH1 shell with
> alone source (th_shell.c, 391 lines in C). Only new one command was
> added [source] to interact with system, and a few TCL-like globals,
> argv0, argv (if that specified), th_interactive, and th_version.
>
> The main function to read TH sources is Th_EvalFile(). Even interactive
> prompt uses it, `thsh' in interactive mode just does process an input
> from stdin with Th_EvalFile().
>
> The shell can report about errors on exit more verbosely like TCL does
>
>   $ echo foo | thsh
>   no such command:  foo
>   while executing
>   foo
>   (line 1)
>
> or
>
>   $ echo foo > foo
>   $ thsh foo
>   no such command:  foo
>   while executing
>   foo
>   (file "foo" line 1)
>
> As ::argv0, ::argv are supported by default, sha-bang scripts work as
> expected (!# /usr/bin/env thsh).
>
> Interactive shell knowns how to deal with two globals ::th_prompt1 and
> ::th_prompt2 if that set, default `thsh' prompt is "% "
>
>   % set ::th_prompt1 [list puts {th> }]
>   puts {th> }
>   th> proc hello args {
> set hello hello
>   }
>   th> hello
>   hello
>   th>
>
> About [info complete]. TH lacks this command, but if Th_Eval() returns
> (rc==TH_ERROR && nResult==0) this means that there was no close brace,
> quote, or bracket in a program and this fact was used to build simple
> interactive shell.
>
> In 'Th1 shell' project I also use `makeheaders' and `translate' *AS IS*.
> Those programs are neat code filters/generators! With `translate' you
> can easy to add new TH procedures or embed TH code in your C sources.
>
> Once again, my goal was to use TH core without any modifications, so it
> should be easy to keep the shell up to date:
>
>   cp ../fossil/src/th.[ch] ../fossil/src/th_lang.c src/
>   make
>
> TH1 shell is really tiny shell (static build with musl libc)
>
>   $ size -t bld/*.o
>  text  data bss dec hex filename
>  6128 0   0612817f0 bld/th_lang.o
> 13124   432   0   1355634f4 bld/th.o
>  2943 8   42955 b8b bld/th_shell.o
> 22195   440   4   22639586f (TOTALS)
>
>   $ size thsh
>  text  data bss dec hex filename
> 44693   8403552   49085bfbd thsh
>
> and you can use TH by its first appointment, test/glue code in embedded
> systems. At least `thsh' (IMHO) provides more comfortable way to run TH
> scripts on *nix than 'fossil test-th-eval', of course, I may be wrong.
>
> Please, excuse this OFF-TOPIC. I thought that `thsh' would help someone
> to learn or play with TH language.
>
> Sergei
> ___
> 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] ChiselApp ChangeOver Complete

[Gour]

On Tue, 7 Jan 2014 09:17:32 -0800
Andreas Kupries 
wrote:

> Repositories can be marked as private, preventing their listing in the
> set of public repos. This only hides them from general view. You still
> have to set the permissions correctly for your situation so that only
> people who you allow to can log in, in case somebody manages to find
> the name of your repo by other means.

Hmm, in my case I'm considering repo having some of my config files
which, among other things, contain my email passwords etc.


Sincerely,
Gour

-- 
>From wherever the mind wanders due to its flickering and unsteady 
nature, one must certainly withdraw it and bring it back under 
the control of the self.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] ChiselApp ChangeOver Complete

[Andreas Kupries]

Repositories can be marked as private, preventing their listing in the
set of public repos. This only hides them from general view. You still
have to set the permissions correctly for your situation so that only
people who you allow to can log in, in case somebody manages to find
the name of your repo by other means.

On Tue, Jan 7, 2014 at 8:51 AM, Gour  wrote:
> On Tue, 30 Apr 2013 13:22:55 -0700
> Andreas Kupries 
> wrote:
>
>> People visiting the chiselapp.com domain should see, well, a slight
>> difference on the homepage.
>> Backups are listed as weekly now, instead of daily.
>
> Does chiselapp.com offer some free space for private stuff like e.g.
> Bitbucket?
>
>
> Sincerely,
> Gour
>
> --
> One who restrains the senses of action but whose mind dwells on
> sense objects certainly deludes himself and is called a pretender.
>
> http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



-- 
Andreas Kupries
Senior Tcl Developer
Code to Cloud: Smarter, Safer, Faster™
F: 778.786.1133
andre...@activestate.com
http://www.activestate.com
Learn about Stackato for Private PaaS: http://www.activestate.com/stackato

EuroTcl'2014, July 12-13, Munich, GER
___
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] New Tree-View feature requires newer sqlite.

[Ron Wilson]

On Mon, Jan 6, 2014 at 7:52 AM, Jan Nijtmans  wrote:

> at (1): Supporting every SQLite 3.7.x release is madness,
> SQLite 3.7.17 is more than 7 months old now, that should
> be enough time for whatever distribution to upgrade to it.
>

That depends on what other packages are using SQLite and how important the
distro maintainers think the the other packages are. Even when the upstream
devs of a library assert the ABI has not changed, the distro maintainers
tend to be quite conservative about when to update libraries. This is
because even if the ABI has not changed, the results returned may have
changed in a way that breaks something else.

The best way to encourage distro maintainers to stay more up to date with a
library is for the library devs to also provide an exhaustive regression
suite that the distro maintainers can use. And, when the results of any of
these tests change, provide detailed explanations as to why the results
changed.

(I have, in the past, talked to a few distro maintainers. Also, my
company's validation testers demand our (product engineering) test reports
so they can better understand the changes we made.)
___
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] ChiselApp ChangeOver Complete

[Gour]

On Tue, 30 Apr 2013 13:22:55 -0700
Andreas Kupries 
wrote:

> People visiting the chiselapp.com domain should see, well, a slight
> difference on the homepage.
> Backups are listed as weekly now, instead of daily.

Does chiselapp.com offer some free space for private stuff like e.g.
Bitbucket?


Sincerely,
Gour

-- 
One who restrains the senses of action but whose mind dwells on 
sense objects certainly deludes himself and is called a pretender.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


___
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] Issues with Compiling Fossil on Windows with SSL

[Jan Nijtmans]

2014/1/5 JR :
> When I use Cygwin, I get pretty far before getting an error,
> "wbld/sqlite3.o:sqlite3.c:(.text+0x158e7): undefined reference to `_msize'
> // wbld/sqlite3.o:sqlite3.c:(.text+0x3b21): undefined reference to `_msize'"
> followed by bad reloc address in section '.data'.

Using the Cygwin environment, this is how:

1) Download openssl-1.0.1e.tar.gz and unpack it
in Fossil's /compat directory.
2) Make sure you have the mingw64-i686-gcc-core package installed in
Cygwin.
3) type:
 make -f win/Makefile.mingw PREFIX=i686-w64-mingw32- \
   FOSSIL_ENABLE_SSL=1 openssl all

Then have some 10 minutes patience, a new "fossil.exe" will
appear in the top directory.

Or, you can simply download fossil-w32-2013094349.zip
from here: 
The fossil.exe in there is already compiled with ssl support.

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

Re: [fossil-users] tree-view of files

[Michai Ramakers]

On 7 January 2014 00:50, Joel Bruick  wrote:
> Joel Bruick wrote:
>
> I'm going to add some javascript for expanding/collapsing directories. Then
> the tree-view will be practically perfect in every way.
>
> And... done. For added convenience, you can also expand/collapse every
> subdirectory at once by clicking the root directory.

even works very nice when viewed with links; I hadn't expected that, really.

Michai
___
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] New Tree-View feature requires newer sqlite.

[Jan Nijtmans]

2014/1/7 Joseph R. Justice :
> I assume you do not mean here that Fossil v 1.28 should be released
> concurrently with SQLite release v 3.8.3, but instead that Fossil v 1.28
> should be released "when it is ready" on or after the moment that SQLite
> release v 3.8.3 is tagged (be that a day, a week, a month, whenever) such
> that the source for the SQLite release v 3.8.3 can be incorporated within
> the source for Fossil v 1.28.

Yes, sure, that's exactly what I mean.

> May I ask why that run-time check cannot or should not be made in the
> release version of Fossil 1.28, rather than immediately after it is tagged
> such that it will only take effect in a release version for Fossil 1.29?

It's fully up to the Fossil-devs what should be the minimum SQLite
version Fossil is supposed to work with, and when this minimum
is updated to higher SQLite versions. My proposal is based on
a SQLite 3.8.3 release in February 2014. If that changes or if
the Fossil developers want to move forward faster than that,
it is very well possible. For Cygwin that wouldn't be a problem, as
SQLite 3.8.2 is already available now as Cygwin package. For
other OS distributions I don't know, I'll leave it to others to comment on that.

> I would agree that, unless part of the purpose (either explicit or implicit)
> for Fossil's existence is to act as a showcase and testbed for the latest
> and greatest available version of SQLite, there is no need to tie releases
> of Fossil to releases of SQLite.  Release versions of Fossil should be made
> "when they are appropriate" and "when they are ready", which does not
> necessarily have anything to do with the release schedule of SQLite.

I agree. It would be possible to make a Fossil release at any time,
independent from SQLite. As long as Fossil doesn't use any
SQLite features which are not available yet in the latest SQLite
release, either the latest SQLite amalgamation could be shipped
with it, either the latest SQLite trunk amalgamation. The latter
choice means more risk, however small in practice.

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

Re: [fossil-users] general question about multiple source-trees in 1 repo, and recursive diff

[Michai Ramakers]

On 7 January 2014 02:25, Martin Gagnon  wrote:
> On Mon, Jan 06, 2014 at 08:47:43PM +0100, Michai Ramakers wrote:
>> On 6 January 2014 12:53, Martin Gagnon  wrote:
>> ...
>> ah, is that the 'sbs=' option to vdiff? If so, what I meant was: can I
>> somehow only see a list of Modified files, instead of a list of Added,
>> Deleted and Modified? (I am already using 'sbs=0').
>>
>
> I don't think it is possible right now..

alright, thx. The diffless file-list itself (including Added/Removed)
is a big help already.

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