Re: [fossil-users] Incomplete patch with idea for enhancement

[Warren Young]

On Apr 18, 2017, at 8:07 PM, The Tick  wrote:
> 
> I added this patch:
> 
> --- doc.c.orig  2017-03-10 11:07:08.0 -0600
> +++ doc.c   2017-04-17 23:32:03.770418400 -0500
> @@ -49,6 +49,7 @@
> { "\211PNG\r\n\032\n",   8, "image/png"  },
> { "\377\332\377",3, "image/jpeg" },
> { "\377\330\377",3, "image/jpeg" },
> +{ "\0\0\1\0",4, "image/x-icon" },
>   };
> 
>   if( !looks_like_binary(pBlob) ) {
> 
> 
> Now >my< version of fossil show the ICO file also. (I say this patch is 
> incomplete because definitively identifying an ICO file is more that just 
> looking at the first 4 bytes).

Both file(1) magic files I looked at here pretty much just do that.  (CentOS 
and FreeBSD.)  There are elaborations, but they seem entirely concerned with 
parsing out internal details, not making detection more reliable.

I’d call your patch “close enough.”  It’s only got a 1 in 4 billion chance of 
matching something incorrectly for a uniform probability distribution, and a 
much smaller chance than that in practice given the bias towards text file 
types in Fossil repositories.

> My idea was to have a way to specify the mime type on a per-file basis. Or 
> maybe by file extension like the 'encoding-glob', etc. settings?

So far, the one-off policy works pretty well, since typical web browsers don’t 
add new internally-viewable file types that often.  With this move away from 
plugins, the list of viewable file types may be *shrinking* at the moment.

I’m not rejecting the idea, I’m just calling into question its ROI.

How about if Fossil just loads the platform MIME type DB and uses that?  Many 
*ix type platforms have one, such as CentOS’s /etc/mime.types or FreeBSD’s 
/usr/local/share/mime/globs.

Writing the parsers would be a bit more work than just cloning the *-glob 
infrastructure and injecting the results into src/doc.c, but it would mean 
Fossil wouldn’t have to adjust its internal DB ever again.

The only open question in my mind is what to do on Windows?  IIS must have such 
a DB, but how does a program access it?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Incomplete patch with idea for enhancement

[The Tick]

I'm very new to fossil so maybe there's a way to do this already.

After I had committed a PNG to a fossil repository then fossil UI showed 
the PNG itself instead of just its name. Pretty nice! After adding an 
ICO, fossil just said it was XXX number of bytes. After looking at the 
source, I added this patch:


--- doc.c.orig  2017-03-10 11:07:08.0 -0600
+++ doc.c   2017-04-17 23:32:03.770418400 -0500
@@ -49,6 +49,7 @@
 { "\211PNG\r\n\032\n",   8, "image/png"  },
 { "\377\332\377",3, "image/jpeg" },
 { "\377\330\377",3, "image/jpeg" },
+{ "\0\0\1\0",4, "image/x-icon" },
   };

   if( !looks_like_binary(pBlob) ) {


Now >my< version of fossil show the ICO file also. (I say this patch is 
incomplete because definitively identifying an ICO file is more that 
just looking at the first 4 bytes).


My idea was to have a way to specify the mime type on a per-file basis. 
Or maybe by file extension like the 'encoding-glob', etc. settings?


Perhaps this is already possible?
___
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] REST API and client for same

[Paul Hammant]

OK, so I don't think there's any interest in this beyond me :-(

On Wed, Apr 5, 2017 at 1:58 PM, Paul Hammant  wrote:

> I don't really need Fossil to become an application server.  I just need
> it to handle CRUD over HTTPS on specific resources, and have configurable
> permissions for that.  Though TH1 scripts exist, I'd not use them, nor
> anything that purports to be JSP/ASP application scripting model. I'd not
> need them, if I've shifted my application code to JavaScript.
>
> Just like for CouchDB in a "backend as a service" configuration, *in-house non
> financially critical* *applications* are the type of apps that would fit
> well. CouchDB implements CORS
> 
> which all the modern browsers are savvy with too, and that is a partial
> answer to XSS/CSRF concerns.
>
> Anyway - I'd want everything that CouchDB does in the BaaS
>  model, but lose the
> query capability if I had to. I'd want to gain security features that CouchDB
> doesn't do by default  
> ("AdminParty"
> and HTTP *off* by default, HTTPS *on* by default).  Why VCS - who
> wouldn't want to be able to checkout documents as a set, perform functions
> on them, and commit them back as a set, atomically?
>
> - Paul
>
> - Paul
>
> On Tue, Apr 4, 2017 at 2:53 PM, Warren Young  wrote:
>
>> On Apr 4, 2017, at 11:24 AM, Paul Hammant  wrote:
>> >
>> > > I have little need for such a thing myself, so I’m just throwing this
>> idea out
>> > > there for anyone who thinks it looks like a good itch to scratch.
>> >
>> > I do have a need for this class of use. My thread "Fossil as an app
>> server" (nearly a week ago on this list) is in the same direction.
>>
>> Only in the vaguest sort of way.
>>
>> My idea is just that you should be able to replace the fossil binary as a
>> client with a series of HTTP calls, which lets you replace
>> fossil-the-client without duplicating all of its internal functionality.
>>
>> This idea of turning Fossil into a generic application server is off on a
>> completely wild tangent from that point.
>>
>> While thinking about this sort of thing, consider the XSS problem just
>> brought up on the mailing list.  To me, “generic application server”
>> implies multiple independent — possibly mutually-untrusting — applications
>> running on a single platform.  So, you’d better solve the XSS problem first.
>> ___
>> 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] Feature request: local .fossil-ignore

[Ross Berteig]

On 4/18/2017 2:29 PM, rosscann...@fastmail.com wrote:
@Barry: True, but it's clumsy, since you have to specify every path, 
in full, in the global ignore-glob file. If you move a subproject to a 
different location in the directory tree, you have to remember to 
update the ignore-glob file.


No, the wild cards in the glob can match any part of the path. You can 
ignore "*/_build/*" and that will ignore any folder named _build and all 
its descendants anywhere in the tree except at the root of the workspace.


--
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] Feature request: local .fossil-ignore

[Martin Gagnon]

On Wed, Apr 19, 2017 at 07:29:42AM +1000, rosscann...@fastmail.com wrote:
> @Barry: True, but it's clumsy, since you have to specify every path, in
> full, in the global ignore-glob file. If you move a subproject to a
> different location in the directory tree, you have to remember to update
> the ignore-glob file.
> 

That's true, but in some cases, the fossil ignore-glob is more useful.

Example:
*/obj/*
*.o
*.bak

Which will works for the whole repo.

I often do something like this to create or update my ignore-glob file: 

fossil extra >> .fossil-settings/ignore-glob

vim .fossil-settings/ignore-glob
   
   (cleanup the content added by "fossil extra" by replacing by the
   most general glob pattern possible to get rid the extras and
   keep some individual file from the list if needed, for the
   exceptions)


But I agree that the per directory ignore file have it's advantage in
some situations. 

> 
> This is something I miss from Subversion (and Git, too, apparently) -
> the ability to set an ignore list for *just this directory*, and have
> that ignore list move around with the directory automatically.
> 
> 
Also true for the venerable CVS (.cvsignore files).

   [snip]

-- 
Martin G.
___
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] Feature request: local .fossil-ignore

[Ross Berteig]

On 4/18/2017 2:21 PM, Barry Arthur wrote:
This is already possible with pathed globs in your 
.fossil-settings/ignore-glob file.


On 19 April 2017 at 01:10, David Mason > wrote:


I have had to use Git for something this semester.  It was mostly
a failure and I'll find a way to use fossil going forward.

That said, I noticed one feature of Git that was very useful, and
I'd love to see in Fossil.  In Git, you can have a .gitignore file
in any directory and it applies to that directory and nested
sub-directories.  This is very handy, especially for build
directories and executables.  For example, if I have a directory
where I'm working on a program foo.c, I can (and do) exclude *.o
in my .ignore-glob, but I don't really want to put "foo" there
because I might have a file foo in another directory that I *do*
want in the repo. If I could put "foo" in a .fossil-ignore file -
in that particular directory - that would be very convenient. It
would also be useful in a target directory (for Rust/cargo) or a
_build directory (for Elixir/mix), where the only file you'd add
to the repo would be the .fossil-ignore, where you'd put "*" so
that nothing would be added.



It isn't well documented (yet, working on that right now) but the globs 
are matched against the whole pathname of each file. Also, wild cards 
are allowed (unlike Unix or Windows) to match path separators. This 
allows a number of common cases to be easily handled in the single 
.fossil-settings/ignore-glob file, stored alongside the other versioned 
settings.


So a glob like "*.bak" or "*.o" works on files in the entire tree 
because the "*" matches the path separators, just as a glob like 
"*/_build/*" would match all the files in any "_build" folder below the 
workspace root. As long as names are reasonably unlikely to collide, 
that sort of glob can be set once and never need further maintenance 
even if you re-organize or add a second thing to build.


Another thing that is not really said explicitly is that the ignore-glob 
setting is mostly just a suggestion to fossil. It sets the default 
behavior of some commands, but can usually be overridden either by 
naming a file explicitly on the command line or by changing the entire 
setting with the --ignore option to a command. Specifically, the 
ignore-glob is not a kind of automatic "fossil rm".


I frequently include "*.dll" in my ignore-glob. If I needed to check in 
some specific DLL (perhaps it was provided by a vendor as a binary only) 
I can still say "fossil add some.dll" and then it will be picked up by 
the next commit. Similarly if there were some file that an IDE 
(stupidly) located in their build output folder that must be tracked, 
you could still say "fossil add tool/_build/valuable-file.txt" even with 
"*/_build/*" ignored.


One thing that is missing is the ability to have comments in the 
ignore-glob to explain why some obscure file is being ignored. (Also 
thinking about that, there are issues, but once settled it should not be 
difficult.)


There has been discussion in the past of the merits of a single 
project-wide ignore-glob vs individual files scattered in the tree. I 
don't recall the details, but we settled on the single file in full 
knowledge of it being different from other DVCS systems.



I think this would be a nice little project for someone who wants
to delve into the fossil codebase. I would, but I'm *way*
over-committed at the moment.



As usual, a working patch adds a *lot* of weight to an argument for a 
feature.


--
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] How to deal with obsolete stuff in a repository

[Warren Young]

On Apr 17, 2017, at 8:26 PM, The Tick  wrote:
> 
> On 4/17/2017 9:11 PM, Ross Berteig wrote:
>> Try to avoid
>> preserving a version number as part of the folder names in the workspace
>> even if your upstream does that to you.
> 
> So I've goofed up by putting freetype-2.7.1/ and others into the repository?
> 
> I guess I had assumed that I could just add, say, freetype-2.8 some day and 
> change the master makefile as appropriate while making any other changes that 
> might be necessary to accommodate the new library version.

Certainly you *can* do this, but it gives the very problem you started the 
thread with, which is that you end up with duplicate copies of all files in the 
depended-upon library, even if those files have not changed.

If you unpack the library into a freetype/ directory and update to new versions 
in place, not only do unchanged files not take more space, Fossil’s delta 
compression is likely to store the files that *do* change in far less space.

One other thing you might want to consider is simplifying the depended-upon 
project’s build system.

Ideally, you’d merge the depended-upon project’s build rules into your existing 
build system to avoid the Recursive Make Considered Harmful problems:

http://aegis.sourceforge.net/auug97.pdf

That takes extra work, so if you’re unwilling to do that, then at least 
consider reverting the upstream project’s build system to a more “core 
developer” state.  If the upstream project uses Autotools, for example, you’d 
check in only configure.ac and Makefile.am, not any of the files that are built 
from them: configure, aclocal, etc.  The upstream project may have a bootstrap 
or autogen.sh type of script which rebuilds these generated files; call that 
from *your* top-level build system when you bootstrap *it*.

> I guess I'd need a readme or something to tell what the current version is?

Most third-party libraries contains a ChangeLog or VERSION or NEWS type file 
which gives version info.  Your checkin message committing the new version 
should also contain this, as should your parent project’s ChangeLog file.

> stuff gets lost in all the commit messages.

That’s one of many reasons why you should distill your commit messages into a 
ChangeLog as part of every release: to document such things.  My rule for 
writing ChangeLog entries is that everything that could affect behavior the end 
user can see goes into the ChangeLog.

The ChangeLog should be much shorter than the output of “fossil timeline” 
because you’ll be removing all the checkins for behind-the-scenes changes, as 
well as frequently distilling multiple detailed checkin messages into a single 
brief user-focused ChangeLog entry.

That gets you a file you can trivially search afterwards.  I end up going back 
to my ChangeLogs roughly monthly to answer questions like “When was feature Foo 
added?”
___
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] How to deal with obsolete stuff in a repository

[Ross Berteig]

On 4/17/2017 7:26 PM, The Tick wrote:

.
So I've goofed up by putting freetype-2.7.1/ and others into the 
repository?


"Goofed up" is too strong. "Picked a different way to do it" is more 
accurate. There are tradeoffs and a lot of personal preference involved.


I guess I had assumed that I could just add, say, freetype-2.8 some 
day and change the master makefile as appropriate while making any 
other changes that might be necessary to accommodate the new library 
version. Then, I would do a commit after verifying everything still 
works.


You certainly can do it that way. When you replace freetype-2.7.1 with 
freetype-2.8, just rm -rf the old one and unzip the new one.


Fossil addremove will mark the entire old tree as no longer tracked and 
add the new tree.


What you lose doing it this way is any continuity of history of files in 
both versions. But that might not really be a loss. There's an internal 
storage cost too, in that fossil might not store the new version as 
efficiently as it could have, but that almost never matters given 
today's price per byte of disk, and that source code is already highly 
compressible by fossil's internal use of zlib.


If the library's name should not contain a version string, I guess I'd 
need a readme or something to tell what the current version is? I 
guess the commit message could mention that, but stuff gets lost in 
all the commit messages.


You can also tag the checkin with the library version. Probably should 
do that anyway, it can help you locate where in the timeline you 
introduced a particular version.


--
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] Feature request: local .fossil-ignore

[rosscanning]

@Barry: True, but it's clumsy, since you have to specify every path, in
full, in the global ignore-glob file. If you move a subproject to a
different location in the directory tree, you have to remember to update
the ignore-glob file.


This is something I miss from Subversion (and Git, too, apparently) -
the ability to set an ignore list for *just this directory*, and have
that ignore list move around with the directory automatically.


+1 for David's idea.





On Wed, Apr 19, 2017, at 07:21 AM, Barry Arthur wrote:

> This is already possible with pathed globs in your .fossil-settings/ignore-
> glob file.
> 

> On 19 April 2017 at 01:10, David Mason  wrote:

>> I have had to use Git for something this semester.  It was mostly a
>> failure and I'll find a way to use fossil going forward.
>> 

>> That said, I noticed one feature of Git that was very useful, and I'd
>> love to see in Fossil.  In Git, you can have a .gitignore file in any
>> directory and it applies to that directory and nested sub-
>> directories.  This is very handy, especially for build directories
>> and executables.  For example, if I have a directory where I'm
>> working on a program foo.c, I can (and do) exclude *.o in my .ignore-
>> glob, but I don't really want to put "foo" there because I might have
>> a file foo in another directory that I *do* want in the repo. If I
>> could put "foo" in a .fossil-ignore file - in that particular
>> directory - that would be very convenient. It would also be useful in
>> a target directory (for Rust/cargo) or a _build directory (for
>> Elixir/mix), where the only file you'd add to the repo would be the
>> .fossil-ignore, where you'd put "*" so that nothing would be added.
>> 

>> I think this would be a nice little project for someone who wants to
>> delve into the fossil codebase. I would, but I'm *way* over-committed
>> at the moment.
>> 

>> ../Dave

>> 

>> ___

>> fossil-users mailing list

>> fossil-users@lists.fossil-scm.org

>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>> 

> _

> fossil-users mailing list

> fossil-users@lists.fossil-scm.org

> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

Re: [fossil-users] Feature request: local .fossil-ignore

[Barry Arthur]

This is already possible with pathed globs in your
.fossil-settings/ignore-glob file.

On 19 April 2017 at 01:10, David Mason  wrote:

> I have had to use Git for something this semester.  It was mostly a
> failure and I'll find a way to use fossil going forward.
>
> That said, I noticed one feature of Git that was very useful, and I'd love
> to see in Fossil.  In Git, you can have a .gitignore file in any directory
> and it applies to that directory and nested sub-directories.  This is very
> handy, especially for build directories and executables.  For example, if I
> have a directory where I'm working on a program foo.c, I can (and do)
> exclude *.o in my .ignore-glob, but I don't really want to put "foo" there
> because I might have a file foo in another directory that I *do* want in
> the repo. If I could put "foo" in a .fossil-ignore file - in that
> particular directory - that would be very convenient. It would also be
> useful in a target directory (for Rust/cargo) or a _build directory (for
> Elixir/mix), where the only file you'd add to the repo would be the
> .fossil-ignore, where you'd put "*" so that nothing would be added.
>
> I think this would be a nice little project for someone who wants to delve
> into the fossil codebase. I would, but I'm *way* over-committed at the
> moment.
>
> ../Dave
>
> ___
> 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] Is there a way to find identical files?

[Sergei Gavrikov]

Tony Papadimitriou wrote:

[snip]


For example, if
/defs.inc is the same as /project1/defines.inc,
and project2/lib.mod is the same as project3/library.inc and 
project4/libroutines.inc,

and docs/mydocs.pdf is the same as project1/docs.pdf,
I would like some simple report like this:

defs.inc
project1/defines.inc

project2/lib.mod
project3/library.inc
project4/libroutines.inc

docs/mydocs.pdf
project1/docs.pdf

(a blank line --or whatever other separator -- simply separates each group)

Ideally from the command line so that I can redirect to a file.


On *nix you would use FDUPES(1) [1] to find duplicate files, e.g.

  fdupes -r project1 project2 project3 project4

Default `fdupes' output is exactly what you looking for. Just install
fdupes using your package manager.

[1] https://linux.die.net/man/1/fdupes

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] Feature request: local .fossil-ignore

[David Mason]

I have had to use Git for something this semester.  It was mostly a failure
and I'll find a way to use fossil going forward.

That said, I noticed one feature of Git that was very useful, and I'd love
to see in Fossil.  In Git, you can have a .gitignore file in any directory
and it applies to that directory and nested sub-directories.  This is very
handy, especially for build directories and executables.  For example, if I
have a directory where I'm working on a program foo.c, I can (and do)
exclude *.o in my .ignore-glob, but I don't really want to put "foo" there
because I might have a file foo in another directory that I *do* want in
the repo. If I could put "foo" in a .fossil-ignore file - in that
particular directory - that would be very convenient. It would also be
useful in a target directory (for Rust/cargo) or a _build directory (for
Elixir/mix), where the only file you'd add to the repo would be the
.fossil-ignore, where you'd put "*" so that nothing would be added.

I think this would be a nice little project for someone who wants to delve
into the fossil codebase. I would, but I'm *way* over-committed at the
moment.

../Dave
___
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] How to deal with obsolete stuff in a repository

[David Mason]

Another option is to create a fossil for the 3rd party libraries, and then
open that fossil --nested in a directory inside your working directory.
Then nothing in that nested directory tree will be part of the main
fossil.  You don't even need to commit to it if you don't want.  Lastly,
when you don't want that version any more, remove the contents, close the
repo and create a new one for the new version of the 3rd-party library.

Nested repositories is one of the things I like best about Fossil.

../Dave

On 17 April 2017 at 22:26, The Tick  wrote:

> On 4/17/2017 9:11 PM, Ross Berteig wrote:
>
>> On 4/17/2017 6:50 PM, The Tick wrote:
>>
>>> I've put a project under fossil. Since it depends on a couple other
>>> libraries, I've also put those into the repository so that I am not
>>> dependent on being able to download those particular versions. Now,
>>> when new versions of those dependent libraries become available, I
>>> want to update my project. I could just add the new versions and
>>> modify my makefile. The problem I see is that over time the fossil
>>> repository is going to get >really< big as it will contain a bunch of
>>> obsolete stuff.
>>>
>>> Is there a way to handle this? I really want to keep the dependent
>>> libraries in the repository since who knows what might happen to
>>> someone else's open source project in the future, and in addition, it
>>> makes my project "self contained".
>>>
>>
>>
>>
>
>> Unzip the new library on top of the old in your workspace. Try to avoid
>> preserving a version number as part of the folder names in the workspace
>> even if your upstream does that to you. That will just confuse life.
>>
>>
> So I've goofed up by putting freetype-2.7.1/ and others into the
> repository?
>
> I guess I had assumed that I could just add, say, freetype-2.8 some day
> and change the master makefile as appropriate while making any other
> changes that might be necessary to accommodate the new library version.
> Then, I would do a commit after verifying everything still works.
>
> If the library's name should not contain a version string, I guess I'd
> need a readme or something to tell what the current version is? I guess the
> commit message could mention that, but stuff gets lost in all the commit
> messages.
>
>
> ___
> 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