Re: [fossil-users] [fossil-dev] About to merge the forum-v2 branch

[John P. Rouillard]

Hi all:

In message <23ebb036-9e71-4e02-b496-1361e3852...@etr-usa.com>,
Warren Young writes:
>On Jul 31, 2018, at 7:47 AM, Richard Hipp  wrote:
>> 
>> The intent is to replace this mailing list
>
>Are you also going to import all the old content, so that people can
>clone the forum repo — assuming you still plan to keep the forum and
>code as separate repos — and get a locally-searchable archive?

According to the comment above, it looks like the forum will be a
separate fossil instance from the source code. I must have missed that
if it was stated.

Since I clone the fossil repo to my RasPI I am really not interested
in cloning the forum/mailing list along with the source code.

I throw away 99+% of the traffic on the mailing list after reading
it. I don't really want to have to keep all of that on disk.

A method that allows syncing without forum artifacts or a command to
purge forum artifacts would be helpful. This would allow clones to not
download or not permanently store possibly large forum discussions in
their repo.

Have a great day.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Backup traffic

[John P. Rouillard]

Hi all:

In message 
,
Florian Balmer writes:
>Richard Hipp:
>> ... create your backups by cloning and syncing ...
>
>Thank you for your comments.
>
>I see, this completely makes sense.
>
>The process of "restoring" a repository from backup would include
>copying database files, as syncing from backup → original might not
>work if something's gone awry with the original. My main concern here
>is that the cloned backup really includes everything from the original
>(configuration, etc.). But hearing again (haven't you already outlined
>the "cloning as backup strategy" recently, on this list?) that it
>works for the experts should give me the faith to trust it.

Does a clone/sync grab passwords and user accounts as well? I thought those
weren't copied in the clone but were private to the repository.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Syntax Highlighting

[John P. Rouillard]

In message <20531f51e58eeb700e801d854d82d...@amlegion.org>,
"Lester L. Martin II" writes:
>On 2018-07-04 10:03, John P. Rouillard wrote:
>> There is something odd happening with the history buffer. Start at:
>> 
>>   https://code.amlegion.org/hljs_line_numbers/
>> 
>> click on "Single line selection". You end up at:
>> 
>> 
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2
>> 
>> bur rather than 2 items in the history, there are 4 items in my
>> history:
>> 
>>  4
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2
>> 
>>  3
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#
>> 
>>  2
>> https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2
>> 
>>  1  https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md
>> 
>> I have to hit the back button 3 times to move back to the original 
>> page.
>> It looks like URL's 2 and 4 are the same.
>> 
>> Any idea what's happening here?
>> 
>> Have a great day.
>
>Hey Mr. Rouillard,
>
>I bet I know what that is. The code uses window.location.hash to
>establish where the URIs will link to by doing something that is
>partially destructive. Something like:
>
>var uri = window.location;
>var old_hash = window.location.hash;
>window.location.hash = "";
>uri = window.location.href;
>window.location.hash = old_hash;
>
>So now I need to figure out how to reset history to where it should
>be after those operations. I'm welcome to ideas (that I'll review
>later on and push up a fix to the repo and then pull into the
>static files for my repos so that it can be tested.)

Maybe:

  
https://stackoverflow.com/questions/8969878/in-javascript-how-do-i-clear-the-back-history-1

which offers:

  window.location.replace("path/to/target/page");

as way to fix?

Have a great day.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Syntax Highlighting

[John P. Rouillard]

Hello Mr. Martin:

In message ,
"Lester L. Martin II" writes:
>For the JS source that enables line numbering see:
>https://code.amlegion.org/hljs_line_numbers/ (Fossil repo with it)
>
>For a showcase of it doing its job and doing it well since I've recently
>got it up to par with the C source's selection code:
>https://code.amlegion.org/hljs_line_numbers/
>
>The home page gives some links to test selection with line numbering,
>multi-selection, and scroll to top. As time permits I'll also create
>(and link to from the home page) wiki documents describing the setup
>of this for one's own Fossil Repo.

There is something odd happening with the history buffer. Start at:

  https://code.amlegion.org/hljs_line_numbers/

click on "Single line selection". You end up at:

  
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2

bur rather than 2 items in the history, there are 4 items in my
history:

 4  
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2

 3  
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#

 2  
https://code.amlegion.org/hljs_line_numbers/artifact?udc=1=on=b5869c31fbae9ca0#L2

 1  https://code.amlegion.org/hljs_line_numbers/doc/trunk/README.md

I have to hit the back button 3 times to move back to the original page.
It looks like URL's 2 and 4 are the same.

Any idea what's happening here?

Have a great day.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Email notifications content transfer encoding

[John P. Rouillard]

Hi all:

In message <20180626110936.3524bd1f@puter>,
Rafal Bisingier writes:
>Richard asked me to post it on the list for discussion, so here it is:
>The new email notification functionality in fossil use base64 as
>Content-Transfer-Encoding. I personally prefer use of 8bit encoding,
>which have a side-effect of human-readable source of message.

I agree having a regular readable/greppable message is a big win.

Just my $0.02.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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 (dumb idea for pull requests)

[John P. Rouillard]

Hi all:

In message <20180614213758.ga7...@britannica.bec.de>,
Joerg Sonnenberger writes:
>On Thu, Jun 14, 2018 at 04:51:08PM -0400, Ron W wrote:
>> 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.
>
>How do I develop a patch locally and send it to someone for review? The
>pull request model is kind of stupid and works only for a centralized
>system (the irony...), but integration of something like "patchbomb" or
>even just bundles is quite handy for this.

Would some combination of:

  bundle

published via

  uv mechanism

and announced via some url on the upstream fossil (e.g. fossil/pull)
work? The pull requests could be manipulated by the primary developers
similar to how wiki pages can be moderated.

So my thought is:

  fossil bundle export --publish implement_pull_method.bundle --branch pull

which because of the --publish does a:

  fossil uv add implement_pull_method.bundle

which then automatically sends a post to:

  https://www.fossil-scm.org/pull

user: rou...@example.com
url: https://my.fossil.repo/fossil/uv/implement_pull_method
description: {derived from last checkin message maybe}

then doing a get on:

   https://www.fossil-scm.org/pull

(or running fossil pull list ) for somebody logged in and allowed to
see pull requests can run:

  fossil bundle import https://my.fossil.repo/fossil/uv/implement_pull_method

test, publish, purge etc

Verbs like:

  fossil pull list - list name/owner/artfact_id ... for all pull requests
  fossil pull allow - make available for sync (c.f. moderator approval of wiki)
  fossil pull delete artifact_id - delete pull request
  fossil pull describe artifact_id - show description/url and other info

to round out management of the pull request.

Thoughts?

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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.org broken?

[John P. Rouillard]

In message

Re: [fossil-users] Stress testing www4... (was Re: [Bug?] [server] Processes of Fossil popping up unexpectedly

[John P. Rouillard]

Hi Richard:

In message

Re: [fossil-users] [Bug?] [server] Processes of Fossil popping up unexpectedly

[John P. Rouillard]

In message ,
Warren Young writes:
>On Dec 22, 2017, at 10:20 AM, Olivier R.  wrote:
>> 
>> Le 22/12/2017 à 16:10, Warren Young a écrit :
>>> 1. Your repo is public-facing.  Is this a reasonable number of
>>> clients to be connected at any given time to this repo?  It seems
>>> high to me, given the transient nature of most Fossil connections.
>> 
>> Only two devs have the right to modify the online repository.
>> I’d be surprised if there were more than 5 people connected to this
>> repo at the same time.
>
>Your first netstat -na output shows 24 established connections, most
>to distinct remote peer IPs.
>
>Additionally, Fossil connections tend to be short-lived due to the
>nature of Fossil.  [...]
>Therefore, one of two things is happening:
>
>1. You have a high rate of connections to the server, so that at any
>   one time, we can see dozens of them.  Disproving this hypothesis is
>   the purpose of the tshark test.
>
>2. You have connections that stay open for a long time, which suggests:
>
>2a. A connection handle leak.  But if this were common, lots of
>people would have found it before you.
>
>2b. Bad actors on those remote hosts, which is why I bought up the
>possibility of a botnet attack.
>
>If we have a 2b case, then you’d want to find some way to identify
>the connections somehow, so that you can block them.

The only way I managed to reproduce the lsof output that was reported
earlier was to connect to my fossil using netcat and send no
data. Once I sent any data (by hitting a return) fossil reported a 403
(since I sent no http headers).

As I noted earlier I have hiawatha running in front of the fossil
server.  It kills idle connections after I think 60 seconds. So if
there is no traffic, the connection to the back end fossil server will
be killed.

Note that Warren is running nginx as the front end for his fossil
server. I think that has anti-DOS and timeouts on client header/body
and response times that can do something similar.

Does fossil have any idle connection timeout limits?

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] [Bug?] [server] Processes of Fossil popping up unexpectedly

[John P. Rouillard]

Hello all:

In message 

Re: [fossil-users] Automatic update when changing type on timeline?

[John P. Rouillard]

Hi Florian:

In message ,
Florian Balmer writes:
>As the form has no "submit" element, it works differently in different
>web browsers. I've sent a set of patches directly to Richard Hipp to
>make use of the "onkeydown" ("onkeyup" in the initial version) instead
>of the "onchange" handler for text input elements [0], as in some web
>browsers, the "onchange" handler is only fired after the control lost
>focus. The "onchange" handler usually works better for drop-down
>lists, but obviously not in all cases, and I'm not sure what's the
>solution here.

Would adding a submit button labeled "refresh" or "update" be helpful
here? Basic functionality like submitting a form should not depend
on having javascript enabled.

AFAIK the only thing that requires javascript is the timeline graph.
I can use fossil with w3c, lynx or other text based browser if
required (using an anonymous login to get links populated).

The refresh/update button could be hidden by a javascript function so
it isn't displayed if javascript is enabled.

Thoughts?

--
-- rouilj
John Rouillard
==
___
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] Lots of web interface changes

[John P. Rouillard]

Hello Richard:

In message 

Re: [fossil-users] Lots of web interface changes

[John P. Rouillard]

Hello Richard:

In message

Re: [fossil-users] Lots of web interface changes

[John P. Rouillard]

Hello Richard:

I have to say I like the new changes. Especially making the diff
format sticky. It was a real pain to have to keep shifting fron side
to side diff to unidiff format. Now onto the issue.

In message

Re: [fossil-users] How to find out when a line was removed

[John P. Rouillard]

Hi Andy:

In message <a3b39e7c-3cf2-41c6-71a4-1beabbe64...@gmail.com>,
Andy Goth writes:
>On 09/23/17 10:18, John P. Rouillard wrote:
>> I am trying to find out when a line disappeared from a file.
>
>I've long wanted a reverse annotate command.  Rather than show when each 
>line was most recently modified or added, it would show when each line 
>is next modified or removed.
>
>I haven't taken any steps toward implementation because this will be 
>harder to use (certainly harder to implement) than normal annotation. 
>Annotate works as well as it does because each revision has only one 
>primary predecessor, so there's no ambiguity.  Reverse annotate won't 
>magically know the intended "next" version with which to compare.  My 
>best guess at how to handle this is to ask for a target version, and the 
>path from the current version to the target version is the one along 
>which changes are examined.

That sounds workable. Similar to diff between two revisions.

>> I am managing a configuration file and one of the config options lines
>> is no longer there.
[...]
>> Does fossil have something like "perforce annotate -a" or "git log -S"
>> or "hg grep"?
>
>perforce annotate -a sounds interesting.
>
>"All lines, including deleted lines and lines no longer present at the 
>head revision, are included.  Each line includes a starting and ending 
>revision."
>
>https://www.perforce.com/perforce/r14.2/manuals/cmdref/p4_annotate.html
>
>Though I suspect it could result in an extremely messy report should the 
>lines be reorganized multiple times.

It looks like it figures out for each line in the file what line was
at that location in a prior revision. You can specify a range of
revisions as well (not just a -N count). So:

  p4 annotate -a myfile@23,40

would just show the lines between the two revisions (@ is a way of
specifying a revision range for a file). You can also do:

  myfile@>2017/09/03

to get all lines in revisions created since Sept 3 2017 (@> means the
value is a starting point).

Also this brings up an interesting point. None of annotate, blame or
praise support specifying the revision of the file. I would think
being able to annotate a previous version of the file would be useful.

  This is fossil version 2.3 [f7914bfdfa] 2017-07-21 03:19:30 UTC

  Usage: fossil (annotate|blame|praise) ?OPTIONS? FILENAME

  Output the text of a file with markings to show when each line of
  the file was last modified.  The "annotate" command shows line numbers
  and omits the username.  The "blame" and "praise" commands show the user
  who made each check-in and omits the line number.

  Options:
--filevers  Show file version numbers rather than
check-in versions
-l|--logList all versions analyzed
-n|--limit NOnly look backwards in time by N versions
-w|--ignore-all-space   Ignore white space when comparing lines
-Z|--ignore-trailing-space  Ignore whitespace at line end

  See also: info, finfo, timeline

>Not exactly what you're asking, but you can search across many files and 
>many revisions of many files using the fusefs command.  fossil fusefs 
>will make all revisions available in the filesystem so you can use 
>standard programs like grep to examine them.  However...

Ah yes. If I was working from linux that would work.

>> If there is no equivalent in fossil, I am considering running:
>> 
>>fossil finfo _filename_
>
>... You'll still need a list of versions to examine, though the above 
>command will provide.
>
>> to get a list of all the revisions where the file was changed then for
>> each revision:
>> 
>>fossil --checkin _revision_ _filename_ | grep "option name"
>
>Assuming you meant to have a "cat" in there somewhere.  Also I was 
>unaware the -r option could be spelled out as -checkin.

Actually meant diff in there.

 fossil diff --checkin _revision_ _filename_ | grep "option name"

so I can see what lines changed in that revision compared to the
previous revision for the file.

>> Anybody have any answers, thoughts, comments or quips?
>
>I think your cat approach is solid.  Bisect could work too, though it'll 
>make many changes to your checkout directory.

Yeah the problem with bisect is that I have to guess right on the
initial revision and on every good/bad decision. If I end up making a
choice that brackets a time when the file was missing the option,
I can bisect the range forever and never find the deletion.

Thanks for your thoughts.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to find out when a line was removed

[John P. Rouillard]

Hi all:

I am trying to find out when a line dissapeared from a file.

I am managing a configuration file and one of the config options lines
is no longer there.

I initially thought of trying to bisect the file if I can identify
when the system was properly configured. If I guess wrong I could end
up having to run multiple bisects to find the last removal of the
option line.

Does fossil have something like "perforce annotate -a" or "git log -S" or
"hg grep"?

If there is no equivalent in fossil, I am considering running:

  fossil finfo _filename_

to get a list of all the revisions where the file was changed
then for each revision:

  fossil --checkin _revision_ _filename_ | grep "option name"

Anybody have any answers, thoughts, comments or quips?

Have a great day and thanks.
--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] How to deal with obsolete stuff in a repository

[John P. Rouillard]

Hi Ross:

In message ,
Ross Berteig writes:
>On 4/17/2017 6:50 PM, The Tick wrote:
>> I've put a project under fossil. Since it depends on a couple other 
>> libraries, I've also put those into the repository so that I am not 
>> dependent on being able to download those particular versions. Now, 
>> when new versions of those dependent libraries become available, I 
>> want to update my project. I could just add the new versions and 
>> modify my makefile. The problem I see is that over time the fossil 
>> repository is going to get >really< big as it will contain a bunch of 
>> obsolete stuff.
>>
>> Is there a way to handle this? I really want to keep the dependent 
>> libraries in the repository since who knows what might happen to 
>> someone else's open source project in the future, and in addition, it 
>> makes my project "self contained".
>
>This is essentially why the "fossil addremove" command was invented.
>
>When an upgraded library is available, do something like this:
>
>Start with your working directory clean and stable, possibly even 
>updating back to a stable point on trunk.
>
>Unzip the new library on top of the old in your workspace. Try to avoid 
>preserving a version number as part of the folder names in the workspace 
>even if your upstream does that to you. That will just confuse life.

I usually rm -rf the contents of the old lib directory then unpack the
new library into the empty directory.

If you don't remove the original files in the directoru, then
addremove command won't remove any files that have been deleted from
the new version.

The rest of your stuff was spot on.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PROPOSED FEATURE] Fossil commands output sent through a pager

[John P. Rouillard]

Hi all:

In message <787dd2f8-edf8-4caf-5d8c-b63cac39a...@marples.name>,
Roy Marples writes:
>On 26/03/2017 22:19, Joerg Sonnenberger wrote:
>> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
>>> For someone with a different background, there is *nothing* nice about
>>> fossil dumping thousands of lines to the terminal. In fact, I think it
>>> scares off newbies who only used git before.
>>
>> I quite disagree. Terminal output is C friendly. Pager output tends to
>> disappear with the pager. That's a real world UX issue I have with the
>> git default settings.
>
>Pager output disappearing with the pager (I assume when asking the pager 
>to exit) is an issue with the pager.
>
>As Fossil is a single binary to do everything approach, I'm sure that a 
>Fossil pager would not suffer this defect.

IIRC the patch is using an external pager right? There is not a pager
being build into fossil.

>Yes, terminals have scroll bars and can page up, but that's the wrong 
>approach as well.
>
>When viewing a diff I want to start at the top and scroll down, not 
>start at the bottom and scroll up, hence a pager makes perfect sense.

As long as it can be turned off so wrappers around fossil (fsl, emacs
vc mode, other programs using the cli as a fossil interface) are not
broken if terminal detection fails, I'm meh about it.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.


On 26/03/2017 22:19, Joerg Sonnenberger wrote:
> On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
>> For someone with a different background, there is *nothing* nice about
>> fossil dumping thousands of lines to the terminal. In fact, I think it
>> scares off newbies who only used git before.
>
> I quite disagree. Terminal output is C friendly. Pager output tends to
> disappear with the pager. That's a real world UX issue I have with the
> git default settings.

Pager output disappearing with the pager (I assume when asking the pager 
to exit) is an issue with the pager.

As Fossil is a single binary to do everything approach, I'm sure that a 
Fossil pager would not suffer this defect.

Yes, terminals have scroll bars and can page up, but that's the wrong 
approach as well.

When viewing a diff I want to start at the top and scroll down, not 
start at the bottom and scroll up, hence a pager makes perfect sense.

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

[fossil-users] Using child projects/repositories effectively

[John P. Rouillard]

Hi Everybody:

I am currently using a child project/repository as described
in:

  http://www.fossil-scm.org/index.html/doc/trunk/www/childprojects.wiki

In this child repo I have files that should not be pushed to
the main repo. So my locally added files, configuration file
changes etc. all happily live in the child repo.

However when I do a:

   fossil pull --from-parent-project

I usually end up forking the trunk which requires a merge to
get things back in order. Is that how this is supposed to
work?  I was envisioning the parent project would be
something more like a branch that I could merge/integrate
from at will. Should I change the child project's
main-branch from "trunk" to "mainline" to reserve the trunk
tag for the parent project.

If I should rename to mainline, I have a bunch of commits in
the repo. So how do I move all the child's trunk commits to
the new mainline branch and establish the mainline branch
going forward?

Also I would like to use fossil as the method people use to
manage the software at their own sites, so understanding how
to use the child project feature effectively is a big win.

Thanks for any ideas on how to use this feature successfully.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to use login-group

[John P. Rouillard]

Hi all:

I am trying to set up a series of fossil repos for a volunteer coding
project.

I have a script that I can use to set up the repos, and the plan is to
have the developers self register at the event.

I would like to have the sign up once and get access to multiple
repos.

It seems that login group shoud be able to do this, but I haven't
found any documentation on how it should work.

Reading through emails, it looks like I need to:

   Choose one repo to be the master

   Enter the server side path to the repo as:
   Repository filename in group to join

  Then provide admin credentials on the master repo (I assume
so it can modify the login group config on the master repo).

  Then choose a name for the group.

Once I have done that I need to have the developers register on the
master repo.

To allow them to log into the web or clone/push/pull I need to:

fossil config pull -R museum/repo.fossil user museum/master.repo

to copy all the users from the master to each repo.

Is this correct?

Thanks.

--

-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] --nosync option for merge, update, checkout when disconnected

[John P. Rouillard]

In message 

Re: [fossil-users] Weird cross-contamination between two fossil repositories (and not even talking to server!)

[John P. Rouillard]

Hi Ross:

In message <38334f96-17cf-e32a-e758-2d15ce5fd...@cheshireeng.com>,
Ross Berteig writes:
>On 5/27/2016 3:58 PM, John P. Rouillard wrote:
>> Hi Richard:
>>
>> Richard Hipp writes:
>>> Just to be clear, I consider anything involving shunning to be
>>> out-of-the-ordinary.
>>
>> Perfectly reasonable.
>>
>> 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
>
>IMHO, that is capability is outside the core mission of
>fossil. One of the great selling points of fossil to new users
>is the low ceremony of fossil. One executable. A repo is a
>single file, that can even safely reside in the same folder as
>your checkout. And very little policy is enforced by fossil
>directly.

I agree that the low ceremony feature of fossil is excellent. I
am *not* suggesting that the th1/tcl code to enforce policy be
supplied by default. However I was expecting that the fossil
hooks would operate similar to hooks/triggers (and similar
mechanisms) in svn, cvs, git, perforce 

>That said, there is a hook mechanism that can be used to check
>preconditions before executing a command. It might require some
>cleverness to use it for this purpose, however.

Yup, cleverness is what I am looking for. I was expecting that I
could do the following from a hook:

  1) Get the current manifest for the checkin (passed to the hook
 script)
  2) Using the manifest, find a list of new artifacts added
 in this commit transaction (e.g from th1: 
 set manifest [fossil artifact ]
 )
  3) Analyze the manifest for filenames and artifact id's and be
 able to "fossil artifact" these new artifacts to analyze the
 contents
  4) verify the checkin comment contents (by looking for the C
 card in the manifest): E.G. does the checkin comment have a
 reference to an open ticket.
  5) Identify the user who made the commit (U card in manifest IIRC)
  6) Abort the commit from the hook causing the artifacts be
 removed and the user to be notified with a message from the
 hook script.

However from what you say below it looks like the hook is at the
wrong level for me to do any of this.

>Hooks exist if fossil is compiled with the option, are written
>in TH1, can configured to make Tcl available to TH1, and are not
>extensively documented.

So I have noted 8-). Even some light code groveling failed to
enlighten me.

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

>Hence the need for cleverness since you would want to learn what
>files are going to be committed.
>
>This hook has to run at the client, and before the commit is
>performed.  So that won't prevent a user from bypassing it, or a
>misconfigured repository from failing to call it, or if depending
>on Tcl, I'm sure there are more failure modes since Tcl is
>(usually, depending on configuration of fossil) loaded from the
>system at run time.

Agreed. I would expect that only the central repo would be
guaranteed to run the hook, but that doesn't stop repo clones
from also having the hooks so that they don't commit things that
would be rejected upstream.

Obviously I would also need access in the hook to see if the
branch is private or not so I could bypass the hook on a private
branch (that won't be pushed upstream).

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?

>>   If you really wanted to commit a file that matched that
>> pattern, you added a string like: BYPASSPASSWORD to the commit
>> message and the check would be bypassed.
>
>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.

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

[fossil-users] --nosync option for merge, update, checkout when disconnected

[John P. Rouillard]

Hello Everybody:

I a usually use a central repo with autosync enabled. However
sometimes I want to work from a coffee shop or somewhere else where my
central repo is unavailable.

Similar to what was discussed recently, I need to merge or update my
working area for testing, reporting or just normal work.

Since I am disconnected from my central repo, the pull requests for
merge and update fail and prevent me from using those commands until I
turn off autosync.

While merge/update fail, checkin asks if I want to continue even though the
sync will fail:

  fossil ci --branch test -m "testing checkin"
  Autosync:  http://user@host/fossil/roundup_2
  getaddrinfo() fails: Name or service not known
  Pull done, sent: 0  received: 0  ip:
  Autosync failed.
  continue in spite of sync failure (y/N)?

If I say yes, the checkin to my local repo works.

Does it make sense to follow the checkin model for merge/up?

Alternatively is there some argument I can use for the "pulling"
commands. E.G. a hypothetical --nosync option to turn:

  $ fossil up jquery_1.12.4_upgrade
  Autosync:  http://user@host/fossil/roundup_2
  getaddrinfo() fails: Name or service not known
  Pull done, sent: 0  received: 0  ip:
  Autosync failed.
  Cannot proceed with update

into:

  $ fossil up --nosync jquery_1.12.4_upgrade
  REMOVE fo
  --
  updated-to:   
  changes:  1 file modified.
  "fossil undo" is available to undo changes to the working checkout.

While I can use 'fossil settings autosync 0' there is a good chance I
will forget to turn it on and not notice the next time I up/merge.

Suggestions?

AtDhVaAnNkCsE

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.


___
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] Branch and tag metadata

[John P. Rouillard]

Hi Andy:

In message <3d27b874-c4db-f4e9-956f-7bbfd651b...@gmail.com>,
Andy Goth writes:
>On 5/21/2016 4:53 PM, John P. Rouillard wrote:
>> In message <C7F6D0C7DBB14445BAF6F56CB651D6A8@Yulichka>,
>> "Tony Papadimitriou" writes:
>>> I've had the same wish for a long long time.  I would
>>> like the FOSSIL BRANCH list to show except for the
>>> branch name some kind of description. [...]
>>>
>>> So, I think the simplest way to add this functionality
>>> *without* causing backward compatibilities or file
>>> format changes is to display the first commit comment
>>> for that particular branch as a description in the
>>> BRANCH list command.  [...]
>>
>> Since tags are really just properties, what about a
>> convention for adding a branch-description property along
>> side the branch=BRANCHNAME property.
>> 
>> Thus to add a description, you can run:
>> 
>>   fossil add tag branch-description CHECKIN \
>>   "This branch implements the flooze feature, \
>>[...] see BRANCH:flooble wiki [...]"
>> 
>> where checkin is the revision with the branch= property set.
>>
>That's a good thought.  The backward-incompatible part of
>my initial suggestion was due to not knowing where else to
>store the branch or tag description.  I also suggested
>using the wiki but with drawbacks.  The location you
>suggest makes sense, plus would leverage the existing
>artifact amendment infrastructure.
>
>It's also related to Tony's suggestion in that you both
>propose storing the description in the first check-in of
>the branch, but you go a step farther by using a property
>rather than recycling the comment.
>
>How about tags?  Put the description in the check-in
>manifest of the first usage of the tag, I suppose.

That's my thought. IIUC a property with no value is the
definition of a tag. Making the value of a tag be its
description would stop it from being interpreted as a tag.

So you would need to use a separate property to hold the
description.  The description for the tag "tagname" would be
held in the "tagname-description" property for example.

Richard, is there any documentation on the meanings of the
various properties/tags? This is what I think is true:

  prop name value comment
  anything  null  is a tag

  sym-anything  null  is a propagating tag?? 
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki
indicates that sym is a symbol but without
saying what a symbol is. Also propagating/non-propagating
and removal/closing  is controlled by the value of the
field in the T record. One of: +, -, * 

  branchbranch-name   define a branch with name branch-name
  closednone  indicates the branch is closed
  bgcolor   color assigns color to the displayed branch
  cancels a tag (what does this??)

  user  a userall three of these amend the
  comment   text  checkin manifest values 
  date  a date

>What if a tag is used multiple times?  I'm guessing use the
>newest which contains the tag-description property.

Use the tag-description on the revision identified with the
tag. E.G.

  fossil co myrelease

may have two candidates:

  "myrelease", revision deadbeef done a month ago with a myrelease-description
  "myrelease", revision beefdead done a day ago with no myrelease-description

if you look at details for the myrelease on beefdead, you
will see no description. Similarly you will see a
description if you look at the "myrelease" associated with
deadbeef.

It would be a mistake to associate the deadbeef description
with the myrelease tag on beefdead.

>Same goes for branches.  Though hopefully there won't be
>more than one instance per tag or branch.

As long as the revision where the branch is created or tag
is assigned is the same revision where the description is
attached, I don't think there is an issue.

>> As an enhancement to the branch command
>> 
>>fossil branch new BRANCH-NAME BASIS ?OPTIONS?
>> 
>> add an option "--description" that sets the value for the
>> branch-description value at branch time.
>
>Does anyone use the "branch new" command?  It's a relic
>from the old way of doing branches.  I'm not opposed to
>this suggestion, just asking.

I am working on a gitflow technique and this is the command
I am using to create the feature branch and have the user
move to that branch so they can't accidently check back into
the development branch line. Hence my reason for raising it.

>Though I would go a step further and add the -descri

Re: [fossil-users] Branch and tag metadata

[John P. Rouillard]

Hi all:

In message ,
"Tony Papadimitriou" writes:
>I've had the same wish for a long long time.  I would like the FOSSIL BRANCH 
>list to show except for the branch name some kind of description.
>Like you mentioned, making the branch name itself long enough would be one 
>way to tackle this but it is counter-productive as you would need to type 
>the whole thing each time you need to access that branch.
>
>So, I think the simplest way to add this functionality *without* causing 
>backward compatibilities or file format changes is to display the first 
>commit comment for that particular branch as a description in the BRANCH 
>list command.
>
>Although it may not always be the most accurate description for branches 
>already created, I think in most cases the first branch commit comment 
>represents a pretty good description about what the branch is about, or why 
>it had to be created.

Since tags are really just properties, what about a convention for
adding a branch-description property along sinde the branch=BRANCHNAME
property.

Thus to add a description, you can run:

  fossil add tag branch-description CHECKIN "This branch implements the flooze 
feature, see the BRANCH:flooble wiki page for details."

where checkin is the revision with the branch= property set.

As an enhancement to the branch command

   fossil branch new BRANCH-NAME BASIS ?OPTIONS?

add an option "--description" that sets the value for the
branch-description value at branch time.

According to

   http://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki

this should work to associate metadata with a checkin artifact.

Comments?

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Repairing trunk/timeline after a shun

[John P. Rouillard]

Hi Andy:

In message <0dc19ff1-f9f1-67af-7119-62bf62462...@gmail.com>,
Andy Goth writes:
>On 5/14/2016 4:59 PM, John P. Rouillard wrote:
>> fossil init shun.fossil
>> mkdir shun
>> cd shun
>> fossil open ../shun.fossil
>> echo 2 > 2
>> fossil addremove
>> fossil ci -m "initial commit"
>> echo 2a > 2
>> fossil ci -m "second commit"
>> echo 2b > 2
>> fossil ci -m "third commit"
>> echo 2shun > 2
>> fossil ci -m "fourth shunable commit"
>> echo 2c > 2
>> fossil ci -m "fifth commit"
>> echo 2d > 2
>> fossil ci -m "sixth commit"
>> 
>> then shun the forth commit. You can rebuild the repo if you like it
>> makes no difference.
>
>Go look in /bloblist and you'll find that 2shun is still there, even
>after a rebuild.  You've not actually succeeded in removing the
>dangerous data from your repository.  It's still there despite not being
>connected to anything.

Eep. If I shun a commit artifact, should all the artifacts for that
commit also be shunned? I think the answer is no since shunning should
be an advanced operation.  Mistakenly shunning a commit (rather than a
file) could delete other files that shouldn't be shunned.

Would it be worth mentioning that shunning a commit does not shun the
artifacts checked in during that commit? I kind of expected them to be
removed since they were added as a single transaction. (I understand
why this expectation is wrong but...)

Is there any way to identify and remove these unconnected artifacts?
Would rebuild --vacuum clean them out? I suspect deconstruct would not
dump those disconnected artifacts. So would

   fossil deconstruct
   fossil reconstruct 

make a new repo without the disconnected data.

Is there any way using "fossil sqlite3" to dump the data so I can grep
for the banned data to make sure it's been erased?

As I figured:

   select uuid,content from blob;

doesn't do it.  Is there an expand(content) or something that I
could use?

In any case, thank you for showing the error of my ways. I have to
shun the files with the privileged info and not the commit (unless the
privileged info is in the commit message). Well back to trying to
sanitize things.

Have a great week.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Conversation with a CM guy

[John P. Rouillard]

Hi Eric:

In message
 ,
Eric Rubin-Smith writes:
>>  employability.
>
>
>It takes less than a day to pick up git if you're used to fossil.

I agree with you to an extent. There are some sharp edges in git that
people seem to cut themselves on. If you are hiring people you don't
want to have to train to avoid/be able to bandage themselves then it's
not a 1 day deal.

>So I don't really think it makes a huge difference as to future employability
>unless the hiring manager is looking for the wrong things.

No argument here.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Conversation with a CM guy

[John P. Rouillard]

In message <4d41a0c9-37e8-1a0b-2120-99953b016...@gmail.com>,
Andy Goth writes:
>On 16 May 2016 15:34:02, John P. Rouillard <rou...@cs.umb.edu> wrote:
>> I would like to see your document when you think it's ready to share.
>
>I can't, it's not mine to share.  And even if I were willing to spill
>proprietary information, the document is heavily tailored to the project
>I'm working on, full of host names and engineer names and site names and
>version names and internal process references and all that.

Fair enough. A lot of the doc I write professionally is releasable
and supported as part of the open source effort at the companies I
have worked at.

However that's not the type of doc you are writing 8-).

>I might someday write a more generic document on my own time.  I'll
>partially outline it below.
>
>> In my case I have perforce rather than clearcase.
>
>I've integrated Fossil with Perforce in pretty much the same way.  The
>secret is the "-keep" option to open.  Create the checkout directory
>using the other SCM tool, then use "-keep" to ask Fossil to manage it
>without overwriting it.  Then use "f checkout -force -keep" to go from
>version to version while still not overwriting anything.
>
>[ very useful and interesting info removed ]
>
>Oh right, renames.  I guess you're going to want to track those too.  I
>haven't thought about them much because the way we're using ClearCase
>completely prevents rename tracking.

Ok. Yeah renaming would be useful. I don't know how it's handled in
perforce, but I assume some sed magic on some query option can provide
the commands to mirror the renames across repos.

>And now we're talking about having Fossil track copies too.  Once again,
>I don't know how to apply that to the process I'm outlining.

Fair enough.

>I'm not sure this is what you wanted to read about.  Maybe you wanted
>workflow within Fossil, like how to manage branches.

That would also be useful, but we are using perforce streams so the
same promotion/restricted merge mechanism can be enabled using fsl I
think.

>Or maybe you
>wanted to know how to synchronize despite lacking end-to-end network
>connectivity.

No, not so interested in that 8-).

>>> Of course, none of that matters since he started by prioritizing
>>> marketing.
>> 
>> Well nobody ever got fired for choosing git (yet).
>
>One person being fired for a poor decision is preferable to the whole
>shop having to bear a long-term burden that eats their competitive
>advantage and their morale, possibly leading to turnover or layoffs.

I agree, but the same can be said about using Microsoft or IBM 8-).

>> I wonder if a git-fossil (like git-svn) might be helpful for people?
>
>I don't know what git-svn is.

It's a git command that treats an svn as an upstream repo. There is
also git-p4 IIRC.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Repairing trunk/timeline after a shun

[John P. Rouillard]

Hello Richard:

In message

Re: [fossil-users] Repairing trunk/timeline after a shun

[John P. Rouillard]

Hi Andy:

In message <5538e894-bdfa-ad31-be79-26383e8ea...@gmail.com>,
Andy Goth writes:
>On 5/14/2016 4:59 PM, John P. Rouillard wrote:
>> I had to recently shun some artifacts from a fossil repo (due
>> to embedded security credentials). Now when I look at the
>> fossil timeline that spans that shunning I no longer have a
>> single connected trunk.
>> 
>> So is there some way to reintegrate the trunk across the shun?
>> Is this split timeline just a side-effect of shunning?
>
>Quite simply, you have a hole in your repository.

As I suspected, I removed a link in the middle of the timeline chain.

>To fix, you're going to have to go back to the version prior to
>the shun and redo every check-in since that point.  Use the
>-date-override and -user-override commit options to make your
>commits resemble the originals.  As far as I know, no one has
>scripted this kind of reconstruction yet, so you're on your own.

Fair enough. If I come up with a script I'll post it.

>A consequence is every manifest artifact ID since the shun will
>change.  If you have any references to the old artifact IDs,
>e.g. in tickets or subsequent check-in comments, you may want to
>update them as well.

Fortunately there are no artifact references in
tickets/wiki/comments. But if there was, would some SQL magic
be needed to find/change these references?

>In retrospect, you would have been better off not shunning the entire
>check-in but rather only the file containing the security credentials.

That makes sense. What is the easiest way to get the artifact
ID for the file?

   fossil timeline -v

gives you the file name, but not the artifact number.  I would
have expected the artifact number as part of the listing:

  [305556e6e5] fourth shunable commit (user: rouilj, tags: trunk) 
 EDITED 2 [artifact_ID]

Then I could "fossil what artifact_ID" to get the full sha1 sum.

It looks like I need to "fossil finfo 2" to get all artifacts for
all versions of the file named 2. Then I need to search the finfo
for the checkin artifact number to figure out which artifact I
need to wipe.

Is there an easier way?

[[ As a side note "fossil json timeline checkin -v" does have the
uuid's for the files in it. I am not sure parsing json is easier
even with tools like jq, but... ]]

The timeline view in the web interface also doesn't supply
artifact id's for the files created during a checkin. I am
thinking of something like:

  [305556e6e5] fourth shunable commit (user: rouilj, tags: trunk) 
 EDITED 2 [artifact ID here] [diff]

If I had seen the artifact ID's, I would most likely not have
shunned he checkin and shunned the files instead 8-(. I would
still have to click on the file names to get the whole sha1
artifact number for shunning but it would have made me think twice.

Might it make sense to add a verification step if any of the
shunned artifacts are a commit record since this misstep is a
pain to recover from?

>Then do a check-in that corrects or removes the file.

There was a following checkin that fixed the issue before I
shunned the earlier versions with the credentials.

>It is legal, though certainly not ideal, to have one or more
>manifests refer to artifacts not present in the repository.
>Fossil's handling of this situation isn't quite as graceful as
>it could be, but I don't think it's going to outright die.

Doesn't seem to have died.

In my test case repo, accessing the artifact by UUID returns an
unknown page notice in the web interface. Accessing the artifact
with "fossil artifact" again just reports not found.

Looking at the commit the diff (and mlink) table report that the
shunned artifact is deleted. "timeline -v" shows:

  21:15:19 [305556e6e5] fourth shunable commit (user: rouilj tags: trunk)
   DELETED 2

and "fossil finfo 2"  doesn't show a fourth commit at all.

Looking at the timeline (with file listing) in the web ui, I do
see a (deleted) notation on the shunned file and a subsequent
(new) notation on the following revision. So a little misleading
but amending the checkin comment can explain it away, so not a
real issue.

Looks like the missing artifact is being handled reasonably.

Also it looks like you must support manifests with missing
artifacts otherwise shunning can't work at all. As it always
leaves references to missing artifacts (the commit record) if
nowhere else.

>> Would doing a fossil git-export | fossil git-import "fix" things?
>No, nor would a rebuild, nor would a deconstruct followed by a
>reconstruct.

Right because I deleted the commit artifact needed to stitch
the commits before and after the shunned commit together.

Thanks for your feedback.
--
-- rouilj
John Rouillard
===
My employers do

[fossil-users] Repairing trunk/timeline after a shun

[John P. Rouillard]

Hi Everybody:

I had to recently shun some artifacts from a fossil repo (due to
embedded security credentials). Now when I look at the fossil timeline
that spans that shunning I no longer have a single connected trunk.

To reproduce use:

fossil init shun.fossil
mkdir shun
cd shun
fossil open ../shun.fossil
echo 2 > 2
fossil addremove
fossil ci -m "initial commit"
echo 2a > 2
fossil ci -m "second commit"
echo 2b > 2
fossil ci -m "third commit"
echo 2shun > 2
fossil ci -m "fourth shunable commit"
echo 2c > 2
fossil ci -m "fifth commit"
echo 2d > 2
fossil ci -m "sixth commit"

then shun the forth commit. You can rebuild the repo if you like it
makes no difference.

fossil ui's timeline shows the initial checkin on the leftmost rail
with nodes for the initial, first, second, third commits. The third
commit is marked as a leaf. Then next to the left rail is a second
rail with no nodes until the fifth and sixth commits. The sixth commit
was marked as leaf before the shunning but not after the shunning.

So the fourth commit (shunned) is missing, but the timeline is
disjoint at the point of the shunning. Also the end of the trunk
branch is located at the fourth commit (which is marked as a leaf).

If I try to: fossil up trunk
in the shun subdirectory (with the 6th commit) I get:

  fossil: ../fossil/src/bag.c:146: bag_find: Assertion `e>0' failed.
  Aborted

which seems wrong.

I tried to reconnect the timelines by adding a new propagating branch
tag called trunk to commit 5. This did make commit 6 into a leaf, but
the timeline is still split. However I do get the following when
running 'fossil update trunk'

checkout: 7d1873d50037c56a9d610ef557590f33cc1ccbe1 2016-05-14 21:43:24 UTC
tags: trunk
comment:  sixth commit (user: rouilj)
changes:  None. Already up-to-date
WARNING: multiple open leaf check-ins on trunk:
  (1) 2016-05-14 21:43:24 [7d1873d500] (current)
  (2) 2016-05-14 21:43:19 [43059e2375]

So is there some way to reintegrate the trunk across the shun? Is this
split timeline just a side-effect of shunning? Would doing a
fossil git-export | fossil git-import
"fix" things?

(As a side note, is there a shun cli command? fossil help/help -all
doesn't seem to show one.)

Thanks for any insight.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Some more default settings for a UI user

[John P. Rouillard]

In message ,
=?iso-8859-1?Q?Marko_K=E4ning?= writes:
>
>On 24 Apr 2016, at 01:07 , Stephan Beal  wrote:
>
>> You need to edit the links in the menus to add parameters for the
>> settings you want. e.g. max is set using n=123.
>> 
>

>I know that I can do that, in principle, BUT next time I click the
>/timeline menu link I am back to the default settings for all three
>parameters, i.e. n=50 in this case.

You're missing what he is saying. He is saying change the Timeline
(/timeline) link in the menu.

When logged in as an admin, go to:

   Admin/Skins

You will see text that says:

 A "skin" is a combination of CSS, Header, Footer, and Details 

Choose Header.

The html/th1 mix that shows up in the textbox is the top section of
the pages.

Search for Timeline and you should see:

  menulink /timeline Timeline

Change
   /timeline
to
  '/timeline?n=100'

and click Apply changes. Now the default value when clicking Timeline
menu link is to show 100 changes.

I don't think there is an option to allow logged in users to set those
sorts of things on a per user basis. AFAIK there is no user data
stored other than a password. So you would need to figure out how to
create a user table to store user preferences. There are no custom
forms for users (i.e. a user equivalent of the admin/tickets
mechanism), you wouldn't be able to allow the user to edit things
without some changes to the fossil core code.

However once you had that info in the database, IIRC you can use th1 to
find out who the current user is. Then you can make sql calls into the
database. So I think in theory you could change/create a user schema
that holds personalized settings and use th1 to customize the menu
item.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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] Version 1.33 - /reports failing

[John P. Rouillard]

Jooks like this never made it to the list when it was sent on May 28th.

In message 20150528165652.GA2489@k8,
Svyatoslav Mishyn writes:

(Wed, 27 May 14:03) Warren Young:
 On May 23, 2015, at 1:25 PM, Svyatoslav Mishyn
 j...@openmailbox.org wrote:
  
  /tmp: wget -S http://localhost:8080/reports
  --2015-05-23 21:42:12--  http://localhost:8080/reports
  Resolving localhost (localhost)... 127.0.0.1
  Connecting to localhost (localhost)|127.0.0.1|:8080... connected.
  HTTP request sent, awaiting response... No data received.
  Retrying.
 
 That works here.

It doesn't for me.

Finally, I found why ;)
It is just  CFLAGS=' -O2'.

I also have the /reports url crashing with no output. Recompiling
after changing the top level Makefile to remove -O2 from the TCCFLAGS
makes /reports work. The side effect is to turn off optimization which
isn't great.

This is on Linux mint 17.1 with

   gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 
   GNU ld (GNU Binutils for Ubuntu) 2.24

Is there a way to run fossil under gdb in single shot mode where it
will listen at a port but not fork a child to handle the request. That
would make debugging this a lot easier rather than trying to chase
across a forking process.

  echo 'GET /fossil/reports HTTP/1.1' | fossil  http ~/fossil_repos/ | less

is the right idea, but

  echo 'GET /fossil/reports HTTP/1.1' | gdb fossil

sends the get to gdb and not to fossil so

Also is there any logging in fossil thatt I can enable to help debug
where things are actually going wrong?

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Patch to make server --repolist --notfound ... work more correctly

[John P. Rouillard]

Hi all:

(I didn't see this show up in the list archives, so I am resending this.
Sorry if it's a duplicate.)

If I run:

  fossil server -P 8081 -files '*.html' --repolist \
   --notfound index.html ~/fossil_repos/

and I try to access http://host:8081/ I get a redirect to index.html
rather than getting a list of repositories. The following patch checks
to see if the url is / before trying to redirect to the url specified
by notfound and is just an inversion of the two existing checks.

The attached patch was tested with:

server: fossil server -P 8081 -files '*.html' --repolist \
--notfound index.html ~/fossil_repos/

urls: http://host:8081/ returns with repolist
  http://host:8081/foo (non-existent) redirects to index.html
 
server: fossil server -P 8081 -files '*.html' \
  --notfound index.html ~/fossil_repos/

url: http://host:8081/ redirects to index.html

Given how trivial this patch is, I release this patch into the public
domain to be used as needed.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
Index: src/main.c
==
--- src/main.c
+++ src/main.c
@@ -1563,16 +1563,16 @@
 zRepo[j] = '.';
   }
 
   if( szFile1024 ){
 set_base_url(0);
-if( zNotFound ){
-  cgi_redirect(zNotFound);
-}else if( strcmp(zPathInfo,/)==0
+  if( strcmp(zPathInfo,/)==0
allowRepoList
repo_list_page() ){
   /* Will return a list of repositories */
+}else if( zNotFound ){
+  cgi_redirect(zNotFound);
 }else{
 #ifdef FOSSIL_ENABLE_JSON
   if(g.json.isJsonMode){
 json_err(FSL_JSON_E_RESOURCE_NOT_FOUND,NULL,1);
 return;

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

[fossil-users] How to import tickets into fossil

[John P. Rouillard]

Hello:

I am converting from a bulletin board system that I was using as a
ticketing system (elog).

Does fossil have a mechanism where I can create and update the tickets
from the command line? Even some form of input format would be useful.

I guess the same question is once I have tickets in fossil, is there
an export mechanism of some sort in case I want to move to another
system?

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] How to serve up static files using --files

[John P. Rouillard]

Hello:

I am having an issue trying to serve up static files like index.html
with fosssil in server mode. My command line is:

   fossil server --files *.txt,*.html /home/rouilj/.fossil_repos

there is a file:

  /home/rouilj/.fossil_repos/index.html

but when I connect to:

  http://server:8081/index.html

all I get is a 404 error and a page with Not Found inside h1
tags.  http://server:8081/reponame works fine.

I have searched high and low trying to get some logging or debugging
output (including building with configure ...  --fossil-debug and
running the server with --debug). However I have had no luck
debugging the code base to figure out what I am doing wrong.

Can somebody toss a clue by 4 my way?

Thanks.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
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 tickets into fossil

[John P. Rouillard]

In message 20141205201648.27318.qm...@angmar.bradfordfamily.org,
Andy Bradford writes:
Thus said John P. Rouillard on Fri, 05 Dec 2014 21:38:35 -0500:

 Does fossil have a mechanism where I can create and update the tickets
 from the command line? Even some form of input format would be useful.

http://www.fossil-scm.org/index.html/help?cmd=ticket

I know about that, but I am not sure how to use it. I can create the
ticket:

fossil ticket add title This is ticket title private_contact 
someb...@emmail.com comment encode the body of the ticket\n\nusing the 
quioting\tmechanism\nhere we go\n tkt_ctime 2011-10-20 12:34:23 type 
text/plain status open -q

and somehow get a UUID back (lets say 12345), but how do I update
the ticket with a new comment from another user?

Neither set or change seems right as it will update the fields of the
ticket I just added.

Ahh, is an update for the ticket just an append to the comment with
a header?

So after I add a ticket, I can create a new comment on it with:

fossil ticket change 12345. +comment 
-\nuser added on 2014-03-20 
12:22:12\n\nThis is an update to the same ticket\nwith two lines of text -q

Or should it be:

fossil ticket change 12345. tkt_mtime 2014-03-20 12:22:12 login user 
username A user mimetype text/plain icomment This is an update to the same 
ticket\nwith two lines of text -q

I am not finding anything that indicates which I should do.

Also do the fossil ticket change and fossil ticket set command do
the same thing (so they are interchangable)?

I suspect (as in my second fossil ticket change example), set
changes the ticket table and change changes the ticketchng table.

Also is there a way to do a file attach from the command line?

I don't see any ticket attach command.

I do see an /attachadd page,but I am not quite sure how to automate
using that to add my attachments on tickets.

 I guess the same  question is once I have tickets  in fossil, is there
 an export  mechanism of some  sort in case I  want to move  to another
 system?

I  don't think  there is  any specific  mechanism for  exporting tickets
(except perhaps in the above mentioned command line options).

So I would need to parse out the comment or dump the db to generate
something for another ticketing system. Ok, I can handle that I guess.

I suppose there's always the SQL mechanism if one is desperate:

http://www.fossil-scm.org/index.html/help?cmd=sqlite3

Given the  warning there, any tampering  with the DB should  probably be
done on a temporary clone which is discarded when done.

Yeah, that seems possible for dumping the data, but seems dangerous
for importing the tickets.

Thanks for your thoughts.

--
-- rouilj
John Rouillard
===
My employers don't acknowledge my existence much less my opinions.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users