[fossil-users] Fw: How about renaming a fork to "fork-*"? (Was: Two trunks?)

[Steve Stefanovich]

Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list, 
but just the quote without my reply).

‎What I meant to say here is that the whole confusion about forks is due to the 
fact that they branch out under the same tag.  I can't see the case where is 
this ever desirable.

How about if the fork happens, simply change the tag automatically to 
'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or just 
tag it as 'fork', on commit?

That would be very visible, either prompting people to merge back and close the 
fork, or to rename the 'fork-' tag to meaningful branch name.

From: Ron W
Sent: Saturday, 18 April 2015 03:00
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two 
trunks?)


Hello,

Did you mean for your reply to go only to me? You did not CC the Fossil list.

On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich 
mailto:s...@stef.rs>> wrote:

From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
mailto:amb-fos...@bradfords.org>> wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly 
state any intent beyond the merge itself, even a full merge. After all, a merge 
doesn't automatically close a named branch. So why would a merge automatically 
make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an 
intent to remove "fork" status.


___
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 about renaming a fork to "fork-*"? (Was: Two trunks?)

[Steve Stefanovich]

Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list, 
but just the quote without my reply).

‎What I meant to say here is that the whole confusion about forks is due to the 
fact that they branch out under the same tag.  I can't see the case where is 
this ever desirable.

How about if the fork happens, simply change the tag automatically to 
'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or just 
tag it as 'fork', on commit?

That would be very visible, either prompting people to merge back and close the 
fork, or to rename the 'fork-' tag to meaningful branch name.

From: Ron W
Sent: Saturday, 18 April 2015 03:00
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to "fork-*"? (Was: Two 
trunks?)


Hello,

Did you mean for your reply to go only to me? You did not CC the Fossil list.

On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich 
mailto:s...@stef.rs>> wrote:

From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
mailto:amb-fos...@bradfords.org>> wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly 
state any intent beyond the merge itself, even a full merge. After all, a merge 
doesn't automatically close a named branch. So why would a merge automatically 
make a "fork" not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an 
intent to remove "fork" status.


___
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] Can fossil be used to apply a diff patch?

[Warren Young]

On Apr 17, 2015, at 4:41 PM, to...@acm.org wrote:
> 
> I was hoping fossil would be able to eat its own … diff

patch(1) is the tool Larry Wall was famous for writing before he created Perl.  
It is one of those tools complex enough that there are no clones.

There is a fork around licensing issues.  The FSF took over maintenance of 
patch(1) around the turn of the millennium and GPL’d it, so the BSDs typically 
ship a version forked off from the last pre-GPL’d version.

So, if Fossil were to get built-in patch(1) functionality, it would mean 
integrating something like this:

  https://svnweb.freebsd.org/base/head/usr.bin/patch/

That’s several thousand lines of tricky C code, all to replace a tool that is 
already on almost all non-Windows development boxes.  A bit of tail wagging the 
dog, I think.

Windows ships without a whole lot of tools.  I suggest you treat this problem 
the same as you treat the compilers it doesn’t include, the decent text editors 
it doesn’t include, the decent web browser it doesn’t include… ;)
___
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] Can fossil be used to apply a diff patch?

[David Macek]

On 18. 4. 2015 0:41, to...@acm.org wrote:
> Thank you but I wanted this for a Win7 machine, not Linux.
> (I have MINGW installed but its 'patch' is a bit unstable as it crashes most 
> of the time besides not being available on most Win7 machines.)
> 
> Thanks, anyway.  I guess I need to look for a reliable Win7-based stand-alone 
> patch utility.  Until then, manual editing! :)

What do you mean by stand-alone? I'm inclined to suggest Cygwin/MSYS2 patch, 
but I could also look at building/fixing a recent patch with the mingw-w64 
toolchain if your patch is old/broken.

-- 
David Macek



smime.p7s
Description: S/MIME Cryptographic Signature
___
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] Can fossil be used to apply a diff patch?

[tonyp]

Thank you but I wanted this for a Win7 machine, not Linux.
(I have MINGW installed but its 'patch' is a bit unstable as it crashes most 
of the time besides not being available on most Win7 machines.)


That's why I was hoping fossil would be able to eat its own ... diff

Bundle is not good when the patch comes from a 3rd source (e.g., posted on a 
web site) in unified diff format, and there's nothing you can do about it.


Thanks, anyway.  I guess I need to look for a reliable Win7-based 
stand-alone patch utility.  Until then, manual editing! :)


-Original Message- 
From: Warren Young

Sent: Saturday, April 18, 2015 12:31 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Can fossil be used to apply a diff patch?

On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote:


Can fossil be used to apply a diff patch (such as that created by the diff 
command)?


Fossil itself doesn’t do that.  You use the patch(1) utility for that, which 
expects a unified diff.  (“fossil diff” produces output in that format by 
default, but diff(1) does not.)


If you want something that works entirely with Fossil tools, you should be 
using the new “bundle” features.  This creates a “sub-repository” containing 
a given change set, including all of the details Fossil tracks that do not 
appear in “fossil diff” output.

___
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] Can fossil be used to apply a diff patch?

[bch]

Note also that you can tailor your diff output w/ "fossil set diff-command"

eg: fossil set diff-command "diff -bu"

On 4/17/15, Warren Young  wrote:
> On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote:
>>
>> Can fossil be used to apply a diff patch (such as that created by the diff
>> command)?
>
> Fossil itself doesn't do that.  You use the patch(1) utility for that, which
> expects a unified diff.  ("fossil diff" produces output in that format by
> default, but diff(1) does not.)
>
> If you want something that works entirely with Fossil tools, you should be
> using the new "bundle" features.  This creates a "sub-repository" containing
> a given change set, including all of the details Fossil tracks that do not
> appear in "fossil diff" output.
> ___
> 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] Can fossil be used to apply a diff patch?

[Warren Young]

On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote:
> 
> Can fossil be used to apply a diff patch (such as that created by the diff 
> command)?

Fossil itself doesn’t do that.  You use the patch(1) utility for that, which 
expects a unified diff.  (“fossil diff” produces output in that format by 
default, but diff(1) does not.)

If you want something that works entirely with Fossil tools, you should be 
using the new “bundle” features.  This creates a “sub-repository” containing a 
given change set, including all of the details Fossil tracks that do not appear 
in “fossil diff” output.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Can fossil be used to apply a diff patch?

[tonyp]

Can fossil be used to apply a diff patch (such as that created by the diff 
command)?___
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] Two trunks?

[Ron W]

On Fri, Apr 17, 2015 at 7:24 AM, Joerg Sonnenberger  wrote:

> As discussed earlier, a fork means more than one
> leaf for the same branch.


And merging the leaf of a branch to another branch (maybe trunk) does not
make that leaf not-a-leaf. So why should merging a "fork-leaf" to whatever
make the "fork-leaf" not a "fork"?
___
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 about renaming a fork to "fork-*"? (Was: Two trunks?)

[Ron W]

Hello,

Did you mean for your reply to go only to me? You did not CC the Fossil
list.

On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich  wrote:

>
>*From: *Ron W
> *Sent: *Friday, 17 April 2015 11:04
> *To: *Fossil SCM user's discussion
> *Reply To: *Fossil SCM user's discussion
> *Subject: *Re: [fossil-users] Two trunks?
>
>   On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford  > wrote:
>
>> And a fork that ends in being merged is also no longer a fork.
>
>
>  I disagree. While it might be the most common case, merging does not
> explicitly state any intent beyond the merge itself, even a full merge.
> After all, a merge doesn't automatically close a named branch. So why would
> a merge automatically make a "fork" not a fork?
>
>  Closing it or making it the start of a new, named branch explicitly
> indicate an intent to remove "fork" status.
>
>
> ___
> 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] terminology confusion

[Andy Bradford]

Thus said "j. van den hoff" on Fri, 17 Apr 2015 07:51:26 +0200:

> but  if changing  the  terminology really  is  a seriously  considered
> issue, than  I cannot  abstain from  proposing "shoot"  instead (which
> would open the  theoretical possibility to indicate it  as `SHOOT!' in
> the CLI timeline display -- which  most of the time, would be correct,
> too ;-)

If we're looking for a new  term, then I propose ``aerial root'' because
they're cool:

http://commons.wikimedia.org/wiki/File:Aerial_roots_Banyan_Tree_Park.jpg

Thanks,

Andy
--
TAI64 timestamp: 400055312be5
___
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] terminology confusion

[James Moger]

> Fossil simply defines it:
>
> Having more than one leaf in the check-in DAG is called a "fork."
>
>
After re-reading the wiki section that you pointed out I have a much better
understanding of how Fossil defines a fork.  Thanks for pointing that out.
What I'm surprised at, after following both discussions, is I don't recall
seeing this mentioned, but perhaps it was:
*Fork*

A fork is when a check-in has two or more direct (non-merge) children in
the same branch.

And then the example text:
> Check-in 2 of figure 3 is considered a "fork" because it has two children
in the same branch. Check-in 2 of figure 5 also has two > children, but
each child is in a different branch, hence in figure 5, check-in 2 is
considered a "branch point."

Figure 3: https://www.fossil-scm.org/index.html/doc/trunk/www/branch03.gif
Figure 5: https://www.fossil-scm.org/index.html/doc/trunk/www/branch05.gif

My interpretation of fork was an "unmerged leaf" on the same branch - which
is incorrect, according to the docs.  This was also the reason I suggested
"head" as a Mercurial analog.

In the oft cited example of a fork in 2015 (which happens to be related to
my check-in submitted by bundle export/import).  My check-in is not
actually the fork; the parent of my check-in is the fork.

To use Ron's road analogy, if I am driving a car and I come to a fork in
the road I can go left or right or however many road choices I have.  The
fork is the point at which I make a choice.  Whichever road I choose, I
drive through the fork/branch point and I am now just on a road - maybe the
road ends quickly (leaf), maybe it keeps going (branch).

The distinction between "fork" and "branch point" then becomes important as
it gets to intent.
*Branch Point*

A branch point occurs when a check-in has two or more direct (non-merge)
children in different branches. A branch point is similar to a fork, except
that the children are in different branches.
So a leaf is never a fork; it is just a leaf.

Sorry if am restating what was obvious to everyone else.

-J
___
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] Merging deleted files (Was: Merge - including files from other branches - best practice?)

[Richard Hipp]

On 4/16/15, Steve Stefanovich  wrote:
>
> Richard, do you have a view on this?
>

I am following this conversation closely, as well as the discussion
regarding "forks".  But I don't have any free cycles available to work
on this, or even to comment on it, at the moment.

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

[fossil-users] Bug? FOSSIL MV does not work as expected (Win7 machine)

[Tony Papadimitriou]

This is on a Win7 machine (if it matters).  A simple way to reproduce (f = 
fossil):

f new xxx.fossil
f o xxx.fossil
mkdir a\a
dir > a\a\xxx
f add a
f com -m "Initial"
f mv a\a b
f close

Based on help screen, and usual behavior of mv, I would expect subdirectory a\a 
to be now known as b, and of course all files below to move accordingly.  But 
nothing happens.  If I move each file separately, it works.

This is what the help screen shows:

Usage: f mv|rename OLDNAME NEWNAME
   or: f mv|rename OLDNAME... DIR

Move or rename one or more files or directories within the repository tree.
You can either rename a file or directory or move it to another subdirectory.
___
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] terminology confusion

[James Moger]

>
> github calling the project clone maintained on the server side a fork (I
> believe that's what it is, right?).
>
>
100% correct; a Github fork is a server-side clone.

A Github fork is also part of the project "fork network".  This membership
allows you to propose changes from your copy of the project to another
repository copy in the network - this is the pull request.  Normally you
propose changes to the initial upstream repository from which you forked,
but you can also generate pull requests from your fork to any other repo in
the fork network.

-J
___
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] Two trunks?

[Joerg Sonnenberger]

On Fri, Apr 17, 2015 at 01:07:50PM +0200, Jan Nijtmans wrote:
> 2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger :
> > On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
> >> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
> ...
> >> I disagree. While it might be the most common case, merging does not
> >> explicitly state any intent beyond the merge itself, even a full merge.
> >> After all, a merge doesn't automatically close a named branch. So why would
> >> a merge automatically make a "fork" not a fork?
> >
> > You can still create commits from it, but update will move past it.
> > That's why it is no longer a fork.
> 
> Let's try that with a branch which is recently merged to trunk:

Right, but different. As discussed earlier, a fork means more than one
leaf for the same branch. My point is that a merge of a fork will be
passed over by update. In this case the branches are by definition the
same.

Joerg
___
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] Two trunks?

[Jan Nijtmans]

2015-04-17 12:02 GMT+02:00 Joerg Sonnenberger :
> On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
>> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
...
>> I disagree. While it might be the most common case, merging does not
>> explicitly state any intent beyond the merge itself, even a full merge.
>> After all, a merge doesn't automatically close a named branch. So why would
>> a merge automatically make a "fork" not a fork?
>
> You can still create commits from it, but update will move past it.
> That's why it is no longer a fork.

Let's try that with a branch which is recently merged to trunk:

$ fossil update update-fork-warn

updated-to:   72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10
17:33:18 UTC
leaf: closed
tags: update-fork-warn
comment:  Only check for forks on "open" leaves, otherwise we
cannot do anything about it from here anyway. Thanks to Andy Bradford
  for noticing this. (user: jan.nijtmans)
changes:  13 files modified.
 "fossil undo" is available to undo changes to the working checkout.

$ fossil update

checkout: 72794ec975ce4c8e43d519c1267eff1baab290fe 2015-04-10
17:33:18 UTC
leaf: closed
tags: update-fork-warn
comment:  Only check for forks on "open" leaves, otherwise we
cannot do anything about it from here anyway. Thanks to Andy Bradford
  for noticing this. (user: jan.nijtmans)
changes:  None. Already up-to-date

Looks like that statement is not true! "fossil update" will only move
past it if the
branch-name didn't change. I think Andy was right in his statement: the only
three ways a fork can be resolved is:
  1) "fossil merge" without any arguments, merging the two tips of the
fork together.
  2) "fossil merge --integrate ": merging to another branch, while
  implicitely closing .
  3) "fossil tag --raw closed " (or close it with the UI)

So, a merge which merges the two tips of a fork together indeed closes
the fork. But
for other merges more needs to be done, that's how it functions (as it should).
Sorry ;-)

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

Re: [fossil-users] Two trunks?

[Joerg Sonnenberger]

On Thu, Apr 16, 2015 at 09:04:12PM -0400, Ron W wrote:
> On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
> wrote:
> 
> > And a fork that ends in being merged is also no longer a fork.
> 
> 
> I disagree. While it might be the most common case, merging does not
> explicitly state any intent beyond the merge itself, even a full merge.
> After all, a merge doesn't automatically close a named branch. So why would
> a merge automatically make a "fork" not a fork?

You can still create commits from it, but update will move past it.
That's why it is no longer a fork.

Joerg
___
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] Merging deleted files (Was: Merge - including files from other branches - best practice?)

[Steve Stefanovich]

I can imagine a lot of people being annoyed if auto resolution was to add a 
file previously deleted from a branch back to the branch. I can see that being 
every bit as confusing to them as it not being re-added is to you. Just as my 
deleted text a month ago was to me.

The difference is that re-adding is showing up in 'fossil status', which is 
then easy to reverse by grepping it's output and piping to delete before 
commit; while for no-op, as currently is the case, you are not aware there is a 
potential problem at all. And if/when you figure out that files are missing, 
you'd have to resurrect and manually add them one by one.

But I wouldn't mind if, instead of no-op, status just shows that the ancestor 
was removed and current edits are therefore ignored. I can then equally grep 
for it and then bulk add it, if necessary. It would be interesting to know what 
others on the list think. It would be more cumbersome to describe, in my 
opinion - see below example.

I think the crucial thing here is the distinct indicator by the merge that this 
situation is encountered, so you can then choose to act if appropriate. How it 
is auto-resolved is less important.

For example, this indicator could be a status like 'CONFLICT', but would be 
auto-resolved to allow commit. For example, 'READDED_BY_MERGE' or, in your 
case,  'KEPT_DELETED_BY_MERGE' or 'IGNORED_CHANGES_ANCESTOR_MISSING'.

On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich 
mailto:s...@stef.rs>> wrote:
?I'd argue this is not intuitive, especially to a new Fossil user. "Losing" the 
file like this and not reporting at least as a warning seems like a wrong 
design choice, to me.

I'd agree it is not intuitive, as it took some hours of my time when I thought 
I'd found a bug a month ago to trace through the code looking for a flaw that 
didn't exist. I had told it at one point in time to merge in a deletion into my 
branch, and so when it came time to play catch up to trunk, it did what I had 
told it to do previously: Keep text previously deleted out of the new merge, 
even though in this case I needed to readd something due to other changes in 
fossil.

I actually like flagging the file as a conflict, with auto-resolution being to 
keep (re-add) the file. If this is tagged distinctively, then it is very easy - 
when you don't want the files re-introduced - to grep the output of 'fossil 
status' and bulk delete such files before committing the merge.

I can imagine a lot of people being annoyed if auto resolution was to add a 
file previously deleted from a branch back to the branch. I can see that being 
every bit as confusing to them as it not being re-added is to you. Just as my 
deleted text a month ago was to me.

But at least a warning would be very useful. We already have warnings when 
files don't have common ancestors while merging (the cause of which confused me 
enough times and is probably related to this).

How about this scenario:

1. Trunk is the mainline branch from which releases are made.
2. Feature is a branch for ongoing development of some feature.
3. Periodically you merge trunk into feature so that you don't drift too far 
(up to and including just before the final merge back to trunk).
4. In the end, you merge from the feature back to trunk when everything is 
ready for release.

I think in this case you'd get the warning you seek because in the parent 
branch it had been deleted while being edited in the child branch (the nearest 
common ancestor was on trunk).

I think you're right about the common ancestor confusion. I certainly can see 
the point about "deletion from one branch and edits in another branch being 
arguably a conflict requiring resolution". I'm just can't think of a better way 
to handle it than at present. This is probably why I don't get paid the big 
bucks.

--
Scott Robison

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