Re: [fossil-users] Why no EXE+DLL like SQLite?

[Ron W]

On Tue, Aug 7, 2018 at 11:47 PM 
wrote:

> Date: Tue, 7 Aug 2018 13:26:04 -0500
> From: Artur Shepilko 
> Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
>
> > project they are working on. Then they use TortoiseSVN to (mostly) commit
> > changes to their documents, sometimes to fetch older versions. Many of
> the
> > users are now making almost daily commits, not just just when making
> > official releases of their documents.
>
> Thank you for sharing this.
> So the add/diff/branch/merge/pull SCM functionality is mostly
> under-utilized or even remains unused.
>

The users do use add when they create a new document. But don't use
branch/merge or diff features (SVN doesn't have pull).


> Basically, the commit is used as an alternative Save.
>

Something like that. The pay-were DMS that was previously used had a GUI
similar to TortoiseSVN, so the usage is very similar.

>
> For such a use-case it'd be more user-friendly if there would be some
> kind of hook into the Save/Save As action (and perhaps Open) to allow
> more transparent VCS interactions.
>

TortoiseSVN, as a Windows Explorer extension, goes halfway in that
Open/Save dialogs summoned by applications are able to access SVN
functions. Since the DMS worked this way as well, the users only had to
adapt to slightly different details.

Taking the further step would be nice. I don't know if/how this could be
done.

>
> BTW, back in the days of OpenVMS, file versioning was supported by OS
> itself, not sure if it has seen a huge demand, other than a need to do
> 'purge' to clean up the directories. But in my experience it was
> mostly an "Undo" feature, still the versioning was fairly transparent
> to the ordinary user. VCS should be able to handle this much better if
> it could be as much transparent to the user.
>

I recall some discussion about adding fsuser support to Fossil so this
could be done. I don't remember if anyone actually implemented it. For MS
Windows, it might be possible to borrow code from Samba to do this.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[Ron W]

On Mon, Aug 6, 2018 at 12:57 PM 
wrote:

> Date: Mon, 6 Aug 2018 11:18:09 -0500
> From: Artur Shepilko 
> Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
> Message-ID:
>
> How would you want to use such a GUI?
> I mean practically what is a non-programmer user workflow that
> involves a VCS interaction via GUI?
>
...

> So my feeling is that no amount of explanation or "instructions" would
> convert such users to make use of a VCS in any form, GUI or not. VCS
> would be perceived as an additional and annoying hoop to jump through.
>
> So I wonder, how do you see your use-cases and GUI VCS workflow?
>

In the case of my employer, transitioning away from a hugely expensive (as
in a large annual license fee) to SVN. Most of the non-programmers like it
much more than the old system. Partly because because a set of documents
could be identified by project code and SVN revision number, instead of a
list of document numbers and revision numbers. with the help of a Power
Shell script from IT, each user has, on their PC, a workspace for each
project they are working on. Then they use TortoiseSVN to (mostly) commit
changes to their documents, sometimes to fetch older versions. Many of the
users are now making almost daily commits, not just just when making
official releases of their documents.

Unfortunately, fossil - and other DVCSs - use less friendly version IDs
than the revision numbers SVN uses. But, I suspect that, after using the
old system, the non-programmers would have welcomed Fossil, even with its
unfriendly version IDs - except for the   lack of a GUI front end to add,
commit and update the user's workspace.

I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think
non-programmers would be unwilling to put up with it. And I seriously doubt
it's a project corporate IT departments would be willing to take on. (The
Power Shell script I mentioned is very simple. It presents the user with a
folder-and-file style interface to select a project, then creates a folder
in the user's projects folder and does a SVN checkout into that folder.

I suspect most corporate IT directors would choose SVN+TortoiseSVN for a
document management system for non-programmers, as an alternative to the
kind document management system my employer used to use. If they did choose
a DVCS, then I think it would be Mercurial+TortoiseHg or git+Tortoisegit,
before they'd consider Fossil.

(As I've mentioned before, my fellow programmers and I, use Fossil for our
day-to-day VCS needs and only use SVN for official releases. We used to use
SVN for day-to-day use, but then the "process gurus" decided to link SVN to
an issue tracking system that makes every commit a 2 hour (or more) task.
We use Fossil "under the radar" and the process gurus seem to think that
our reduced use of SVN is a good thing, so haven't asked why we are using
it less.)
___
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] Why no EXE+DLL like SQLite?

[Ron W]

On Mon, Aug 6, 2018 at 8:07 AM 
wrote:

>
> Date: Mon, 6 Aug 2018 09:18:56 +0800
> From: Steve Landers 
> Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
>
> Put differently, what can’t you do with “fossil ui” that you can do with a
> native client?
>

You can't do:

fossil add
fossil ci
fossil changes
fossil extras

and a few others.

With some IDEs, you can define an interface to the above commands, which
will run the command in a terminal (or command) window using command
templates you define.

For example:
fossil add ${selected_resource_path}
will tell Eclipse to run the "fossil add" command with the workspace
relative path of the currently selected file.
___
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] Perception of Fossil

[Ron W]

On Fri, Jun 15, 2018 at 2:58 PM, 
wrote:

>
> Date: Fri, 15 Jun 2018 13:35:13 -0400
> From: Richard Hipp 
> Subject: Re: [fossil-users] Perception of Fossil
>
> An alternative design sketch:
>
> (4) The pullrequest command creates a "bundle" out of the "anon-patch"
> branch and then transmits that bundle back to the server from which
> the clone originated.
>
> (5) The server accepts the bundle and parks it in a separate holding
> table, but does not merge it or otherwise make it available to average
> passers by.  The server then sends email notifications to developers
> with appropriate privileges to let them know that a pull request has
> arrived.
>

How does the bundle get transmitted to the server? If via a push, making
the bundle seems like extra work..

Would it make sense to enhance Fossil to (optionally) accept only non-truck
branches - and so in a way that makes them purge-able like the branch
created from an imported bundle is purge-able?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 125, Issue 33

[Ron W]

On Thu, Jun 14, 2018 at 5:20 PM, 
wrote:

>
> Date: Thu, 14 Jun 2018 15:12:17 -0600
> From: Warren Young 
> Subject: Re: [fossil-users] Perception of Fossil
>
> On Jun 14, 2018, at 2:51 PM, Ron W  wrote:
> >
> > In another forum I follow,a commented claims that Fossil is designed for
> "cathedral development" not "bazaar development”
>
> That’s the official stance, not some rand-o’s opinion:
>
>https://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
>
> > so would be of little interest to anyone
>
> The conclusion does not follow from the premise, else most software would
> never be written, which we can see from the fact that most software is not
> written in a bazaar style.
>

I agree that "designed for cathedral development" should not imply "little
interest to anyone".

While I dislike "marketing", I know that it is very important. To that end,
I think it might be better to drop mention of "bazaar development" and
"cathedral development". Also, to focus on describing the features that
make Fossil different from git (and, hopefully, better.

For example:

* Robust SQLite datastore
* Branches are "full citizens" (like in Hg), rather than "local
bookmarks"
* Auto-sync (enabled by default) between a clone and its upstream
repository
* ... etc

Basically, make it appealing to "upgrade" to Fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Perception of Fossil

[Ron W]

In another forum I follow,a commented claims that Fossil is designed for
"cathedral development" not "bazaar development", so would be of little
interest to anyone. Unfortunately, the poster did not elaborate on why.

Except maybe possible issues scaling to a large number of contributors, I
don't see how Fossil is less suitable for  "bazaar development" than git or
Hg.

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

Re: [fossil-users] fossil-users Digest, Vol 121, Issue 22

[Ron W]

On Sun, Feb 25, 2018 at 7:00 AM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:

>
> Date: Sun, 25 Feb 2018 04:37:38 -0500
> From: Ron W <ronw.m...@gmail.com>
> Subject: Re: [fossil-users] Minor Issues with Fossil 2.5
>
> > Date: Sun, 25 Feb 2018 10:11:04 +0100
> > From: Florian Balmer <florian.bal...@gmail.com
> > Subject: Re: [fossil-users] Minor Issues with Fossil 2.5
> >
> > I think that the "Last-Modified" header is much easier to handle, as
> > it boils down to parsing a GMT date/time string. And, as already
> > mentioned, clobbering of locally-modified files can be avoided with
> > the timestamp mechanism, this is not possible with an ETag alone.
>

Sorry, I missed the locally modified part.

But, it sounds like you expect it to be overwritten by a newer "version"
from the remote resource.

ETag can handle that case as well.

In the wget.pl wrapper I linked, an ETag "jar" is maintained. So, wget.pl
doesn't care about any local changes. It will only fetch the remote
resource when the resource's ETag value has changed.

Another suggestion: Treat unversioned files like 3rd party "vendor
releases" and keep locally modified copies in a separate location. That
way, the newly fetched copy can't accidently overwrite your local changes.

The ETag is supposed to only change when the content changes Therefore, if
> the Etag you have is not the same as the current ETag on the server - for
> the same resource - then the content is different.
>
> Admittedly, if the server's copy of the resource is changed to an older
> version, the ETag will be different, as well.
>
> So, if you always need the newest version, then modification time is
> needed. But if different is acceptable, then Etag will do that.
>
___
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] Minor Issues with Fossil 2.5

[Ron W]

On Sun, Feb 25, 2018 at 4:11 AM, 
wrote:

>
> Date: Sun, 25 Feb 2018 10:11:04 +0100
> From: Florian Balmer  Subject: Re: [fossil-users] Minor Issues with Fossil 2.5
>
> I think that the "Last-Modified" header is much easier to handle, as
> it boils down to parsing a GMT date/time string. And, as already
> mentioned, clobbering of locally-modified files can be avoided with
> the timestamp mechanism, this is not possible with an ETag alone.
>

The ETag is supposed to only change when the content changes Therefore, if
the Etag you have is not the same as the current ETag on the server - for
the same resource - then the content is different.

Admittedly, if the server's copy of the resource is changed to an older
version, the ETag will be different, as well.

So, if making you always need the newest version, then modification time is
needed. But if different is acceptable, then Etag will do that.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 121, Issue 20

[Ron W]

On Sat, Feb 24, 2018 at 7:00 AM, 
wrote:

>
> Date: Sat, 24 Feb 2018 12:14:33 +0100
> From: Florian Balmer 
> Subject: Re: [fossil-users] Minor Issues with Fossil 2.5dg_
> pca...@mail.gmail.com
> >
> Content-Type: text/plain; charset="UTF-8"
>
> Thinking about HTTP caching twice, the following comes to my mind:
>
> A command line download tool, that unlike a web browser does not keep
> a cache of content and associated ETags, won't be able to calculate
> the ETag for a file it is going to request from a Fossil web server.
>

Someone already made an ETag wrapper for wget:
https://www.w3.org/2001/12/rubyrdf/pack/tests/scutter/wget.pl

If you aren't using Perl, call it like:
perl wget.pl $filename


> ETags are not simple file checksums, and Fossil seems to use the
> following information to generate them:
>
> ///
>

There is no requirement or specification for the value of an ETag, could
use the Fossil artifact hash as the ETag value. Then a script trying to
fetch the file can generate the value from the current copy of the file.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 121, Issue 9

[Ron W]

On Tue, Feb 13, 2018 at 7:00 AM, 
wrote:
>
> Date: Tue, 13 Feb 2018 11:42:59 +0100
> From: Gilles 
> Subject: Re: [fossil-users] Windows GUI that allows diff between two,
> revisions?
>
> Thanks for the tip. Fuel does have an internal web browser:
>
> https://s14.postimg.org/efgcfmwj5/Fossil.Fuel.history.internal.browser.png
>
> If there's no Windows alternative to Fuel, it looks like it's either the
> web UI or the command line.
>
> Is there an easy way to compare two revisions of a file while the
> repository is closed (ie. not a comparison between a revision in the
> repo and a live file in the workspace), possibly using WinMerge, so I
> can easily see what the changes are, check out the latest verison, and
> copy/paste ?
>

In the Fossil "web UI", from the timeline, select a commit. Scroll down to
the file of interest and click on it to show that file's history. In the
"revision graph" (on the left), click the version you want to compare from
(the node will turn red), then the version you want to compare to. This
will display (in the web browser), a differ of the 2 versions.

 To use WinMerge, you need to configure Fossil to use that as the external
diff (or gdiff) tool. then from the command line:

   fossil diff --from VERSION --to VERSION

This will launch WinMerge (with temporary copies) to display the
differences between the 2 versions. However, Fossil will ignore any changes
you make in WinMerge.

Until either Fuel is updated (possibly by some one forking it) or some one
creates a new GUI front end for Fossil (possibly using Electronic or
similar), this is the best you can get.
___
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] Windows GUI that allows diff between two revisions?

[Ron W]

On Mon, Feb 12, 2018 at 7:19 PM, 
wrote:

> Date: Tue, 13 Feb 2018 01:06:26 +0100
> From: Gilles 
> Subject: Re: [fossil-users] Windows GUI that allows diff between two
> revisions?
>
> On 13/02/2018 00:33, Richard Hipp wrote:
> > On 2/12/18, Gilles  wrote:
> >> Fuel* doesn't support diffing two revisions of a file in the repository:
> >>
> >> https://s14.postimg.org/h528wio5t/Fossil.Fuel.diff.two.revisions.png
> >>
> >> Since it hasn't been updated since 2015… is there another Windows GUI
> >> application that supports this?
> > Well, you could run "fossil ui", then surf to the page that shows a
> > complete history of the file in question, with its timeline, then
> > click on the timeline graph node for the first version (so that it
> > gets a red dot in the center) then click on the timeline graph node
> > for the second version.
> >
> > That's what I always do, anyhow.
> Thanks for the tip.
>
> 
>
> So at this point, there is simply no Windows GUI that supports diffing
> two revisions of a file that's been checked in? IOW, if I'd like to diff
> two versions of a file with Fuel, I should do this while it's still
> checked out ?
>

As best I recall, Fuel uses "fossil ui" (or "fossil server") behind the
scenes, so any feature of "fossil ui" should also be usable in Fuel.

It has been years since I looked at Fuel (as an option for co-workers who
dislike the command line), so I'm not 100% sure, but I do remember Fuel
having an embedded web browser to display content from "fossil ui". I
thought Fuel's design somewhat "clunky". My co-workers said it was more
confusing than using the Fossil command line.

However, since "fossil ui" already provides most of a good GUI, maybe a
framework like electronjs.org could be used to create a Windows GUI for
Fossil that integrates the functionality of both "fossil ui" and the Fossil
command line in a seamless fashion.

FYI, Electron is a framework, based on the open source Chromium browser
(which is also the base for the Chrome browser), for "converting" a
web-base application into a desktop application. Also, Electron supports
all 3 of Windows, MacOS and Linux.

I've never tried it, but a friend of mine showed me an application built
using Electron.
___
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] Action-based automation and scripting

[Ron W]

On Sun, Jan 28, 2018 at 7:00 AM, 
wrote:

> Date: Sat, 27 Jan 2018 17:22:39 -0500
> From: "Joe Mistachkin" 
> Subject: Re: [fossil-users] Action-based automation and scripting
>
> The following pages may be of help to you:
>
> https://www.fossil-scm.org/fossil/doc/trunk/www/th1.md
>
> https://www.fossil-scm.org/fossil/doc/trunk/www/th1-hooks.md
>
> TH1, by itself, cannot do things like send mail, write files, etc.
>

th1.md claims TH! has an http command that can send an HTTP request (get or
put) to a specified URL. (However, only asynchronous requests are currently
implemented, so no way to receive the response.)

With just TH1, you should be able to send some information to a HTTP based
service, which could then perform more complex operations with that
information. (But, the TH1 hook won't get any confirmation that the service
received the information.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 120, Issue 38

[Ron W]

On Sat, Jan 27, 2018 at 7:00 AM, 
wrote:
>
> Date: Fri, 26 Jan 2018 14:13:29 -0800
> From: jungle Boogie 
> Subject: Re: [fossil-users] Cross-link tech notes to commits
>
> On 21 December 2017 at 07:34, jungle Boogie 
> wrote:
> > On 20 December 2017 at 13:13, jungle Boogie 
> wrote:
> >> Hi All,
> >>
> >> I know a tech note entry in the timeline can be linked to a specific
> commit.
> >> For example:
> >> http://fossil-scm.org/index.html/timeline?ss=m=200=e=0
> >>
> >> See the top commit by AG.
> >>
> >> Can a commit message contain the [ID] of a tech note and have it linked
> to it?
> >>
> >
> > At this point in reading the documentation, I don't think this is the
> > case. Technotes commit messages can contain the [ID] of a check-in,
> > though.
> >
> > https://www.fossil-scm.org/index.html/doc/trunk/www/event.wiki
> >
> > Is this because of this?
> > Because technotes are considered a special kind of wiki, users must have
> > permission to read wiki in order read technotes.
> >
>
> I know a release is coming up soon, so maybe we can determine if this
> is a bug not to cross-link, an enhancement, or as designed.
>

It looks like Fossil fails to treat the "name" of a tech note as the name
of a wiki page. I would consider this an oversight when implementing the
wiki page look up.

Also, Fossil claims to only look at commit and ticket artifact IDs when the
link appears to be an artifact ID. I would guess this was by design to
minimize the number of potential "prefix collisions" when searching by just
a prefix of the artifact ID.
___
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 Embed WebM Videos to Fossil Wiki Pages?

[Ron W]

On Wed, Jan 3, 2018 at 1:27 PM, 
wrote:
>
> Date: Wed, 3 Jan 2018 19:04:20 +0200
> From: Martin Vahi 
> To: fossil-users@lists.fossil-scm.org
> Subject: [fossil-users] How to Embed WebM Videos to Fossil Wiki Pages?
> Message-ID: 
> Content-Type: text/plain; charset=utf-8
>
>
> I know that the way to embed an image is by
>
> ![name of the link]()
>
> but it does not seem to work with the WebM videos.
>

Both Fossil wiki syntax and Fossil Markdown syntax allow including HTML
markup, so you should be able to include the video as an HTML video element
and not have to rely on Fossil to generate the needed HTML.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 119, Issue 68

[Ron W]

On Sun, Dec 31, 2017 at 7:00 AM, 
wrote:
>
> Date: Sat, 30 Dec 2017 22:48:18 +
> From: John Pateman 
> Subject: [fossil-users] Interest in supporting Bugwarrior/Taskwarrior
> integration from Fossil users?
>
> I have been using Fossil for a while and I also use TaskWarrior a simple
> CL todo list manager  (https://taskwarrior.org )
> to organise my work /todo list / life etc. TaskWarrior integrates with
> Bugwarrior (https://github.com/ralphbean/bugwarrior <
> https://github.com/ralphbean/bugwarrior>) which is a small utility for
> pulling tickets from a a variety of sources including  GitHub / BitBucket /
> Trac / Megaplan / Teamlab / Redmine / Jira (and others) and adding them to
> a Taskwarrior list. There are mechanisms for pulling  these  lists into
> Trello / Kanban type boards too. Works well and seems pretty solid.
>
> There is /was a partially functional python plugin for Fossil which will
> also pull issues from Fossil and push them to Bugwarrior (and then to
> Taskwarrior). Unfortunately, the Fossil code has not been updated to meet
> the current coding requirements
>

Though I'm not a Python coder, I did look at the code and compare it to one
of the current tracker "plug ins", "youtrack". Looka like Bugwarrior's
plug-in API has changed a lot. I think the only part of the existing code
that can be re-used is the ticket-fetching. Unfortunately, I could not find
any documentation on the API.

I also looked at Taskwarrior's JSON API. Looks like it would not be hard to
create a 2-way integration directly with Taskwarrior.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 120, Issue 2

[Ron W]

On Mon, Jan 1, 2018 at 6:48 PM, 
wrote:

> Date: Mon, 01 Jan 2018 12:44:42 +
> From: Sergey Bronnikov 
> Subject: [fossil-users] ticket length limitation
>
> For most by bugs it works fine, but command is failed when ticket body
> exceed limits. Command line length is limited by value in `getconf
> ARG_MAX`, in my case it is 262144. So when file is too long it is
> impossible to create ticket.
> $ echo "fossil ticket add title "title" comment \"$(cat content)\"" | wc -c
> 469207
>
> Is there any workaround?
>

Try splitting the long text file into 2 or more smaller files, then add the
ticket using the first file. Then you can append to the comment:

   $ fossil ticket change TICKETUUID +comment "$(cat content_next)"
___
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] question regarding fuel-scm maintenance / ownership

[Ron W]

On Tue, Dec 26, 2017 at 7:00 AM, 
wrote:
>
> Date: Mon, 25 Dec 2017 23:44:27 +0100
> From: Chris Drexler 
> Subject: [fossil-users] question regarding fuel-scm maintenance /
> ownership
>
> Anyone here who knows any contact or has suggestions on what to do? I
> don't want to see this project die, I like fossil/fuel to propagate DVCS
> usage even to DVCS-newbies (like my son :-) ).
>

If you are unable to make contact, you might consider "forking" the project
(under a new name) and maintaining it yourself.
___
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] tangent vs. wyoung on recent commti

[Ron W]

On Sun, Dec 17, 2017 at 9:11 PM, 
wrote:
>
> Date: Sun, 17 Dec 2017 18:13:17 +
> From: Mark Janssen 
> Subject: Re: [fossil-users] tangent vs. wyoung on recent commti
>
> Then what is the point of recvfrom? It will then just reduce to the repo
> where the artifact was created. This might be useful, but it is not what
> recvfrom means.
>

All I'm suggesting is that the information already being put in the
"rcvfrom" table (that DRH mentioned) also be saved as tags to the commits
they refer to. Therefore, the tags will have the same meaning as the
entries in the existing "rcvfrom" table.
___
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] tangent vs. wyoung on recent commti

[Ron W]

On Sun, Dec 17, 2017 at 7:00 AM, 
wrote:
>
> Date: Sun, 17 Dec 2017 09:56:57 +
> From: Mark Janssen 
> Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28
> Message-ID:
> 

Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28

[Ron W]

On Sat, Dec 16, 2017 at 7:00 AM, 
wrote:

> Date: Fri, 15 Dec 2017 13:52:55 -0500
> From: Richard Hipp 
> Subject: Re: [fossil-users] tangent vs. wyoung on recent commti
>
> On 12/15/17, Andy Bradford  wrote:
> > As  stated  in  the  past,  Fossil  is meant  for  a  tighter  group  of
> > developers---perhaps   this  perception   has  changed---one   in  which
> > impersonation is unlikely.
> >
>
> I was very aware of all of these factors when I designed Fossil, 10
> years ago.  Impersonation was a concern.  But in a DVCS, there really
> is no way around it.
>
> Defenses include:
>
> (1) The rcvfrom table that shows clearly where all artifacts
> originated, thus allowing the originator of a deception to be tracked
> down and dealt with administratively.
>

Maybe there should be a way to store this rcvfrom table in artifacts so the
data is part of the permanent Fossil record.

Maybe as control artifacts to auto-tag each each commit received via
sync/pull/push?
___
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 vs. GitHub

[Ron W]

On Thu, Dec 14, 2017 at 7:00 AM, 
wrote:
>
> Date: Wed, 13 Dec 2017 18:04:41 -0600 (CST)
> From: Roy Keene 
> Subject: Re: [fossil-users] Fossil vs. GitHub
>
> One thing I often wish Fossil did was show other things (tickets, wiki
> pages) that reference tickets rather than just checkins -- I often have a
> mess of tickets that refer to other tickets and no place to generate a
> list of them, or reverse them.


I'm not sure how the TH1 regexp command works, but it might be possible to
at least find other tickets that reference a specific ticket using a
combination of SQL in Fossil's ticket report subsystem and TH1+SQL in the
new and edit ticket scripts in the ticket configuration.

In the ticket configuration, add a new table to the ticket schema to that
has 2 columns: "referree" and "referrer"..

In the new and edit ticket TH1 scripts, enhance the submit handling to find
artifact references using the regexp command with the regex "\[[0-9a-f]\]".
For each match, add (or update) a row to the new table with referree = ID
found and referrer = ID of current ticket.

Of course, this assumes that the ticket TH1 scripts can access the ID of
the current ticket and that the TH1 regexp command can be used to get a
list of locations of regex matches.

Maybe some Javascript can extract the ticket ID from the URL and supply
that as a hidden field back to the TH1 scripts.

If regexp doesn't work as needed, may be possible to use "string first" and
"string range" to find and extract artifact IDs.

As for wiki pages, maybe the "webpage_notify" hook can be used to find
artifact references.
___
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] tangent vs. wyoung on recent commti

[Ron W]

On Thu, Dec 14, 2017 at 2:31 PM, 
wrote:
>
> Date: Thu, 14 Dec 2017 12:31:21 -0700
> From: Scott Robison 
> Subject: Re: [fossil-users] tangent vs. wyoung on recent commti
>
> I'd bet that you can commit as anyone and push it if you have that access.
> You probably wouldn't keep that access for long, though.
>

As I understand it, Fossil's "check in" permission really means "push"
permission. That is, whether a repo will accept a push from another repo
under that user name.

Local, command line usage seems to grant the command line user full
permissions as long as the user has RW access to the repo file, itself.

Right now, I can't test this to confirm this behavior.
___
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] Metadata in Timeline Verbose View

[Ron W]

On Tue, Dec 12, 2017 at 1:16 PM, 
wrote:
>
> Date: Tue, 12 Dec 2017 14:00:01 +0100
> From: Florian Balmer 
> Subject: Re: [fossil-users] Metadata in Timeline Verbose View
> Message-ID:
>  mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > $ fossil conf export skin foo
> > …upgrade Fossil, switch repo to skin you wish to merge…
> > $ fossil conf merge foo
>
> Sounds easy. But on shared web hosting, with limited shell access, and
> a total of 10-15 repositories, this already makes me edgy. I have also
> tried using a shared skin loaded from a directory using the "skin:"
> CGI control line, but then the skin is missing on local machines.
>

$ fossil conf pull skin URL-to-remote-repo
... update skin locally
$fossil conf push skin URL-to-remote-repo
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 119, Issue 6

[Ron W]

On Tue, Dec 5, 2017 at 10:56 AM, 
wrote:
>
> Date: Tue, 5 Dec 2017 10:56:06 -0500
> From: Richard Hipp 
> Subject: Re: [fossil-users] Fossil in Debian
>
> On 12/5/17, Roy Keene  wrote:
> > upstream doesn't make it easy, with their download page that uses
> > javascript to mangle the URLs, thus confounding Debian's automatic
> > monitoring tools.
>
> What else can I do to make things easier for Debian's automatic
> monitoring tools?  What do the Debian monitoring tools need?
>

Isn't this "URL mangling" part of the "bot" protection?

If the zip files linked on the downloads page are pre-built, how much load
would the bots put on the website without the protections?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 118, Issue 47

[Ron W]

On Mon, Nov 27, 2017 at 7:00 AM, 
wrote:
>
> Date: Mon, 27 Nov 2017 09:50:29 +
> From: Javier Guerra Giraldez 
> Subject: Re: [fossil-users] Trolling GitHub for ideas
>
> the only github think i've really missed when using fossil for
> non-personal projects is the ability to comment on a diff.
>

This would be a very handy feature to have.

I think it could be implemented by adding Javascript to the existing diff
output. Maybe save the comments in a wiki page with a name derived from the
filename and commit ID, appending each comment to the page. The Javascript
code would get the line numbers of the from and to versions of the file
from the diff output.

Actually, I'd rather the comments be saved in a ticket. I think a tag on
the commit could be used to identify the ticket. All comments would go in 1
ticket, regardless of the file. I'm not sure how the Javascript could find
the filename. Maybe the diff output would need to have anchors inserted by
Fossil's diff generator.

As a bonus, Fossil's ticket artifacts are designed to support appending to
ticket fields. The diff comments will be stored without duplicating all
previous diff comments when a new one is posted.

FWIW, since my group at work was already using Review Board (reviewboard.org)
with SVN, when I introduced Fossil, our Python geek butchered RB's CVS
support to (sort of) support Fossil. (We enter review requests with
"fossil diff
| rbt post --diff-filename=-" ) Unfortunately, that person left the company
and our IT department won't let us access RB's Python files on that server,
so I can't share the changes that were made.

(Personally, I don't like Review Board. Also, since we only use RB for
commenting on diffs, adding diff comments to Fossil would allow us to keep
everything in Fossil (and to stop using RB).)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 118, Issue 46

[Ron W]

On Sun, Nov 26, 2017 at 7:00 AM, 
wrote:
>
> Date: Sun, 26 Nov 2017 09:22:08 +0100
> From: Stephan Beal 
> Subject: Re: [fossil-users] More timeline changes
>
> On Sat, Nov 25, 2017 at 11:06 PM, Tony Papadimitriou 
> wrote:
>
> > The idea looks very good to me.  But the ellipses are indeed barely
> > visible.
> > How about replacing ... with [*] as a generic (foot)note mark?
> >
>
> LOL! i didn't even notice that the ellipsis were there. i recommend doing
> away with them entirely, an simply making "click a timeline entry to expand
> its details" a new documented feature.
>

I think there needs to be some indication that there is more information.
>From my experience, an ellipses is a very common tool for this purpose - as
long as they are visible.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 118, Issue 38

[Ron W]

On Fri, Nov 24, 2017 at 7:19 PM, 
wrote:
>
> Date: Fri, 24 Nov 2017 19:19:27 -0500
> From: Richard Hipp 
> To: "Fossil SCM user's discussion" 
> Subject: Re: [fossil-users] Fossil-NG Bloat?
> Message-ID:
> 

Re: [fossil-users] Fossil-NG ideas

[Ron W]

On Tue, Nov 21, 2017 at 6:43 PM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Tue, 21 Nov 2017 15:25:37 -0700
> From: Warren Young <war...@etr-usa.com>
> Subject: Re: [fossil-users] Fossil-NG ideas
>
> On Nov 21, 2017, at 2:09 PM, Ron W <ronw.m...@gmail.com> wrote:
> >
> > While I like the idea of a "smart default" for the file name, I'd rather
> have an "--open" (or "-o") option to trigger the automatic "fossil open”.
>
> So…you want to remain more difficult to use than Git in this regard?
>

"fossil clone -o URL" would still be 1 step instead of 4 steps.


> > 1. If the user actually wants to specify the name, the option would be
> needed, anyway.
>
> No, they’d pass the FILENAME argument to “fossil clone,” just as you do
> today.
>

My understanding of your proposal was that leaving off the file name would
be the trigger for the git-like behavior.

So, I would expect "fossil clone URL filename" to do what it does today:
Create a repository file with the specified filename. No more.


> This does open a new issue, however.  What does this mean:
>
> $ fossil clone https://fossil-scm.org/ fsl
>
> Do you:
>
> a) get a fsl subdirectory containing the contents of the Fossil trunk
> checkout, as Git would do; or
>
> b) get a fsl.fossil file, as someone up-thread apparently wants.  That is,
> assume the FILENAME argument is still a repository file name, and that if
> .fossil is not given as an extension, add it?  Or
>
> c) get a fsl file, as Fossil 2.4 and all prior versions do?


I would expect c - do as Fossil does, today.

If I want the git-like behavior, I'd type "fossil clone -o
https://fossil-scm.org/ fsl"

I'm all for "stealing" features from other VCSs. Just don't change break
existing command syntax.

As for something I'd suggest stealing, how about enhancing "fossil
checkout" to accept an optional URL?

When I first started using Fossil, one of the things that was confusing to
me is that "svn checkout" maps to "fossil open", not "fossil checkout". It
is still something I help others migrating from SVN to Fossil. If Fossil
did not have a checkout command, it would have been less confusing. What I
tell those I help is "Just use 'fossil open' and pretend there is no
'fossil checkout'."

Anyway, "fossil checkout" could be made more like "svn checkout" merely by
extending the syntax to allow an optional URL.
___
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?

[Ron W]

On Fri, Nov 24, 2017 at 7:00 AM, 
wrote:
>
> Date: Fri, 24 Nov 2017 05:55:51 -0500
> From: Richard Hipp 
> Subject: Re: [fossil-users] Fossil-NG Bloat?
>
> On 11/24/17, Johan Kuuse  wrote:
> > I agree on that we would give up Fossil semantics.
>
> I have no intent to "give up" or change the semantics of Fossil, and I
> see no reason why enabling Fossil to push and pull from Git
> repositories would require this.
>

Your wiki page summary and replies in this discussion imply you would
implement interoperability with git by having fossil store git artifacts.

Between your comments that git/Fossil artifact translation has significant
overhear (and a claim that "git fast-export | (cd /new/path; git
fast-import)" is not lossy), there is an implication that git artifacts do
not support all of Fossil's metadata.

What effect will this reduced metadata have on applying Fossil semantics to
git artifacts?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 118, Issue 35

[Ron W]

On Fri, Nov 24, 2017 at 10:17 AM,  wrote:
>
> Date: Fri, 24 Nov 2017 09:35:55 -0500
> From: Richard Hipp 
> Subject: [fossil-users] A-B comparison of proposed timeline changes
>
> Which is better?
>
>   A:  https://www.fossil-scm.org/a/timeline
>   B:  https://www.fossil-scm.org/b/timeline


I prefer B because I don't have to scroll down to get to the "older" link.

I do like having the timestamp of the commit as the link to the commit.

Also, I did not see any effect when adding the "?basic=1" option to the URL.
___
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?

[Ron W]

On Wed, Nov 22, 2017 at 7:09 PM, 
wrote:
>
> Date: Wed, 22 Nov 2017 19:09:21 -0500
> From: Richard Hipp 
> Subject: Re: [fossil-users] Fossil-NG Bloat?
>
> On 11/22/17, Offray Vladimir Luna Cárdenas  wrote:
> > I'm dubious over making Fossil a client for
> > any other main DVCS out there.
>
> One important reason that many people use Git is because so much OSS
> is hosted on GitHub and everybody wants to be part of the action.  If
> developer Alice wants to play in the OSS world, she has to use Git.
> But if Fossil were able to clone, push, and pull from Git
> repositories, that would enable Alice to use Fossil instead, opening
> the door to wider adoption.
>

But we give up Fossil semantics. And some of git'd semantics will require
extending the Fossil UI. And, if some of the UI ideas suggested would
actually change (instead of extending) the behavior of existing Fossil
commands. At that point, to my thinking, will be easier to use a proper git
client rather than translate git commands to Fossil commands.

Also, FWIW, it's been years since I last actually used git to "play in the
Github world". The projects I have been contributing to accept patches just
as readily as they accept pull requests, so I can just download a zip file,
update the "vendor branch" in my Fossil repo for the project, make and test
my changes, then make and send a patch.

(Yes, many project only accept pull requests. Just been a long time since
I've had a reason to contribute beyond a bug report (possibly including a
tiny patch).)
___
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 ideas

[Ron W]

On Tue, Nov 21, 2017 at 4:09 PM, 
wrote:
>
> Date: Tue, 21 Nov 2017 16:08:20 -0500
> From: Richard Hipp 
>
> The overhead for a small batch of commits non-zero but it is
> manageable.  A full clone, on the other hand, is too expensive.  To
> give Fossil the ability to service clone requests from git or hg
> clients, it would be necessary to implement some kind of cache wherein
> all of the artifacts have been pre-translated.  That means that the
> storage space requirements on the server would be multiplied by 2 or 3
> (depending on whether your wanted to service just git or just hg or
> both).
>

I assumed a full clone would be far too much. Thus why I was thinking that
non-Fossil VCS clients would be served via shadow repositories, despite
doubling (or more) the repository storage needs.

If a project were so big that the storage requirements became an issue,
then maybe make the shadow repositories be shallow and/or narrow.

(If I'm correctly understanding how git implements branches, it would be
possible to keep the git shadow shallow by periodically deleting old branch
labels/tags (which would allow the referenced commits to be garbage
collected (if not otherwise referenced by other means).)
___
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 ideas

[Ron W]

On Mon, Nov 20, 2017 at 5:22 PM, 
wrote:
>
> Date: Mon, 20 Nov 2017 13:33:11 -0700
> From: Warren Young 
> Subject: [fossil-users] Fossil-NG ideas
>
> There is one more thing Git really gets right compared to Fossil:
> single-step clone-and-open.  We should be able to do the same:
>
> $ fossil clone https://fossil-scm.org
>
> When the FILENAME parameter is not given, it produces a “Fossil”
> subdirectory containing the contents of tip-of-trunk, with the directory
> name coming from the project configuration under Admin.  The SQLite repo
> file is stored inside the subdirectory in a hidden file; I propose .fslrepo.
>

While I like the idea of a "smart default" for the file name, I'd rather
have an "--open" (or "-o") option to trigger the automatic "fossil open".

1. If the user actually wants to specify the name, the option would be
needed, anyway.

2. By not requiring the option, it would be hiding one of Fossil's
advantages over git and Hg: Multiple working copies without the overhead of
multiple repository copies. (Granted, more likely SVN users migrating to
Fossil will appreciate this, but I know some former git and Hg users that
quickly learned to appreciate this.)

3. Adopting features from git is good, but let's not make Fossil too much
like git.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 118, Issue 22

[Ron W]

On Mon, Nov 20, 2017 at 7:44 PM, 
wrote:
>
> Date: Mon, 20 Nov 2017 17:44:49 -0700
> From: Warren Young 
> Subject: Re: [fossil-users] Fossil-NG Bloat?
>
> 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.
>
...

> 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.
>

Between this and what the Fossil-NG page discusses, sounds like Fossil-NG
would be more like a "universal VCS adaptor" - implement support for the
Fossil API and you automatically get support for git, Hg, SVN, etc.
(Similar to what the https://langserver.org/ project aims for coding
languages.)

But, a "universal VCS adaptor" won't really be universal, so tool
developers will still end up supporting git, Hg and maybe SVN, so why would
a tool developer support Fossil-NG?

Maybe if Fossil-NG did a stellar job of supporting Hg and SVN APIs, tool
developers would accept it as a replacement for directly supporting Hg and
SVN. (I say Hg and SVN because their UIs are closer to Fossil's than git's
UI is.)

I suspect the best way to get interest in using a Fossil-NG "universal VCS
adaptor" would be to provide a Hg-like API for use by tool developers.

As for inter-operating with other VCSs, why is any given Fossil user using
Fossil instead of one of the others?

I use Fossil for its semantics, not its UI. Yes, there would be a certain
convenience to having a Fossil-like UI to other VCSs, but it's not the same
as Fossil itself. (At work, my team and I use both Fossil and SVN.)

To my thinking, if a project's core team can agree on using Fossil,
providing a git/Hg/SVN "shadow repository" for use by non-core contributors
makes sense. Yes, the meta data translation is lossy, but the essentials
can (be made to) get through. (For my team, fossil is our primary VCS with
SVN as the shadow.)

For an individual commit (or small batch of commits), how much is the
translation overhead?

If a git-sync-protocol (or Hg/SVN/other) "plug in" could be developed for
Fossil (so we wouldn't have the overhead of external tools), I suspect the
burden of keeping the main (Fossil) and shadow repositories sync'd would
not be too unreasonable.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 118, Issue 13

[Ron W]

On Sat, Nov 11, 2017 at 8:40 PM, 
wrote:

>
> Subject: Re: [fossil-users] [Nmh-workers] Merging Source Files with
> git.(fwd)
>

Richard said:

There is no way to track file merges in Fossil.  Nor is there a way to
> track splits - when a single source code file is split into multiple
> smaller files because the original became too large.
>

And I said:

I think you could do that with a serials of operations. (I have NOT tested
> any of this)
>

Clarifying my response:

True, Fossil only tracks merges on the commit level. So, not (directly)
possible to track merges of differently named files.

On the other hand, Fossil does track renaming files.

My proposal indirectly uses this renaming tracking to track the merges. It
does require several commits for each file. My proposed procedure is
(possibly over) cautious in that it makes a commit after each file
operation. It might be possible to accomplish with less frequent commits.
Also, if more than one set of files is being merged ( foo*.c => foo.c,
bar*.c => bar.c, etc ), should be able to do all of the same operation for
each set then commit.
___
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] [Nmh-workers] Merging Source Files

[Ron W]

On Sat, Nov 11, 2017 at 7:00 AM, 
wrote:
>
> Date: Sat, 11 Nov 2017 10:22:15 +
> From: Thomas Levine <_...@thomaslevine.com>
> Subject: [fossil-users] [Nmh-workers] Merging Source Files with git.
> (fwd)
>
> Ralph asks whether a particular feature is available in git,
> so I am curious, is it available in fossil?
>
> --- Forwarded Message
>
> Date:Fri, 10 Nov 2017 23:51:07 +
> From:Ralph Corderoy 
>
> This suggests foo_{add,del,find,save,tweak}.c should in time become
> foo.c, allowing globals to become statics in foo.c, and currently global
> structs, etc., to also move to foo.c.  Is there a good way of doing
> this, in multiple stages if necessary, that allows git to preserve the
> chain of history?  Say telling it foo_add.c is now foo.c in one commit,
> and then foo_del.c has merged with foo.c in the next.
>

I think you could do that with a serials of operations. (I have NOT tested
any of this)

1. Create a branch for combining the files
2. fossil mv foo_add.c foo.c
3. fossil ci
4. Branch again
5. Edit foo_del.c to include functions from foo.c
6. fossil rm foo.c
7. fossil ci
8. fossil mv foo_del.c foo.c
9. fossil ci
10. Merge this branch to branch created in 1, then check in the result
11. Goto 4 and repeat for next foo_*.*
12. Merge final result (in branch from 1) to trunck (or where ever "1" came
from)

In theory, could do this without creating a new branch for each foo_*.* but
the "extra" branching will help make the combining history clearer.

These steps can probably be simplified.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 117, Issue 15

[Ron W]

On Thu, Oct 19, 2017 at 8:00 AM, 
wrote:

>
> Date: Wed, 18 Oct 2017 13:30:31 -0500
> From: Andy Goth 
> Subject: [fossil-users] Fwd: Re: Fossil README symlink
>
> -- Forwarded message --
> From: "Matias Fonzo" 
> Date: Oct 18, 2017 13:26
> Subject: Re: Fossil README symlink
>
> Two things, the report of the people is not about the login page
> only.  They can't see some of the pages, cannot remember exactly those,
> but i think it was about the content, and the Timeline.  I've followed
> the suggestions to try to avoid Javascript, but without luck.
>

Sounds to me like some members of Matias' team have disabled Javascript. If
that's not the case, then we need to figure out what's wrong with Fossil's
Javascript.

Not convenient for me to check, right now, but I didn't think that Fossil
used much Javascript. Off hand. I only recall it being used for anonymous
login protection and to draw the graph on the timeline page.

It's been years since I last messed with Javascript, but what little I did
code, I always only used it to enhance functionality, not implement
required functionality.

(Yes, I know that some people would considered the graph in the timeline
page to be required functionality. Unfortunately, at the time the graph was
first implemented, Javascript was, by far, the best browser-independent way
to make the graph.)
___
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] Fwd: Re: Fossil README symlink

[Ron W]

On Wed, Oct 18, 2017 at 8:00 AM, 
wrote:
>
> Date: Tue, 17 Oct 2017 20:12:25 -0500
> From: Andy Goth 
> Subject: [fossil-users] Fwd: Re: Fossil README symlink
>
>  Forwarded Message 
> Subject: Re: Fossil README symlink
> Date: Tue, 17 Oct 2017 21:49:35 -0300
> From: Matias Fonzo 
>
> Fossil is a great software and I consider it better than Git. The
> problem is the Javascript code to avoid the spam, and some people
> reported that they can not enter to the Dragora's website, which is a
> problem for me.
>

As I recall, the Javascript on the login page is to allow for anonymous
logins. If anonymous logins are not allowed, is there still any reason for
Javascript on the login page?

Of course, given that github also makes extensive use of Javascript, what
are they doing differently that doesn't cause problems for Matias?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 116, Issue 32

[Ron W]

On Thu, Sep 28, 2017 at 7:57 AM, 
wrote:

> Date: Thu, 28 Sep 2017 06:17:30 -0400
> From: David Mason 
> Subject: Re: [fossil-users] Using Fossil with Apache Proxy
>
> I'm running fossil from within a CGI of my own... I want to do things like
> `fossil new foo.fossil`
>

As Richard suggested, look at http://chiselapp.com/ . It is open source and
uses Fossil to the things you want to do, like creating new repositories.
___
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 hooks and workflow

[Ron W]

On Sun, Sep 17, 2017 at 4:36 AM, 
wrote:
>
> Date: Sun, 17 Sep 2017 10:36:31 +0200
> From: Johan Kuuse 
>
> Sorry for my ignorance, but I have never heard of this tool. Do you refer
> to
>
> https://en.m.wikipedia.org/wiki/QA-C
>
>
Yes.


> At work, we use the follwing workflow and tools:
>
> Pre-hooks to check the commit message
>

For that, in Fossil, you could configure a commit message editor to a
program/script that launches a text editor (possibly with a "pre loaded"
template), then validates the message after the editor is closed.


>
> The commit is first sent to Gerrit, used as a "Git proxy".
> The commit triggers a build, handled by Jenkins, which compiles the code
> and runs all test suites.
>

We develop software for electronic control modules. While we have automated
testing, during development, loading a new version of software in to a
 module is still a manual process. So, we don't use Jenkins or other CI
server.


> My colleagues may analyze my new commit (manually, a.k.a "code review")
> using Gerrit, and either reject or  accept my commit.
>
> If either the Jenkins build fails, or at least one of my colleagues reject
> my commit, I commit --amend a new patch, which triggers a new Jenkins build
> and sends a new email to my colleagues/code reviewers, and so on, until
> both Jenkins and my colleagues accept my new code.
>
> I may then submit my new commit to the "real repos" (i.e. "trunk", a.k.a.
> "master" in the Git world).
>
> Gerrit is a user-friendly tool, but its function could obviously be
> substituted with a new branch in the same repos as trunk. The new branch
> would have the same function as a "proxy", before merging the commit into
> trunk.
>

We commit our changes to development branches for review. Once a change has
passed testing and has been accepted, it is merged to trunk, tested again,
then committed.


> What I do think are nice features in this workflow are the hooks, where the
> pre-hook watches my commit message syntax, and the post-hook triggers a
> code rebuild, and also sends a mail to my code reviewers.
>
> Is anyone here on the list using Fossil with similar hooks?
> Or combining Fossil with other tools to achieve the same?
>

Unfortunately, Fossil's hooks are not documented, so we rely on Fossil;s
RSS feed to notify of new commits and tickets.

I recall that some people have used Fossil;s post-commit hook to tell a CI
server to look at the RSS feed.

Much as I would like to use Fossil's hooks, my team's needs are covered by
the "editor hook" and the RSS feed.

If Fossil's hooks ever get documented, I will look into using them.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 116, Issue 11

[Ron W]

On Sat, Sep 16, 2017 at 8:00 AM, 
wrote:

> Date: Sat, 16 Sep 2017 01:15:25 +0200
> From: Johan Kuuse 
> Subject: Re: [fossil-users] Shameless self-promotion
>
>
> >El 16 sept. 2017 0:39, "Warren Young"  escribió:
> >>> On Sep 14, 2017, at 11:12 PM, Johan Kuuse  wrote:
> >>>
> >>> A commit pre-hook running an automatic indenting would have solved this
> >>> problem.
> >>
> >> Coding style is a social norm.  It should be enforced by social means,
> not
> >> technical means.
> >
> > Must disagree here, at least when we are talker about bigger communities,
> > where some kind of technical control/help is necessary to create some
> kind
> > of "community standard".
>

While I work, we include a step to run QAC to perform source code analysis
and style checks in the build rule for compiling a source file, so each
source is validated before it's even compiled.

If we wanted to auto-format the source code, we would add a step before
QAC. That way, it would be the (re-) formatted code that is validated and
compiled.

Then, once the build successfully completes, source changes are
automatically committed in Fossil.

Sometimes, we will do "manual" commits between builds, but our build
process insures that what actually got built is also committed.
___
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] Empty file constantly being deleted

[Ron W]

On Thu, Sep 7, 2017 at 5:25 PM, 
wrote:

> The other type of empty files (actually, just one single file) is used
> for a test case to check how one part of the project gracefully handles
> an empty file. So, this file is actually not created by every
> contributor individually according to their preferences but part of the
> checkout.
>

I would recommend that the test script create that file when that test case
is run.

If your testing is not automated, then your build process could create it.

If neither of the above applies, then create a script for preparing the
"work environment" for doing testing. This is often a very good idea
because it helps to establish consistent start conditions for testing,
which makes replicating results much easier.
___
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] toc.tcl

[Ron W]

On Wed, Aug 30, 2017 at 7:05 AM, 
wrote:
>
> Date: Tue, 29 Aug 2017 22:55:56 -0500
> From: Andy Goth 
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] toc.tcl
> Message-ID: <56c8452e-5530-7c0d-c077-fa2b35375...@gmail.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> dewey.hylton says "```" imbues syntax highlighting whereas indented
> lines are left plain.  Fossil doesn't do any kind of syntax highlighting
> at this point.  Is there any interest in having this feature?  I feel
> syntax highlighting is both expected and bloat.  We would have to decide
> which we prefer: being simple or having me-too features.
>
> I'm curious how the Markdown formatter would know what language rules to
> use for syntax highlighting, so surely there's more to the syntax than
> bracketing ("fencing") the code with lines consisting entirely of "```".
> I searched online and found the answer to be: put the name of the syntax
> highlight mode (i.e. the language) right after the first "```" on the
> same line, for instance "```ruby".
>

There are JavaScript scripts to do syntax highlighting in the browser, so
anyone who wanted to do that could. Hopefully, there is one that looks for
something like a  element. then
libdiscount could be enhanced to enclose code-fenced code in that element.

I am neutral on whether to do it, but this seems like it could be done with
a few small changes.
___
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] Suggestion: WIKI command EXPORT clean of tags

[Ron W]

On Thu, Jun 29, 2017 at 8:00 AM, 
wrote:
>
> Date: Wed, 28 Jun 2017 16:57:29 +0300
> From: "Tony Papadimitriou" 
> Subject: [fossil-users] Suggestion: WIKI command EXPORT clean of tags
>
> I use Wiki a lot for keeping short notes/memos about pretty much anything
> related to the host repo.
> For cosmetic purposes when viewing from a Web browser these notes often
> contain  ...  or other such formatting tags.
>
> However, doing most programming from the command-line, when I want to
> quickly look up some notes, I often do (f=fossil):
>
> f wik exp PAGENAME
>
> to get the related note displayed on the console screen.
>
> However, these formatting tags are displayed cluttering the display (for
> some heavily formatted pages to the point of being unreadable).
>
> My suggestion is when ‘wiki export’ command is used without the optional
> file (which would save wiki page to a file, as is), and the console is the
> target to filter out all those formatting tags.
>

"fossil wiki export" outputs the "raw" content of the wiki page, which
seems reasonable, And, when the page contains only wiki mark-up, is very
readable.

Maybe an option to strip HTML, but I would not change the current default
behavior.

Also, from the command line, I sometimes use the lynx web browser, which is
text only. I have a bash macro, so I can type:

fw page+name

The macro is defined as:

fw() { lynx -dump "http://localhost:8080/wiki?name=$1; | less }

The only downside to this macro is needing to type + instead of spaces when
a page name has spaces. (Though, I'm old enough that my first use of a wiki
was with one that used the old "WikiWord" convention for naming pages, so I
tend to name wiki pages in that style.
___
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] Smudge and clean equivalents?

[Ron W]

On Sun, Jun 11, 2017 at 3:48 PM, 
wrote:
>
> Date: Sun, 11 Jun 2017 20:02:08 +0100
> From: John Pateman 
> To: Fossil SCM user's discussion 
> Subject: Re: [fossil-users] fossil-users Digest, Vol 113, Issue 18
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"
>
> I agree that choices made in the design of Kicad are unhelpful in this
> regard but the format is unlikely to change anytime soon. There is a good
> reason for one of the issues - components need annotation to generate a net
> list and it is acceptable to change the annotation between iterations.
> There is some book keeping between schematic circuit diagram and the pcb
> layout which are two separate files and programs. There are also some
> changes made when libraries are added but this is managed elsewhere by
> caching component library changes.  Anyhow, the details of exactly what the
> exact issues are and why these design choices have been made is not what is
> really important - it is the principle of how to cope with the consequences
> that concerns me.
>

I only meant where the only changes are "convenience" changes. Changing
annotation is a change to the design.


> I have investigated whether this is likely to change in Kicad and I think
> the answer, whilst there is a workable solution in git, is going to be no.


Many corporations do not use git or any of the other VCSs commonly used by
open source projects. Cannot assume any of those "corporate" VCSs have any
particular feature of git. (Though, I admit, most corporations aren't going
to use Kicad (for a variety of legal reasons).)


> But I really don't want to be forced into using git simply on this issue -
> I very much like fossil and it has many more advantages for my workflow.
>
> In fact, all I need is the 'clean' functionality. In git it is achieved by
> defining a filter for a particular file type (in my case a .sch) and then a
> filter entry for
> git.clean "sed -E 's/#(PWR|FLG)[0-9]+/#\1?/'"
>

What about "fossil clean" ?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 113, Issue 18

[Ron W]

On Sun, Jun 11, 2017 at 8:00 AM, 
wrote:
>
> Date: Sun, 11 Jun 2017 11:34:48 +0100
> From: John Pateman 
> Subject: [fossil-users] Smudge and clean equivalents?
>
> Is there any way to implement functionality equivalent to git smudge and
> clean in fossil?
>
> I would like to use fossil for a number of Kicad electronic projects.
> Kicad uses simple text files for describing the schematic and circuit
> layout so is a very suitable candidate for version control. Several users
> have used git to facilitate this but I would like to use fossil. Due to
> some internal book keeping there are changes made to the first line of the
> file which records a date stamp when the file is opened even if nothing
> else changes.


This sounds like a Kicad problem, not a VCS problem.

The Kicad devs may a very good reason - to them - for saving such internal
bookkeeping back to the file, but they should also provide a way to disable
saving those bookkeeping-only changes.

Even without a VCS, people edit older versions of documents. Therefore,
this bookkeeping data can't be operationally critical to Kicad itself. And
any workflow where such bookkeeping-only changes are important would likely
want the VCS to track those changes.
___
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 it possible to merge repository's?

[Ron W]

On Tue, May 30, 2017 at 8:00 AM, 
wrote:
>
> Date: Mon, 29 May 2017 22:35:31 -0500
> From: The Tick 
> Subject: Re: [fossil-users] Is it possible to merge repository's?
>
> On 5/29/2017 10:30 PM, Andy Bradford wrote:
> > Thus said Stephan Beal on Tue, 30 May 2017 02:57:38 +0200:
> >
> >> However, there is  _hypothetically_ a way to completely  merge 2 repos
> >> into one while keeping all commits, but i'm not at all certain if this
> >> would work...
> >
> > I think it actually will work for some definition of ``work''. I've done
> > it before.
> >
> > But... it depends on what one expects out of it.
> >
> > There will  be 2 separate  and independent timelines  once reconstructed
> > and there  will not be a  relationship between artifacts except  for the
> > fact that they all live in the same Fossil file.
> >
>
>  From this I gather that there would be no way to connect the imported
> repository onto the main trunk. That was not what I was hoping for.
>

What is your objective?

Once you have both time lines in one repository, you can then fetch files
from both into a single checkout and start making checkins  that affect
both timelines, therefore, effectively merging the timelines at that
checkin.

To get the "combined" checkout, I think you would have to "fossil checkout
uuidLatestA", then make a trivial change to all the files, then "fossil
update uuidLatestB".

At this point a commit would affect both timelines.

Though, as Stephan mentioned, you might need to do a reparent command to
insure that both uuidLatestA and uuidLatestB are parents of this new commit.
___
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] Incomplete patch with idea for enhancement

[Ron W]

On Wed, Apr 19, 2017 at 8:00 AM, 
wrote:

>
> Date: Tue, 18 Apr 2017 23:52:33 -0600
> From: Warren Young 
> Subject: Re: [fossil-users] Incomplete patch with idea for enhancement
>
> 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?
>

In MS Windows, that DB is the Windows Registry - along with a huge amount
of other stuff. I've never written a program specifically for MS Windows,
so I don't know what's involved. However, I have used the Nullsoft
Scripable Installer System to make installers for Ms Windows for some of my
programs and it has the ability to query (and modify) the registry, so
there is a way to access the information in 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] "CGI" command and argc

[Ron W]

On Thu, Mar 30, 2017 at 7:32 AM, 
wrote:
>
> Date: Thu, 30 Mar 2017 11:15:37 +0200
> From: Florian Balmer 
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] "CGI" command and argc
>
> > So, I would expect both of the following to work:
> > #!/usr/bin/env -S fossil2/fossil cgi fossil.config
> > #!/user/bin/env -S fossil1/fossil cgi fossil.config
>
> No, they don't, as the CGI script name is appended as an extra
> argument to the shebang command line, causing Fossil to leave the path
> with the explicit "CGI" command. I was suggesting that Fossil keep
> going the explicit "CGI" command path even if there's more than three
> command line arguments.
>

Unfortunately, I don't have a BSD box to test with.

The BSD man page for env claims that the -S option tells env to split the
string following it by white space.

Therefore, I would expect:

env "-S perl -e 'print qq([$_] ) for (@ARGV)' a b c"

to output:

[a] [b] [c]

There are examples of this behavior in the env man page (for BSD systems).

But, as I said, I don't have a BSD box to test this on,

Also, as best I can tell, only BSD's env has the -S option, so it is not a
portable solution.

However, the following should be portable to most Unix/POSIX type systems:

#!/bin/sh -c fossil cgi fossil.config
___
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] "CGI" command and argc

[Ron W]

On Tue, Mar 28, 2017 at 8:00 AM, 
wrote:
>
> Date: Tue, 28 Mar 2017 09:16:35 +0200
> From: Florian Balmer 
> To: fossil-users@lists.fossil-scm.org
> Subject: [fossil-users] "CGI" command and argc
>
...

> To get Fossil 2.1 running on my FreeBSD 9.1 shared host, I downloaded
> Fossil 2.1 and the OpenSSL libraries for FreeBSD 11 from [0], and
> grabbed a copy of libc.so.7 from a FreeBSD 11 ISO image (for
> `strchrnul`). These files were saved in a separate ./fossil2
> directory, and the symlinks libcrypto.so.9 -> libcrypto.so.7 and
> libssl.so.9 -> libssl.so.7 created. Now Fossil 2.1 works fine with the
> following one-line CGI script:
>
> #!/usr/bin/env -S LD_LIBRARY_PATH=fossil2 fossil2/fossil fossil.config
>

Aside from the libraries, I think the "magic" here is that the BSD version
of env has the -S option, which tells env to do a split("\s+", string) on
the text following the -S, which, because of how #!, is the rest of the
line.

So, I would expect both of the following to work:

#!/usr/bin/env -S fossil2/fossil cgi fossil.config

#!/user/bin/env -S fossil1/fossil cgi fossil.config

Unfortunately, the -S option for env is not implemented in most Linux
distributions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 110, Issue 51

[Ron W]

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

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

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

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

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

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

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

Most projects using a DVCS, whether Fossil, git, Hg or other, have a master
repository. However, it is possible to use a DVCS in a peer-to-peer style,
where, typically, each of the core developers maintains a "co-master"
repository for the project. Fossil's own master repository is actually 3
(last I read) co-equal repositories that are periodically sync'ed with each
other. Granted those 3 repositories are owned and controlled by the primary
developer, it still illustrates the concept of peer-to-peer operation.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Conflicting edits of ticket

[Ron W]

On Thu, Mar 16, 2017 at 2:01 PM, 
wrote:
>
> Date: Thu, 16 Mar 2017 14:31:00 +0100
> From: Richard Bukovansky 
> Subject: Re: [fossil-users] Conflicting edits of ticket
>
> Some kind of “comparer” where I would be able to decide which values are
> correct.
>

When you are viewing a ticket, there is a menu option to show the ticket's
history.

Unfortunately, Fossil doesn't store the ID of the "parent" artifact in
ticket change artifacts, so no easy way to automatically detect potentially
conflicting changes.

(Fossil wiki artifacts, however, do appear to store the ID of the parent
artifact, so should be possible to automate detection of conflicting wiki
edits.)
___
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] Progress report of Fossil 2.x

[Ron W]

On Fri, Mar 3, 2017 at 1:33 PM, 
wrote:
>
> Date: Fri, 3 Mar 2017 08:29:06 -0500
> From: Richard Hipp 
> Subject: Re: [fossil-users] Progress report of Fossil 2.x
>
> (4) When new content is added by means other than a check-in
> (examples: cluster artifacts added by the server on a sync, Wiki
> pages, ticket attachments, or unversioned content files) then use the
> hash algorithm that was used by the most recent check-in.
>

I would argue that wiki pages, ticket changes and ticket attachments have
parent artfacts. For wiki pages, it would be the most commit of that page.
For ticket changes and attachments, it would be the most recent change
commit (or the original ticket artifact itself) for the that ticket.

(Artifacts received during a sync/push/pull operation already have their
own hashes from when/where they were committed.)

Overall, I like this idea of defaulting the hash type of a new artifact to
that of its parent. Fossil development can continue as it has. Then at some
point, change the default new hash type and release that. Maybe 2.1, or
maybe a later one, depending on timing.

(Though maybe consider this an important enough change to warrant jumping
to 3.0. Either way, bug fixes to 2.0 won't be version number capped.)
___
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] Google Security Blog: Announcing the first SHA1 collision

[Ron W]

On Thu, Feb 23, 2017 at 11:23 PM,  wrote:
>
> Date: Fri, 24 Feb 2017 04:23:06 + (UTC)
> From: "K. Fossil user" 
> To: Fossil SCM user's discussion 
> Subject:
> 2/ semi?
>
> > « I think Fossil is in a much better position to do this sort of
> migration than, say, Git, due to its semi-centralized nature »
> This would convince people to use Git not Fossil ...
>
> Git is more secure than Fossil (first reason to use a VCS)Git could be
> centralized or not. I am wondering if Fossil could be centralized... Now
> you've said that it is semi-centralized by NATURE.
>

git and Fossil are equally decentralized. Both are DVCSs.

The "semi-centralized nature" really refers to the git community coalescing
around huge repository services like GitHub.

Fossil can also be organised around repository services. chisselapp.org is
a dedicated Fossil repository service. There are some repository services,
like SourceForge, that off several VCS options, including git and Fossil,

FYI, for most organizational purposes, projects tend to "revolve" around a
"central" master repository (or a central cluster of redundant master
repositories). This is equally true for both git and Fossil.

However, truly peer-to-peer relations between developer repositories can be
setup. This setup is basically the same as a central cluster, except that
each member of the cluster is used directly by members of the development
team.
___
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] Google Security Blog: Announcing the first SHA1 collision

[Ron W]

On Thu, Feb 23, 2017 at 7:02 PM, 
wrote:
>
> Date: Thu, 23 Feb 2017 17:01:56 -0700
> From: Warren Young 
> Subject: Re: [fossil-users] Google Security Blog: Announcing the first
> SHA1 collision
>
> The PHC scheme would allow Fossil to migrate to something stronger in a
> backwards-compatible fashion:
>
>https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md
>
> That is, if the hash argument in the F, P, and Q cards is not 40
> characters and it has a suitable prefix, it’s a new-style hash, else it’s a
> legacy SHA-1 hash.
>

The PHC scheme is conceptually good, but is not friendly for use by command
line tools like Fossil or git. This is mostly because it uses $ as its
field introducer, so will quoting. Also, the Base64 encoding relies on both
upper and lowercase letters, so is more prone to typographical errors.

I suggest a simpler scheme that provides the benefits of PHC in a more
command line friendly way.

Use ^ as the prefix and data introducers. The prefix would have a 1
character field for the artifact type, followed by the nonce. Then a second
^ separates the prefix from the data, which will be the hash. Base64
encoding would make the hash string use fewer characters while continuing
to use the hexadecimal encoding would be less prone to typographical errors.

Example: ^m1234567890^ab4c90e2.

m is the artifact type. Suggest m for manifest, c for control, etc.
___
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] Google Security Blog: Announcing the first SHA1 collision

[Ron W]

On Fri, Feb 24, 2017 at 5:54 PM, 
wrote:
>
> Date: Fri, 24 Feb 2017 20:38:48 +0100
> From: Joerg Sonnenberger 
> Subject: Re: [fossil-users] Google Security Blog: Announcing the first
> SHA1 collision
>
> On Fri, Feb 24, 2017 at 10:32:20AM -0800, bch wrote:
> > Are you saing:
> >
> > contenthash = sha256(content);
> > identifier = sha256 (contenthash . blobtype . conentsize . content);
> >
> > "blobtype" == cardtype ?
>
> Yes.
>

Wouldn't it be artifact type? (manifest, control, etc.)  rather than card
type?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 109, Issue 26

[Ron W]

On Sun, Feb 19, 2017 at 7:00 AM, 
wrote:
>
> Date: Sat, 18 Feb 2017 18:21:28 +0200
> From: Shlomi Fish 
> Subject: [fossil-users] Two problems
>
> I ran into three problems while trying to package the new fossil version
> for
> mageia linux v6:
>
> 1. I could not figure out how to report bugs in fossil itself.
>

This mail list is where to report bugs for Fossil. (The ticket is
restricted to vetted contributors due to many "spam" submissions in the
past.)


>
> 2. The unpacked directory in the 1.37 source tarball is user/packager
> unfriendly and currently it is "Fossil_2017-01-16_205854_1669115ab9" .
> Please
> change it to "fossil-1.37" or similar - see
> http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/ .
>
> 3. I couldn't find a mention of an IRC chatroom or a similar chat medium
> for
> fossil anywhere in a web search.
>

Currently there is no one in the Fossil community to run such a "chat room".
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 107, Issue 24

[Ron W]

On Mon, Dec 26, 2016 at 7:00 AM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Sun, 25 Dec 2016 18:07:18 +
> From: Chad Perrin <c...@apotheon.net>
> Subject: Re: [fossil-users] incorrect user info in export --git
>
> On Sun, Dec 25, 2016 at 12:22:43PM -0500, Ron W wrote:
> >
> > Then I commit the "final"
> > changes to my clone and send the pull request.
>
> That sounds like a use case for what I've built,
>

Not really. I don't need/want to make more than the one commit to git, so
not exporting anything to git. And really no need to import from git,
either. At most, I treat the coded from the git repo as a "vendor branch"
holding only the few git commits relevant to the change I'm making. The
rest of the git history doesn't need to be in Fossil.


>
> >
> > At work, the controls software group uses Fossil "internally", but the
> > company is still "standardized" on SVN (because the IT group's vision is
> > for "thin client" PCs that are fully interchangeable, which doesn't work
> > for my group because we need specialized tool chains that don't "play
> well"
> > with IT's vision). We use Fossil for our day-to-day work, only committing
> > releases to SVN.
>
> It seems like you have need of tools for import/export mirroring with
> Subversion, too.
>

Don't need nor want the day-to-day history in SVN. Only making commits of
the released versions to SVN because the company requires it. Otherwise, we
treat the the SVN repo as "write only". The SVN commit is automated as part
of the process for creating the release "package".
___
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] incorrect user info in export --git

[Ron W]

On Sun, Dec 25, 2016 at 7:00 AM, 
wrote:

>
> Date: Sun, 25 Dec 2016 05:11:28 +
> From: Chad Perrin 
> Subject: Re: [fossil-users] incorrect user info in export --git
>
> On Sat, Dec 24, 2016 at 12:47:43PM -0800, bch wrote:
> > On Dec 24, 2016 10:05, "Stephan Beal"  wrote:
> >
> > On Sat, Dec 24, 2016 at 6:42 PM, Chad Perrin  wrote:
> >
> > > I hope the lack of responses to my questions was because of the holiday
> > > season
> >
> >
> > Or maybe interest in git is slowly dying off ;).
> >
> >
> > Ever hopeful...
>
> I wish, but from what I've seen that's not happening in the wider world.
> I'd easily believe people who start using Fossil end up losing interest
> in Git, though.
>

I only use git when I have to, generally when a project requires submitting
pull requests. In that case, I still track my local changes in Fossil. Then
I pull the latest into my clone of the git repo, merge the changes into my
work space, rebuild, retest abd repeat as needed. Then I commit the "final"
changes to my clone and send the pull request.

At work, the controls software group uses Fossil "internally", but the
company is still "standardized" on SVN (because the IT group's vision is
for "thin client" PCs that are fully interchangeable, which doesn't work
for my group because we need specialized tool chains that don't "play well"
with IT's vision). We use Fossil for our day-to-day work, only committing
releases to SVN.
___
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] workarounds for revert issues

[Ron W]

On Wed, Nov 16, 2016 at 7:00 AM, <fossil-users-requ...@lists.fossil-scm.org>
wrote:
>
> Date: Tue, 15 Nov 2016 08:59:19 -0700
> From: Warren Young <w...@etr-usa.com>
> To: Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org>
> Subject: Re: [fossil-users] fossil-users Digest, Vol 106, Issue 17
> Message-ID: <98cbbc53-197a-456a-be0a-e461f6be3...@etr-usa.com>
> Content-Type: text/plain; charset=utf-8
>
> On Nov 14, 2016, at 10:09 PM, Ron W <ronw.m...@gmail.com> wrote:
> >
> > On Nov 12, 2016, at 4:52 AM, arnoldemu <mem...@arnoldemu.freeserve.co.uk>
> wrote:
> > >
> > > That is useful. What would the windows equivalent command-line?
> >
> > 2. xargs.  Again, no direct equivalent, requiring a bunch of ugly
> batch/PS code to replicate a 5-character command name.
> >
> > Another option for xargs on Windows is:
> > http://gnuwin32.sourceforge.net/packages/findutils.htm
>
> Ugh…they’re still shipping a version of Findutils from *March 2005*.  The
> current release (4.6.0) is less than a year old.
>

I could only find http://getgnuwin32.sourceforge.net/ which seems to be
fork for continuing the development of gnuwin.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil-users Digest, Vol 106, Issue 17

[Ron W]

On Mon, Nov 14, 2016 at 7:25 PM, 
wrote:
>
> Date: Mon, 14 Nov 2016 06:49:44 -0700
> From: Warren Young 
> Subject: Re: [fossil-users] Follow-up to reverting missing files
>
> On Nov 12, 2016, at 4:52 AM, arnoldemu 
> wrote:
> >
> > That is useful. What would the windows equivalent command-line?
>
> 2. xargs.  Again, no direct equivalent, requiring a bunch of ugly batch/PS
> code to replicate a 5-character command name.
>

Another option for xargs on Windows is:
http://gnuwin32.sourceforge.net/packages/findutils.htm

And there are other packages in the gnuwin32 project that might be useful.
___
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] features I'd like to have in fossil

[Ron W]

At the risk of wading in to a minefield, I have some thoughts.

On Fri, Oct 21, 2016 at 2:14 PM, 
wrote:
>
> From: Nikita Borodikhin 
> Date: Fri, 21 Oct 2016 16:02:33 +
>
> == combined log - history ananlysis ==
>
> The most unusual thing about Fossil is that it does not have "log" command.  
> [...]  In Fossil, there is no easy command line way to get the history of a 
> subtree.
>
>
Other than:
fossil finfo path/to/dir/*

I don't know what history of a subtree would be. Fossil tracks files, not
directories

I believe that most users are used to that universal log command and I
would be surprised if fossil's timeline/finfo duo is not _the_ most
thing people struggle with in the beginning of their relationship with
Fossil.
>
>
Never bothered me. I rarely use finfo, I suspect this may have been the
case in the early days of Fossil, with finfo being added as a separate
command, perhaps to avoid issues with the parsing of the existing timeline
command.

If someone were inclined enough to implement a new log command that could
show either commit history or file history, the constraints of the existing
timeline command could be avoided.


> == relative revisions - history analysis ==
>
> In Fossil there is no way to refer to a parent of a revision, with the 
> exception the parent of checked out revision.
>
>
Once in a while, being able to specify a revision relative to another would
be handy.

While git's ^ suffix is simple, tag+n or tag-n would be more flexible.

== show - history analysis ==
>
> I like "git show" and "svn log --diff" as they give me all information about 
> commit I need ...
> It would be even better if show were universal.  By "universal" I mean that, 
> ideally, it should work the same way for a tree change, file change, wiki, 
> ticket and so on.
>
>
I don't really miss this command, as it is very easy to just use the web UI
to see the differences.

But, I can see where a "fossil show" command could be handy as finfo isn't
really a variant of info for files.

== "checkout as repository" ==
>
> When you come from svn or git, the very first question is "why do I need to 
> _open_ the repository I've just cloned?".  ...
> Each of computers I use has at most one checkout of each repo.
>
>
Coming from SVN, "fossil open" was basically the same as "svn checkout"
with a different name. (I'd prefer "fossil checkout" be an alias of "fossil
open", but in Fossil it has a different function.)

The few times I have setup a local "slave" SVN repository I still had to do
"svn checkout" to create a working copy. (SVN is not a distributed VCS, so
you must commit directly to the one repository. "Slave repositories" were
introduced as a way to have a local, read-only copy of the repository, but
commits still have to go first to the "main" repo, then the slaves have to
pull from the main.)

So doing "fossil open" after doing "fossil clone" (or "fossil new") was
nothing strange or new to me.

Perhaps adding a "--open" option to the "fossil clone" and "fossil new"
commands would be a reasonable enhancement to Fossil. (I think this
approach would be cleaner than having Fossil try to guess what you are
asking it to do.)

"git clone" was weird to me at first. Also I very much used SVN's ability
to have multiple working copies checked out from a single repository. With
git I have to clone the repository to get additional working copies. And
then I have to push/pull changes between them.

== wiki syntax ==
>
> One of the weaknesses of the web interface is wiki syntax.  After you chose 
> markup format and click "Create", you have to keep formatting rules in mind.  
> ...  I would appreciate a lot if there were links to the official wiki_rules 
> and md_rules files.
>
>
This can be added by editing the header and/or footer (Admin->Skins->Header
or ->Footer). It is possible to conditionally display links based on the
page being displayed (and/or other factors).

Perhaps someone could update the default "skin" for the Fossil UI to
include a wiki help link.
___
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: Why we should NEVER use inetd/xinetd

[Ron W]

On Sat, Oct 22, 2016 at 8:32 PM, 
wrote:
>
> -- Forwarded message --
> From: Nathaniel Reindl 
> To: "Fossil SCM user's discussion" 
> Cc:
> Date: Sat, 22 Oct 2016 19:56:51 -0400
> Subject: Re: [fossil-users] OT: Why we should NEVER use inetd/xinetd
> > On Oct 22, 2016, at 17:23, K. Fossil user  fr> wrote:
> > 2/ Xinetd is old (four years ?) so may be not secure.
>
> xinetd is actually older than that. It may have not, for whatever reason,
> seen a recent release.
>

I think what K meant was that it has been more than 4 years since the last
new release of xinetd. I also noticed it was about 7 years to the previous
release.

I do agree that assuming too much from a project being long time since the
latest release is folly.

Even a very new release could be insecure.

Xinetd is actually small and simple compared to a lot of servers with a lot
of recent activity. It might be that none of the few currently open issues
is an actual security problem. I have not audited the code, however, I
don't see any recent CERT advisories about xinetd.

I don't use xinetd. I have no need for it. I don't run any services other
than Fossil on my computers.
___
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] remote check in

[Ron W]

On Sun, Oct 23, 2016 at 8:00 AM, 
wrote:
>
> From: "K. Fossil user" 
> Date: Sun, 23 Oct 2016 00:51:40 + (UTC)
>
> I was wondering if it is possible to do EVERYTHING [Fossil related of
> course] in a browser.
> I guess in theory it should be, but in practice?
>

For documentation, this could be done. Fossil does part of this. Could be
improved.

For source code, this more complicated.

Sure, you could edit your source code in a webbrowser, But what about
building it? You either have to download your source files to build them
locally, or run the build on the server. Generally, this is considered to
make it too easy to commit untested changes.

Or you can edit your sources locally, build and test, then upload your
sources through the browser.

A better approach would be to make a GUI client application for Fossil,
similar to TortoiseHg. The most successful project to do this - that I know
of - is fuel-scm.org

Alternately, some IDEs still support command line version control
"providers". At least as of 2.5 years ago, SlickEdit did.  For several
years, I used Fossil through SlickEdit's GUI.
___
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] remote check in

[Ron W]

On Sun, Oct 23, 2016 at 8:00 AM, 
wrote:
>
> From: Andy Bradford 
> Date: 22 Oct 2016 20:48:42 -0600
>
> Thus said Scott Doctor on Sat, 22 Oct 2016 15:40:33 -0700:
>
> > The problem I am having is how to add files, do check-ins and such via
> > the  UI,  mostly regarding  doing  it  remotely without  command  line
> > access.
>


> There do exist tools  that wrap the commands  in a UI. For  example,
> TortoiseSVN,
> TortoiseGit, etc.
>
> I believe I have seen someone announce on this list a wrapper UI for the
> Fossil commands. Maybe search the archives?
>

That I have heard of, https://fuel-scm.org (there were a few others, but
they are too out of date).
___
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] Pedagogy Think Tank or Documentation Framework RFC

[Ron W]

On Tue, Oct 11, 2016 at 6:19 PM, Adam Jensen  wrote:

> On 10/11/2016 03:39 PM, jungle Boogie wrote:
> > I would call that a wiki, not only inside fossil-scm but in general.
>
> I am inclined to think that a wiki probably isn't sufficient for many
> projects. What I am casually proposing (just brainstorming, really) is a
> documentation framework that supports several different types of user
> (annotation) and developer (modification) involvement, all regulated by
> policy automation and human/system assessment, modeling and analysis.
>

Sounds like something Google Docs does or could easily do (at least in
Google docs for Business).
___
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] Pedagogy Think Tank or Documentation Framework RFC

[Ron W]

On Tue, Oct 11, 2016 at 6:19 PM, Adam Jensen  wrote:

> On 10/11/2016 03:39 PM, jungle Boogie wrote:
> > I would call that a wiki, not only inside fossil-scm but in general.
>
> I am inclined to think that a wiki probably isn't sufficient for many
> projects. What I am casually proposing (just brainstorming, really) is a
> documentation framework that supports several different types of user
> (annotation) and developer (modification) involvement, all regulated by
> policy automation and human/system assessment, modeling and analysis.
> (Too much razzle-dazzle?)
>
> I started to sketch some diagrams earlier but ended up exploring
> [something like] enterprise architectures for various
> developer(s)/maintainer(s)/user(s) social organization. (See the work of
> [Max Weber][1] and [Karl Müller][2]).
>
> [1]: https://en.wikipedia.org/wiki/Tripartite_classification_of_authority
> [2]: https://en.wikipedia.org/wiki/Karl_H._M%C3%BCller
>
> Making the operations (policies, procedures, etc) of the system
> explicit, and the assessments and measurements quantifiable, all with
> significant automation support, once bootstrapped, a project could
> continue with little human involvement. If the documentation system
> includes pedagogical information and methods sufficient to train users
> to be maintainers and developers, such a project could endure the
> vicissitudes of interest.
>
> ___
> 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] How to make post-commit hook?

[Ron W]

On Tue, Oct 11, 2016 at 9:26 AM, Svyatoslav Mishyn 
wrote:
>
> as Commit Script I have this:
> tclInvoke catch {exec /home/juef/bin/f2g test}
>
> but it looks like a commit script is executed before commit:
> /home/juef/fossil/test: date >> z && f ci -m f1
> /home/juef/fossil/test: date >> z && f ci -m f2
> /home/juef/fossil/test: date >> z && f ci -m f3
>
> /home/juef/git/mirrors/fossil/test: git --no-pager log -n 3
> --pretty=format:"%s%n"
> f2
> f1
> 11
>

Have you looked at the contents of z in each the 3 most recent commits in
git? Do the changes in the date string in z match what was committed to
Fossil?
___
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 make post-commit hook?

[Ron W]

On Tue, Oct 11, 2016 at 9:26 AM, Svyatoslav Mishyn 
wrote:
>
> in git repo I have this:
> /home/juef/git/mirrors/fossil/test: cat .git/hooks/post-commit
> #!/bin/sh
>
> fossil_dir=/home/juef/fossil
> repo=test
>
> /home/juef/bin/g2f "$repo"
> cd "${fossil_dir}/${repo}" && fossil co trunk
>

"fossil co trunk" does a Fossil check out, so I don't see how that updates
the Fossil repo with the git commit.
___
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] Files named "AUX" on Windows

[Ron W]

On Tue, Oct 4, 2016 at 2:54 PM, Scott Robison 
wrote:
>
> We could modify the Windows code to use the \\.\ prefix trick and then
> fossil could create / delete the files. If we did that, how much pain would
> it cause to other tools and processes on the Windows system?
>
> If we don't support it, Fossil potentially looks bad to someone for not
> creating what appear to be ordinary file names. If we do support it, Fossil
> potentially looks bad for creating files or directories that other
> processes can't interact with normally.
>

This problem is not unique to Fossil. Several years ago, a (then) coworker
of mine cussed at Windows when files he added to whichever VCS his
department was using (Synergy, I think) could not be checked out on a
windows PC.
___
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] Unversioned files.

[Ron W]

On Sun, Sep 11, 2016 at 12:18 PM, Adam Jensen  wrote:
>
> The phrase "ephemeral content" is a bit disconcerting. It suggests
> values and attitudes towards this data which will probably be reflected
> in the requirements, specification, and implementation of the software.
>
> In the use-case I have in mind, this data would be "immutable content"
> and should be considered precious. The goals would be to avoid
> accidental loss and/or corruption. It isn't a low-value, fleeting
> scratch-pad that would be thrown away on a regular basis.
>

Unversioned means that if the file is committed again, the new contents
will replace the current contents.

If you only ever commit the (unversioned) file once, then it's contents
will remain.

I suppose, what you are looking for is a mechanism for preventing further
commits to those files, therefore preventing the contents from being
replaced.

Perhaps marking the file as a "closed leaf" could be used as a means to
achieve this immutability you are seeking.
___
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 import a few commits from a git mirror?

[Ron W]

On Sat, Aug 27, 2016 at 12:46 PM, Natacha Porté 
wrote:

> Hello,
>
> Short version: I have a git repository built a mirror of a main
> repository, a few changes happened to the git repository, and I would
> like to find a way to bring these changes back to the fossil repository
> so that the git repository can again be a simple mirror.
>
> Now sometimes people send pull requests on github, and sometimes I find
> them good, so for various reasons (mostly attribution) I accept them.
> So I end up with a git repository that no longer a mirror of my fossil
> repository, and I am looking for a way to get back to that state.
>

Since this is not frequent, maybe you could just merge the changes in your
git working copy to your Fossil working copy, then "fossil commit
--user-override"
to commit the changes back to Fossil. You could also include the git commit
ID in the commit comment or as a tag on the commit.
___
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] Fix for stash-next pointer (fix for the fix)

[Ron W]

On Thu, Aug 18, 2016 at 4:03 PM, Warren Young  wrote:

>
> I don’t argue for this to make git users happy, but instead to make Fossil
> more like Subversion, where there is no additional step required check out
> a new repository.
>

Technically, Fossil checkouts do work (almost) the same way as SVN check
outs:

svn checkout repositoryURL

fossil checkout /repository/path

But, yes, almost every time a local clone of a Fossil repository is made,
the next step is to checkout a working space. So, it would be convenient to
have an option for clone (and init) to automatically checkout a working
space. (Or maybe an option to checkout to auto-clone (or auto-init) a repo.)

But, I do many more checkouts from a local repo than I make clones, so the
extra command the first time isn't an issue for me.
___
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 host fossil repositories on web server that supports only FastCGI interface?

[Ron W]

On Wed, Aug 3, 2016 at 6:08 AM, John Found  wrote:

>
> Well, I was actually wrong. fcgiwrap actually *can* wrap bash cgi scripts
> (and also, perl, etc.)
> So, the problem is solved and I can recommend using fcgiwrap tool for
> hosting fossil repositories
> on high performance web servers without CGI support, like nginx and rwasa.


Another, possibly better, option occurred to me. If the webserver supports
it, configure it to "pass through" to Fossil and run Fossil in server mode.
Essentially, the webserver would be acting as a proxy server for the base
URL for Fossil. ( I recall seeing something about how to configure Fossil
to operate from behind a proxy)
___
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] Compiler warnings

[Ron W]

On Tue, Aug 2, 2016 at 8:00 AM, Stephan Beal  wrote:
>
> As i rememeber it, sqlite3 won't compile with strict C89 mode because of
> its use of (long long), which is C99 (but is apparently implemented in all
> C compilers when not running in strict C89 mode).
>

This makes me wonder what the benefit of staying with the C89 specification
instead of the C99 specification. Are there really still compilers in use
that don't implement C99?
___
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] basic usage question - empty directories

[Ron W]

On Tue, Aug 2, 2016 at 12:26 AM, Adam Jensen  wrote:

>
> Subversion has "Repository Hooks" (a program triggered by some
> repository event); Fossil might have had a similar capability ...
> worth asking.


With all the right things enabled during build, Fossil can run TH1/TCL
scripts on certain events. But, aside from updating Fossil metadata, can
only notify the "outsife world" by sending an HTTP request to a specified
URL. I am pretty sure the scripts can construct the URL used, so some
information can be encoded in the URL.

Otherwise, the main mechanism for automated publication of notices is RSS.
___
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] basic usage question - empty directories

[Ron W]

On Mon, Aug 1, 2016 at 8:22 PM, Adam Jensen  wrote:

> On 08/01/2016 07:40 PM, bch wrote:
>
> > in a controlling file. Something like a purpose-built makefile or
> > script that handles this layout, so that -it- can be versioned in
> > fossil; fossil wasn't/isn't currently designed to handle that sort of
> > metadata - which *arguably* should be handled in a script as described
> > above. Fossil can then handle that script as an artifact.
> >
>
> Is there a way to run these scripts automatically after each checkout?


My team and I do this as part of the build procedure. Basically, we treat
those as part of the "product" being built, so when we do a "clean check
out", the first run of make will create those directories. We don't need
them before that.
___
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-scm as an SQLite db with schema/data revision control

[Ron W]

On Sun, Jul 24, 2016 at 10:58 PM, Adam Jensen  wrote:

>
> [The Session Extension](http://www.sqlite.org/sessionintro.html) pointed
> out by Eduardo seems to have a lot of potential.
>
> "The session extension provides a mechanism for recording changes to
> some or all of the rowid tables in an SQLite database, and packaging
> those changes into a "changeset" or "patchset" file that can later be
> used to apply the same set of changes to another database with the same
> schema and compatible starting data. A "changeset" may also be inverted
> and used to "undo" a session."
>
> Wow, whoever designed that extension had Vision.
>
> Given this capability, would you still use Fossil tickets to record,
> manage, and communicate the changesets or do you suppose the changesets
> (or some variation) might somehow be stored in the blob table?


I was only suggesting tickets for the schema updates.

Eduardo's description of the SQLite extension only talks about table data.
This would still leave a need for managing schema updates.

If this SQLite extension also handles schema updates, then probably no
reason to use tickets.

In either case, the actual changesets should be suitable to manage as files
in Fossil.
___
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-scm as an SQLite db with schema/data revision control

[Ron W]

Hello,

What you are thinking is not impossible.

You do need to be aware that Fossil only uses SQLite as an index engine.
Fossil does not synchronize the actual databases, only the "artifacts"
(stored as "blobs" in the database). Aside from the blob table, the tables
in the database are derived from the information in the artifacts.

When information in a Fossil repository is added or updated, Fossil creates
new artifacts to contain the new or update information, stores those in the
blob table, then updates the various other tables.

When Fossil pushes to or pulls from another repository, only blobs are
transferred. The receiving Fossil adds those to it's blob table, then
updates the other tables as needed.

Fossil could be used to synchronize 2 or more SQLite databases. Schema
updates could be handled as tickets, the body of each ticket containing the
SQL commands required to make the schema changes. For new clones of the
database, a serialized version of the schema could be used, rather than
"replaying" the schema tickets. Synchronizing tables would require
serializing their content into artifacts, which Could then be pushed/pulled
normally by Fossil.

The serialization of the schema and the table contents would have to be
done by an external application. Maybe libfossil could help with that.
Otherwise, each new artifact could be created in to a file, then the files
committed into Fossil using system() calls to invoke Fossil's command
interface. Alternately, the artifacts could be added as wiki pages via
Fossil's HTTP interface (which would avoid launching the Fossil application
multiple times, though the push/pull would still have to be done via the
command interface).


On Sat, Jul 23, 2016 at 3:33 PM, Adam Jensen  wrote:

> I'm a little puzzled by the lack of response - good, bad, ugly, be gone
> with you - anything will do. Is this kind of speculation taboo in this
> community or does it just take time to ponder the implications? Would
> the SQLite developer list be more appropriate/receptive? I'm very
> unfamiliar with these communities and I am concerned that I might have
> stumbled into some kind of faux pas here.
>
>
> On 07/14/2016 02:31 PM, Adam Jensen wrote:
> > I sent a message last night before joining the mailing list (today) and
> > I'm not certain if it (last night's post) was distributed to the list or
> > not. It's not displayed in the list archive yet. Just in case, here it
> is:
> >
> > On 07/13/2016 06:18 PM, Adam Jensen wrote:
> >> This might be a bit convoluted but is it possible to use fossil-scm as
> >> an SQLite db with the schema/data under revision control? If this
> >> functionality doesn't already exist in fossil, would it be difficult,
> >> awkward, or crazy to try to implement it?
> >>
> >> It seems like such an obvious thing to do that I guess it either already
> >> exists or it's so technically twisted that it's virtually impossible.
> >>
> >> If this functionality doesn't exist, how would you do it?
> >
> > After thinking a little more about this, it seems like maybe this isn't
> > something that should be incorporated into Fossil [or SQLite] but rather
> > this could be a third system that is based on the other two.
> >
> > To add a little more verbiage and description to the basic idea, what I
> > am imagining is (I'm going to assume that in this new system a single db
> > file can support multiple databases) an SQLite database with version
> > control on the schema and data. This might be accomplished in a fashion
> > similar to the original SCCS - every SQL command that causes changes to
> > the [working copy] database is saved in the version history (a
> > fossil-like database in this common db file). With this, any version of
> > the database could be recreated by replaying the history. This process
> > could be sped up by saving or creating snapshots of the database at
> > various moments in its history (all in the common db file (and, perhaps,
> > read-only)) and then a specific version can be created by replaying the
> > relevant set of SQL changes made after the snapshot. (This description
> > is just to get the idea across; there are probably more clever ways to
> > implement it).
> >
> > Another aspect of this third system is the typical fossil-like data
> > sharing. So basically, this could be a distributed, multi-user database.
> > Each user would have a local copy (fast access) with their own branches
> > (write control) but there could be data sharing through merges. (This
> > probably sounds obvious to fossil users but think about it from the
> > perspective of sharing database content rather than sharing a pile of
> > files (source code).
> >
> > For fun, and somewhat whimsically, a name for this Fossil/SQLite hybrid
> > might be DVCSQLite .
> >
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > 

Re: [fossil-users] Constructing Base URI With TH1 Variables

[Ron W]

On Sun, Jul 17, 2016 at 2:08 AM, John L. Poole  wrote:

> On your suggestion, I inserted code on the setup_header page to this:
>  
>  if {[hascap r]} {
>   html "\n"
>  }
>  
>  
>
> And that worked: the baseURI variable in DOM was set to
> "http://themis:8080/tktview?name=149873cca9;
> 
>
> However, each page now complains
> "ERROR: no such variable: tkt_uuid"
> and is missing styling and the heading matter.
>

Test  $current_page for "tktview". If true:
 html "\n"
else:
 html "\n"
___
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] Constructing Base URI With TH1 Variables

[Ron W]

On Sat, Jul 16, 2016 at 1:49 PM, John L. Poole  wrote:

> The Edit Page Header allows one to define an HTML page  element's
> child
> using TH1 variables:
>
>
>
[...]

> But the Base URI as defined by the above concatenation is really:
>
>http://themis:8080/tktview
>
> since $current_page is valued at "tkview".
>
> What I'd like is to have a TH1 variable that allows me to construct a
> value like"tkview?name=149873cca9" or
> "tkview/149873cca9e566ab28d2b9922e44a515a639c3ff  http://themis:8080/tktview>"
>

You can specify the TH1 and HTML for tktview. In that, you will have a
variable with the ticket ID (don't recall name right now and replying from
my tablet), so could build the URL using 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] Further mailing list configuration changes.

[Ron W]

On Thu, Jun 30, 2016 at 11:38 AM, K. Fossil user <
ticketpersonnal-fos...@yahoo.fr> wrote:
>
> As I said, the correct behavior should be : "reply-to" the Fossil SCM
> list...
>

Looking at the email headers, I see "Reply-to: Fossil SCM user's discussion
", so that part is correct.

As for the From header, a newer version of the Mailman list manager would
get us the option to replace just the address in the From header. That
would help mitigate the problem that Richard was trying to patch by
configuring the list to anonymize posts.


> but ask them for a poll about future of Fossil (mailing list included)
> then many will read, and some people just answer.
>

Maybe a poll could be done.

3 options I can think of right now, that I see as options in (a newer)
Mailman, are "replace From address", "anonymize" or "do nothing".

I like "replace From address".

Other options might require new features in Mailman (or switching to
another list manager).


> "Hey they don't know how to deal with a mailing list"
>

Lots of good projects don't know how to properly manage a mailing list or
forum.

This thread is about improving how Fossil's mailing list can be improved.
___
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] A scheme to insert the Fossil checkin ID into a built executable

[Ron W]

On Tue, Jun 28, 2016 at 1:34 PM, Warren Young  wrote:

>
> 5. My scheme modifies one of the input source files — as opposed to
> modifying the built executable, as in Ron W’s scheme — which means you
> could have an executable that claims to be built against the prior checkin
> on the current branch instead of the current checkin.  That is, if you edit
> a file, build the software, test it, and then check the change in, the
> checkin ID containing the change doesn’t match the checkin ID in the
> executable until you build again.
>

As I mentioned in my post, our build system does a commit in the post link
phase of the build, so the ID embedded in the executable matched the commit.

I know some people don't like committing untested code, but our team
follows a "commit early, commit often" philosophy. We do, for the most
part, commit only code that compiles and links. Also, we have the option to
do "debugger only" builds, which don't do the commit, and generates an
executable that can only run with the debugger.

Builds that are to be run without the debugger get programmed in to
electronic modules. Because the modules can be picked up and taken away,
it's very important we are able to identify the software in them. (We have
a special tool to do that.)
___
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 such an scm with GUI?

[Ron W]

On Mon, Jun 27, 2016 at 2:39 PM, followait  wrote:

> In such an scm with GUI, one can:
> 1.  diff / merge / rebase by draging one commit to another
> 2. more generally, everything can be done in the GUI, it can be intuitive
> enough, so that no doc is needed
> 3. by the easy usage and full functionality, it helps the programmer focus
> on his/her essential work
>

In the past, I have used TortoiseSVN and TortoiseHg on MS Windows. Assuming
you have a decent understanding of branching, that fairly intuitive in
either of those. Personally, I have always done merging from the command
line, so I can't tell you about how well these 2 handle merging.

I know of RapidSVN, which is a cross platform GUI SVN client. Tried it
once, years ago. Don't remember much about it.

Also, some IDEs, such as SlickEdit (which is available on both Linux and MS
Windows) have good support for integrating with command line VCSs. However,
merging is usually not supported in the IDE for command line clients.

Also, in the post-link phase of my (at work) team's software builds
(assuming a successful link), our makefiles do a commit then fetch the
commit ID (a separate fetch because we sometimes do commits as we edit, so
the "auto" commit might have nothing to do). The commit ID is then inserted
into the software header of the "load image" created in the final steps of
the post-link phase.

(By incorporating the commit ID into the software header, we are able to
always able to retrieve the exact sources for any given build with out
"polluting" the version number or worry about the filename being changed.)
___
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] Merge tracking tests in a blog entry, some questions

[Ron W]

On Sat, Jun 18, 2016 at 1:21 PM, Paul Hammant  wrote:

> Curiosities:
>
>- Having a database name rather than just a .git or .svn folder
>convention
>- The 'open' step.
>
> Fossil and SVN are more similar than you seem to think.

Fossil's "open" command is much like SVN's "checkout" command. Both take a
path to a repository. The difference being that Fossil expects a local
database file while SVN expects an URL to the repository, which SVN treats
as remote, even if it is local. This is because SVN clients all work from a
central repo, while Fossil works with a local repo that might be a copy of
a remote/central repo. And, like SVN's "checkout" command, "open" also
checks out files into your working copy.

Also, like SVN, when a working copy is created, a .fossil file is created
in the base folder of the working copy. (SVN uses a folder, Fossil uses a
database file.)

Fossil's "update" is pretty much the same as SVN's "update".

Fossil's "checkout" is a bit different. While it fetches the specified
version of files, it does not attempt to merge with local changes.

So, like SVN, Fossil allows multiple working copies from the same repo. But
Fossil working copies are associated with a local repo while SVN working
copies are associated with a remote/central repo.

The local Fossil repo is what might be associated with a remote/central
repo. A pull, push or sync command done from any of the working copies will
cause the associate repo to interact with the remote repo. SVN commands
always interact directly with the remote repo, so SVN doesn't have pull,
push or sync.

Also, when you commit from one local working copy, you can then update from
another local working copy without doing a pull, push or sync. Remote
working copies won't be able to update to your commit until pull, push or
sync (as appropriate) is done to get the commit transferred.

git, on the other hand, every working copy has it's own local copy of the
repo, so each local working copy is completely independent, just as a
remote working copy would be. To transfer commits between git working
copies - local or remote - you have to pull, push or sync.

>From my point of view, Fossil provides the best of a DVCS with the best
features of SVN or other non distributed VCS. I can perform VCS operations
"off line", even with multiple working copies (with only one local copy of
the repo), then still be able to easily sync to a remote repo once online.
___
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] Preferred way of dealing with upstream projects maintained in different VCSes?

[Ron W]

On Wed, Jun 15, 2016 at 10:02 PM, lvh <_...@lvh.io> wrote:

>
> These are important to the software we’re building, so they ought to live
> in VCS, or at least a reference to them should. How do you manage this?
> Just put the .git dir in version control? Bare checkout? Something that
> references the repo + commit but keeping the actual checkout out of source
> control?
>

The .git dir is the local copy of the git repository, so that could be a
huge thing to keep in another VCS - Fossil or other.

If you are only "reading" the upstream projects, you could export the git
repo and import it to Fossil. Once done the first time, you should be able
to do it incrementally. Other VCSs can be exported to Fossil. Fossil
recently acquired support for importing from SVN. Other VCSs would require
exporting to either git or SVN export format, then importing to Fossil.

Would be simpler to just fetch tar/zip files of the other projects as
needed. Then you could either untar/unzip those and commit in to Fossil
locally, or just reference in your makefile (or whatever your build system
uses) by defining a "pointer" to where the files were untared/unzipped.

To make contributions to the upstream projects, you could send patch files.
But many projects - especially those on github - expect pull requests, so
you'd need to have local copies of the repos.

When I make contributions to git based projects, I update my local copy of
the repo, update my Fossil repo of the project and manage my changes with
Fossil. When I'm ready to submit my changes, I update my local git repo,
merge any upstream changes to my changes and commit to my local git repo
(and to Fossil). Then, if applicable, push to my github "fork". Then,send
out the pull request.
___
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] multiple open leaf on closed branches?

[Ron W]

On Tue, Jun 7, 2016 at 2:27 AM, Luca Ferrari  wrote:
>
> In the meantime I've tried the desperate trick:
>
> % fossil merge --integrate  --force aa9521ccd9
>
> but the leaf is still listed on the open ones.
>

As Richard said, it's not a real problem.

I would suggest you compare the files in the extra open leaf with it's
sibling commit(s) to be sure you don't miss any changes.
___
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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Ron W]

On Mon, May 30, 2016 at 4:39 PM, John P. Rouillard  wrote:
>
> In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>,
> Ross Berteig writes:
> >One of the hooks is "command_hook" which is invoked for every
> >fossil command. That name can raise an error (or call break or
> >continue) to prevent the fossil command from executing.
> >
> >Since the hook is called early, it knows the command name, its
> >arguments, its flags, and not a lot lse.
>
> Well if the hook was executed, I could use it to reject a
> --no-th-hooks, but ironically it would never see it 8-).


On any distributed VCS, hooks are like training wheels. They help the user
follow process, but a determined user can take them off.

I hadn't seen documentation on command_hook, but it does get executed
before the list of files with changes is "calculated" so would have to
(somehow) duplicate that functionality.

However I would expect the server would run the hook on an
> incoming commit.
>
> Hmm, now that I think about it, are all the hooks defined in the
> "transfer"(xfersetup) admin page, so they are only run on the
> client?


I think the receiving server also runs hooks, but I don't know.

I don't see where to configure the command_hook on any of the admin pages,
but I'm using the 1.34 released version, not the latest development version.

>The fossil -no-th-hooks option will skip all hooks for that
> >command.  Depending on what else you do in a hook, that might be
> >more than you wanted.
>
> Yup. The embedded codeword allowed fine grain tuning of the
> checks and also recorded whet the developer requested so s/he was
> accountable for the bypass. If any client can disable hooks on
> the remote central repo without any logging/accountability this
> is all moot.


Hooks can only be disabled locally.

Of course, Fossil will have a record of the commit and who did it. So, you
use an assumption of "bypassed unless proven otherwise".

>>Is there some similar way to inspect the transferred artifacts
> >>and file contents and roll back the commit?
> >
> >Nope. And there can't be. Nothing is transferred until well
> >after the whole collection of artifacts that make up the commit
> >have been created and safely stowed in the local
> >repository. There is no "roll back" from that.
>
> Err, that's unfortunate. I was expecting that the order of operations
> for a commit on the server (or a local repo) would be:
>
>   open connection to client (or in the case of local file access,
> just open the sqlite file)
>

When you run "fossil commit", Fossil is directly updating the database
residing on you PC.

If "auto-sync" is turned on, Fossil will automatically pull from the remote
server before processing the commit, then automatically push to the remote
server after processing the commit, but the commit process itself is local
only.

When a remote Fossil server receives a commit from your local repo, it
could run its own commit hook. I don't know if does. Right now, as best I
can tell, only a post_commit hook is available.

I'm not sure all of the implications and collateral damage of a pre_commit
hook on a receiving server. Fossil's current approach is to block all
pushes from users not authorized to push. (Contributions from those users
can, however, be pulled, in which case, Fossil records both who made te
commit and who pulled the commit.)


>   start transaction in database

[...]

> commit transaction
>

Internally, "fossil commit" does this. It just doesn't have a hook just
before committing the database transaction.

However, on a receiving server, commit processing is much simpler.

Overall it sounds that wrapping tools are required to support
> process and validation with fossil rather than supporting the
> process within fossil.
>

At least for "fossil commit", a workable pending_commit hook could be
implemented. Though there is a complication: any commit that has a "base
line" manifest (as opposed to "delta manifest") will list all "current"
artifacts, not just those changed by the commit, so the hook would also
need a way to get a list of artifacts for just the changed files.
___
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] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[Ron W]

On Fri, May 27, 2016 at 6:58 PM, John P. Rouillard  wrote:

>
> On that note, does anybody have code for tcl hooks that can be used to
> reject artifacts that have text that matches a particular pattern.


The closest Fossil has to this is the "commit permission", which blocks the
commit based on the user ID.

Otherwise, to "roll back" a commit requires shunning the manifest.
(Shunning the files is also possible, but you have to be careful to only
shun the ones that actually changed in that commit).

Either way, the originating repo will still have the commit.
___
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] web-UI's timeline should use non-proportional font for commit hashes

[Ron W]

On Tue, May 24, 2016 at 6:53 PM, Marko Käning 
wrote:

>
> ---
> a.timelineHistLink {
>   font-family: courier;
> }
> ---
>
>
Fossil has the capability for user defined "skins". Never used it myself,
but I have seen some nice custom skins for Fossil.

BTW, I assume CSS has styling modifiers, so I'd probably use "font-style"
(or whatever it is) to specify "monospaced".
___
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 2.0: rethinking extras, addremove, and clean

[Ron W]

On Tue, May 24, 2016 at 9:11 AM, Joerg Sonnenberger  wrote:

> On Tue, May 24, 2016 at 07:06:18AM -0600, Warren Young wrote:
> > On May 22, 2016, at 2:49 PM, Andy Goth  wrote:
> > I wouldn’t mind seeing all but “extras” go away.  You should be able
> > to run your build system’s clean command, then run “fossil extras” to
> > learn what files your build system still needs to be told about.
>
> Having to clean the build before finding out what potential new files
> exist is extremely unfriendly...
>

I think Warren is talking about files created by the build system.

However, with a properly set up ignore-glob, "fossil extras" will ignore
those files (but I don't see a --no-ignore option).
___
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] keep-glob

[Ron W]

On Mon, May 23, 2016 at 3:55 AM, Jan Nijtmans 
wrote:

> 2016-05-23 2:46 GMT+02:00 Andy Goth:
> > What is the difference between keep-glob and ignore-glob?  As far as I
> > know, stuff in keep-glob shows up in extras and addremove, whereas it
> > would be excluded if in ignore-glob.  Are there any cases where you'd
> > want to protect something from cleaning yet want it to show in extras
> > and addremove?
>
> Well, keep-glob was added to fossil on my request. Everything I have
> put in keep-glob is in ignore-glob too, I cannot imagine any usecase
> for putting something in keep-glob without putting it in ignore-glob too.
>
> > Is there any difference at all between having something in keep-glob
> > only and having it in both keep-glob and ignore-glob?  I don't think so,
> > but maybe I'm wrong.
>
> I think it's wrong to put something in keep-glob without putting it
> in ignore-glob too. I never do that.
>

To my thinking "keep-glob" and "ignore-glob" are 2 different features with
different symantics. So far, I have not had a need to use keep-glob as I
don't use the "fossil clean" command.

But, I see that the description for ignore=glob says 'files that the "add",
"addremove", "clean", and "extra" commands will ignore'. So, if everything
in the keep-glob is also in the ignore-glob, what does keep-glob do that
ignore-glob doesn't do?
___
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] Automatic Ticket-commit tagging

[Ron W]

On Mon, May 23, 2016 at 10:41 AM, Steve Schow  wrote:

> Is it fair to say, tickets, wikis and checkins are stored in artifacts….
>  while pretty much all configuration stuff including TH1 code, SQL, UI
> enhancements, etc are probably not artifacted?
>

I don't know if they are also stored in artifacts. That would be a question
either for the Fossil source code or Richard. The "fossil config" command
does allow for pushing/pulling configuration, so there might be artifacts,
possibly temporary, so that configuration can be pushed/pulled using the
same mechanism as repository content.


> Except for this .fossil-settings folder you mentioned, which I was not
> aware of…what is in there?
>

In the Fossil web UI of your repo, go to Admin -> Settings (probably
http://localhost:8080/setup_settings)

Some of the setting listed on that page are marked with (v). those are the
version-able settings  Under the edit-able list of settings, there is:
> Settings marked with (v) are 'versionable' and will be overridden
> by the contents of files named .fossil-settings/PROPERTY
> in the check-out root. If such a file is present, the corresponding
> field above is not editable.

Another way to version the settings is to use "fossil config export" and
"fossil config import", which save/restore the settings to/from a file that
could be versioned. However, settings in that file must be explicitly
imported to be used.
___
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] Automatic Ticket-commit tagging

[Ron W]

On Sun, May 22, 2016 at 4:42 PM, Steve Schow <st...@bstage.com> wrote:

>
> with regards to this statement…
>
> On May 22, 2016, at 1:40 PM, Ron W <ronw.m...@gmail.com> wrote:
>
> > Everything in Fossil is stored in artifacts.
>
> Are ticket reports stored as versioned artifacts?


I should revise that: Everything that isn't configuration is stored in
artifacts. I don't know if any or what portion of configuration is stored
in artifacts.

I do know that so called "version-able settings" rely on files in
.fossil-settings folder in the root of a check-out. These files can be
managed by Fossil the same as any other files. As for how other settings
are stored, even if they are stored in artifacts, Fossil doesn't expose an
interface for accessing nor managing their history.
___
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 2.0: rethinking extras, addremove, and clean

[Ron W]

On Sun, May 22, 2016 at 12:38 AM, Andy Goth  wrote:

> On 5/21/2016 9:03 PM, Joe Mistachkin wrote:
> > Andy Goth wrote:
> >> The clean command has gotten very complicated,
> >
> > Unfortunately, most of the complexity is necessary and removing or
> > changing the semantics would risk breaking existing repositories,
> > including some of the ones I use on a daily basis.
>
> Yup, hence the "Fossil 2.0" in the subject line.  But I'm very
> interested to know how you use the features I'm struggling to myself
> find a use fur.
>

My team and I don't have a use for a clean command in a VCS. The build
systems "knows" how to clean up files it creates. Any other files not
managed by the VCS are the responsibility of the user.

I know some people like "clean" to help with making clean builds. But we
see a proper clean build as making an entirely new check-out from just the
content of the repository. Anything else is not truly clean.
___
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 2.0: rethinking extras, addremove, and clean

[Ron W]

On Sun, May 22, 2016 at 12:38 AM, Andy Goth  wrote:

> On 5/21/2016 9:03 PM, Joe Mistachkin wrote:
> > Andy Goth wrote:
> >> The clean command has gotten very complicated, so I further advocate
> >> removing the -emptydirs and -dotfiles options and making them always
> >> be in effect.  Empty directories requiring preservation should be
> >> listed in the empty-dirs setting.  Likewise, dotfiles should be
> >> checked in or put in ignore-glob.  I also advocate removing -keep and
> >> keep-glob since I really don't know what they do that isn't done
> >> better by ignore-glob.
> >
> > Unfortunately, most of the complexity is necessary and removing or
> > changing the semantics would risk breaking existing repositories,
> > including some of the ones I use on a daily basis.
>
> Yup, hence the "Fossil 2.0" in the subject line.  But I'm very
> interested to know how you use the features I'm struggling to myself
> find a use fur.
>
> --
> Andy Goth | 
>
>
> ___
> 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] Automatic Ticket-commit tagging

[Ron W]

On Sat, May 21, 2016 at 4:36 PM, Steve Schow  wrote:

> Thanks for that information.  I was not aware that ticket changes involved
> artifacts also.
>

Everything in Fossil is stored in artifacts. The DB serves as artifact
storage, indexing of artifacts and a convenient cache of data from the
artifacts. All the artifacts could be dumped into files, then later, a new
DB could be constructed from the artifacts.


>   A few months back when I first started using fossil I batch changed a
> bunch of tickets using SQL, I changed the value of the subsystem column..
>  since then I’ve gone in and edited many of the same tickets using the web
> ui and the subsystem value didn’t seem to revert back to anything, and
> everything seems fine, but now you have me a little worried that in some
> cases the artifacts of those tickets will be somehow out of sync with the
> SQL at some point in the future.
>

As long as your repository is not exchanging ticket updates with another,
the DB tables should retain all the information.


>  But thanks for the heads up, in the future if I am going to batch update
> a bunch of tickets I will use the fossil ticket command to do it in some
> way.
>

That would be much safer.
___
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] Automatic Ticket-commit tagging

[Ron W]

On Fri, May 20, 2016 at 10:43 AM, Steve Schow  wrote:

> I think perhaps you meant “commit” comment below?  Its the commit comment
> that needs to be tweaked, in theory, by the TH1…not the ticket itself.   So
> are you saying that modifying a commit comment requires that an artifact be
> created with TH1 somehow, if even possible?
>

To truly update the commit comment, you need to create a control artifact
that "attaches" an updated comment to the commit. This involves two things:
Create a string with the required "cards" (see
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki) then insert
the new artifact into the blob table. I don't know if the TH1 query
function will allow doing an insert or update. Have never tried.


> For the ticket table, I noticed in the admin page that there is a SQL
> insert statement with comments that say we can add our own columns to it
> for whatever purpose we want.  It already has a status column which could
> be used to store “working” status, but what I was thinking is I could stash
> something in a different column that basically indicates its actually THE
> ONE that is being worked on right now…  I don’t think (?) any artifacts are
> needed for putting info like that into the ticket table and using TH1 to
> check out that data from the ticket table…it would not be any new records,
> but rather an additional column to an existing row in ticket table.
>

I think it would be ok to just update the one field in the ticket table.
Just be aware that a future update to the same ticket could cause fossil to
"forget" that change as there will be no artifact to "remind" it.

Alternately, both the web UI and the Fossil command line can update fields
in a ticket, so a ticket change artifact would automatically be created.

Which ever way the field gets set, a "SELECT tkt_uuid FROM ticket WHERE
working=yes;" should find and return the UUID of the currently "active"
ticket.


> However, it makes sense that actually updating the commit comment would be
> more involved, and plenty of opportunities to get it wrong if there is no
> API for such a thing in TH1…sounds like  I would need have TH1 issue some
> SQL that does it…and make sure the SQL is doing things right internally to
> create this artifact you mentioned holding the updated commit comment.  Yes?
>
> probabably easier and safer to just put this in the wrapper script I guess.
>

Yes. But it might actually be possible to do it with just TH1 hook scripts.
___
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] Automatic Ticket-commit tagging

[Ron W]

On Fri, May 20, 2016 at 2:21 AM, Steve Schow  wrote:

> Hmm, very interesting idea about using the EDITOR feature to run a
> pre-script…i will have to ponder that…possibly an alternative to using an
> actual wrapper script….
>
> Sounds like server side TH1 probably won’t do it.
>
> throwing a table into the checkout DB would be easy enough to do…can use
> sqlite directly for that.  Its just a convenient place to put it.  I’d also
> interact with the repo’s ticket table to look for tickets that are
> “working” status, etc.  I was also thinking of adding a column to the
> ticket table in the repo and then putting something there to indicate its
> the one I’m working on…in which case I was thinking maybe TH1 could somehow
> pick it up…but it sounds like the commit operation doesn’t get to the TH1
> to do some action for adding the ticket uid to its comment?
>

Fossil has "post commit" hooks for file commits and ticket updates that run
TH1 scripts configured by the Admin/Transfers page in the Fossil web UI.

While you might be able to change the various tables in the SQL database,
creating a "control artifact" to insert in the artifact table will also be
required. Other than the artifact table, the DB tables are caches of meta
data from the artifacts.

In theory, a field like "working on" could live only in the ticket table,
but could be cleared by other updates to the same ticket.

However, to insert the ticket ID into a ticket comment will require
creating a "control artifact" to contain the modified comment (see
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki)

Alternately, you can edit the TH1 in the Edit Ticket UI page to support
your "working on this ticket right now" field. Then create a Ticket Report
that reports the currently "working on" tickets (if more than one ticket is
reported, you forgot to make the ticket as not "working on"). Then your
wrapper could use "fossil ticket show workReport" to get ID of "working on"
ticket and insert that ID in the commit comment.
___
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] Automatic Ticket-commit tagging

[Ron W]

On Wed, May 18, 2016 at 2:12 PM, Steve Schow  wrote:
>
> I’m going to try to make some kind of wrapper script to my commit command
> that can do this for me, but before I embark I am wondering if anyone has
> thought of any good ways to do this, perhaps using TH1 in the repo or
> something….or perhaps using the checkout DB in some way to keep track of
> what the current ticket is.
>

While TH1 has a query function to process SQL expressions in a TH1 script,
only the ticket hook script would be able to access the check out DB an
donly when triggered by a "fossil ticket" command line command. Even then,
I don't know if you'd have access to the check out DB.

A wrapper script might be able to use "fossil sql" command line commands to
store and retrieve info in the check out DB. I've never tried it.

The SQLite project has a command line client that could be used to store
and retrieve info in the check out DB.

My personal solution to this is to set the Fossil "editor" option to run a
script that launches my preferred text editor with the previous commit
message preloaded. Then I just edit what needs to be edited, save and quite
the editor. Then the script copies the message to the temporary file
supplied by Fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users