Re: [fossil-users] how to edit "All Tickets" presentation

2013-10-17 Thread Will Parsons
Ron Wilson wrote:
> We use the subsystem field, so I created a summary report with out the
> subsystem and comments fields. Fossil then auto-generated only columns for
> the selected fields.

I'm sorry, but I am completely at a loss to understand this.  You
*use* the "subsystem" field, but create a summary report without it?
Why?  And how?

> On Thu, Oct 17, 2013 at 8:18 PM, Will Parsons wrote:
>
>> Ron Wilson wrote:
>> > On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons > >wrote:
>> >
>> >>  I can't
>> >> figure out how to edit the "All Tickets" page to get rid of the
>> >> "subsystem" column, and without that I will get an error when I
>> >> display the page.
>> >
>> > You can edit the "default default" report from the Admin->Ticket Setup
>> page.
>>
>> What?  I don't see any "default default" report from the Admin->Ticket
>> Setup page.
>>
>> > For the existing All Tickets report, there is an "Edit" "button" on the
>> > tickets main menu for each report in the report list.
>>
>> Yes, but how does that help with changing the format of the "All
>> Tickets" page?

-- 
Will

___
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 edit "All Tickets" presentation

2013-10-17 Thread Ron Wilson
Admin->Tickets->Report Template

We use the subsystem field, so I created a summary report with out the
subsystem and comments fields. Fossil then auto-generated only columns for
the selected fields.


On Thu, Oct 17, 2013 at 8:18 PM, Will Parsons wrote:

> Ron Wilson wrote:
> > On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons  >wrote:
> >
> >>  I can't
> >> figure out how to edit the "All Tickets" page to get rid of the
> >> "subsystem" column, and without that I will get an error when I
> >> display the page.
> >
> > You can edit the "default default" report from the Admin->Ticket Setup
> page.
>
> What?  I don't see any "default default" report from the Admin->Ticket
> Setup page.
>
> > For the existing All Tickets report, there is an "Edit" "button" on the
> > tickets main menu for each report in the report list.
>
> Yes, but how does that help with changing the format of the "All
> Tickets" page?
>
> --
> Will
>
> ___
> 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 edit "All Tickets" presentation

2013-10-17 Thread Will Parsons
Ron Wilson wrote:
> On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons wrote:
>
>>  I can't
>> figure out how to edit the "All Tickets" page to get rid of the
>> "subsystem" column, and without that I will get an error when I
>> display the page.
>
> You can edit the "default default" report from the Admin->Ticket Setup page.

What?  I don't see any "default default" report from the Admin->Ticket
Setup page.

> For the existing All Tickets report, there is an "Edit" "button" on the
> tickets main menu for each report in the report list.

Yes, but how does that help with changing the format of the "All
Tickets" page?

-- 
Will

___
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 edit "All Tickets" presentation

2013-10-17 Thread Ron Wilson
On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons wrote:

>  I can't
> figure out how to edit the "All Tickets" page to get rid of the
> "subsystem" column, and without that I will get an error when I
> display the page.


You can edit the "default default" report from the Admin->Ticket Setup page.

For the existing All Tickets report, there is an "Edit" "button" on the
tickets main menu for each report in the report list.
___
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 edit "All Tickets" presentation

2013-10-17 Thread Will Parsons
I've been using fossil for some of my private projects for a few
months now, and at least on one of them there is no use for the
"subsystem" field for tickets.  I can see where to edit the schema to
delete the field from the database, but for the life of me I can't
figure out how to edit the "All Tickets" page to get rid of the
"subsystem" column, and without that I will get an error when I
display the page.

-- 
Will

___
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] 2-way sync between Git & Fossil

2013-10-17 Thread Matt Welland
On Thu, Oct 17, 2013 at 8:33 AM, Remigiusz Modrzejewski
wrote:

>
> On Oct 15, 2013, at 17:34 , Matt Welland wrote:
>
> > I have done what Ron suggests before and it works well but it is
> initially
> > complicated to set up. A generic script or tool to do this would be very
> > nice to have available.
> >
> > I created "vendor branches", one for each system, the git branch in
> fossil
> > would track the git master and the fossil branch in git would track
> fossil.
> > I use rsync to mirror the add/remove/change of files and then script up
> the
> > commit to capture the comment, time stamp, user etc. of the incoming
> data.
> > After rsync'ing in the change and committing it the script merges the
> > change to the trunk.
> >
> > It is very complicated but once set up it works great. BTW, I've done
> this
> > for other systems but never tried it with git. I'm not sure if there are
> > any git related gotchas.
>
> One important question: what is wrong with fossil import --git and fossil
> export --git?
>

If incremental import works reliably at both ends then yes, import/export
would likely be the best option. The only other reasons why the brute force
method might sometimes be better is if you have very large repositories and
full import and export generate very large amounts of data or, as Ron says
in another message, if you wish to keep only specific branches in sync.


>
>
> Kind regards,
> Remigiusz Modrzejewski
>
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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 and REQUEST_URI

2013-10-17 Thread Francis Daly
On Thu, Oct 17, 2013 at 01:40:28PM -0400, Richard Hipp wrote:

Hi there,

> The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or
> PATH_INFO.  CGI should always supply PATH_INFO.  SCGI should give us
> REQUEST_URI.  Either way, Fossil will be happy now.

CGI only requires SCRIPT_NAME.

If PATH_INFO would be non-empty, then it should be set for CGI. But an
empty PATH_INFO and an absent PATH_INFO are equivalent.

(And in that case, I guess that REQUEST_URI should have the same value
as SCRIPT_NAME, if REQUEST_URI is wanted.)

I think thttpd only sets PATH_INFO when non-empty. It sets SCRIPT_NAME,
but not REQUEST_URI.

f
-- 
Francis Dalyfran...@daoine.org
___
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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 8:25 PM, Ron Wilson  wrote:

> $ cat fci
> #! /usr/bin/bash
> echo "" > tmp$$.txt
> $EDITOR tmp$$.txt
> fossil ci -M tmp$$.txt $*
> rm tmp$$.txt
>

If you want to go one further you can protect against ctrl-c leaving a temp
file laying around by adding:

trap "rm -f tmp$$.txt" 0

somewhere near the top (e.g., right after the first echo "" bit).

OTOH, you might want to keep the temp file if the user Ctrl-C's out in an
untimeline fashion.


> This will create a temporary file using the process number of the running
> script, then delete it after the commit is done.
>

With the trap in place it's removed regardless of how the script exits.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread Ron Wilson
On Thu, Oct 17, 2013 at 1:29 PM, Andy Bradford wrote:

> No editor is  used in this case  (except the command line  editor) so it
> isn't exactly as interactive as using your favorite EDITOR but you don't
> have to supply a filename.
>
> Probably not exactly what you were looking for though.
>

How about:

$ cat fci
#! /usr/bin/bash
echo "" > tmp$$.txt
$EDITOR tmp$$.txt
fossil ci -M tmp$$.txt $*
rm tmp$$.txt
$

This will create a temporary file using the process number of the running
script, then delete it after the commit is done.

Optionally, you can pre-load the file with a message template, either as
the parameter the echo or use cp to copy a template 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] CGI and REQUEST_URI

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 7:40 PM, Richard Hipp  wrote:

> The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or
> PATH_INFO.  CGI should always supply PATH_INFO.  SCGI should give us
> REQUEST_URI.  Either way, Fossil will be happy now.
>

@Ben: FWIW, i've deployed this to my Apache-based CGI host and it seems
happy there.

http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/json/version?indent=2

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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 and REQUEST_URI

2013-10-17 Thread Richard Hipp
On Thu, Oct 17, 2013 at 1:21 PM, Stephan Beal  wrote:

> On Thu, Oct 17, 2013 at 7:17 PM, Richard Hipp  wrote:
>
>> Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and
>> will construct PATH_INFO from those two if it is missing.  I'm working on a
>> patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if
>> REQUEST_URI is missing instead.
>>
>
> i think the requirement on REQUEST_URI is in general a mistake (though one
> which appears to mostly work). There's no mention of REQUEST_URI in the CGI
> spec, though many CGI examples/howtos i'm looking at do use this (and some
> even imply that they are standard (e.g.
> http://www.cgi101.com/book/ch3/text.html), but i can find no proof of
> that).
>
>
I've checked in a potential fix.

The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or
PATH_INFO.  CGI should always supply PATH_INFO.  SCGI should give us
REQUEST_URI.  Either way, Fossil will be happy now.

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


Re: [fossil-users] commit message empty

2013-10-17 Thread Andy Bradford
Thus said sky5w...@gmail.com on Thu, 17 Oct 2013 13:06:02 -0400:

> Understood, but the point was to not create a message file.

My example  does not create a  message file but instead  tells fossil to
read the commit message from stdin (using a here document):

> > $ f ci -M - file < > > This is a test
> > > #this
> > > EOF
> > New_Version: a037b79c0b552ac0a2c60b6530f19ae5f4022155

No editor is  used in this case  (except the command line  editor) so it
isn't exactly as interactive as using your favorite EDITOR but you don't
have to supply a filename.

Probably not exactly what you were looking for though.

Andy
--
TAI64 timestamp: 400052601e90
___
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] choice of default user for fresh clone

2013-10-17 Thread j. van den hoff
On Thu, 17 Oct 2013 18:09:38 +0200, Stephan Beal   
wrote:


On Thu, Oct 17, 2013 at 5:56 PM, Stephan Beal   
wrote:



On Thu, Oct 17, 2013 at 5:51 PM, Richard Hipp  wrote:


+  if( zDefaultUser==0 && g.urlUser!=0 ) zDefaultUser = g.urlUser;



Works for me!



please try:

http://fossil-scm.org/index.html/info/64aa75260f


if that works let us know and i'll close your ticket (Richard had it  
fixed

a few seconds before your ticket landed, i think!).


it does. very very good. thanks a lot for fixing this. hoping for a fast  
next release (so that users not compiling themselves can get hold of it).







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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 and REQUEST_URI

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 7:17 PM, Richard Hipp  wrote:

> Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and
> will construct PATH_INFO from those two if it is missing.  I'm working on a
> patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if
> REQUEST_URI is missing instead.
>

i think the requirement on REQUEST_URI is in general a mistake (though one
which appears to mostly work). There's no mention of REQUEST_URI in the CGI
spec, though many CGI examples/howtos i'm looking at do use this (and some
even imply that they are standard (e.g.
http://www.cgi101.com/book/ch3/text.html), but i can find no proof of that).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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 and REQUEST_URI

2013-10-17 Thread Richard Hipp
On Thu, Oct 17, 2013 at 12:59 PM, Stephan Beal wrote:

> On Thu, Oct 17, 2013 at 6:37 PM, Ben Summers  wrote:
>
>> and of course, Jetty isn't sending a REQUEST_URI. This environment
>> variable isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty
>> for not sending it:
>>
>>   http://tools.ietf.org/html/rfc3875
>>
>> It looks like the addition of SCGI support in
>> http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the
>> requirement for REQUEST_URI.
>>
>> Which one of fossil or Jetty needs fixing?
>>
>
> i don't have a definitive answer (i'd never heard of SCGI before those
> patches arrived) but do have a tiny bit more info which might help someone
> else...
>
> http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface
>
> shows an example which implies that REQUEST_URI is indeed required by
> SCGI. As Ben says, though, it's not part of CGI.
>
> My suspicion is that Fossil needs to be fixed but that this hasn't yet
> been seen because Apache and friends provide REQUEST_URI even in CGI mode.
> i'll see if i can get an SCGI environment running here to try this out
> (apache appears to have a mod_scgi... let's see what that does...).
>
> i can't make any promises, but i'm looking into it.
>
>
Apparently we construct REQUEST_URI by appending PATH_INFO to SCRIPT_NAME.
The three are related.

Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and
will construct PATH_INFO from those two if it is missing.  I'm working on a
patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if
REQUEST_URI is missing instead.


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


Re: [fossil-users] CGI and REQUEST_URI

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 6:59 PM, Stephan Beal  wrote:

> My suspicion is that Fossil needs to be fixed but that this hasn't yet
> been seen because Apache and friends provide REQUEST_URI even in CGI mode.
> i'll see if i can get an SCGI environment running here to try this out
> (apache appears to have a mod_scgi... let's see what that does...).
>
> i can't make any promises, but i'm looking into it.
>

Setting up mod_proxy and friends for this is going to take more effort than
i can commit to tonight, but i'll give it a go after work tomorrow.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread sky5walk
Understood, but the point was to not create a message file.
However, seeing "fossil commit -M fossilcommit.txt" retains '#' lines, I
will just adopt this approach with a script. I actually like this method
more after trying it out. :)

Thanks for the feedback and fossil!


On Thu, Oct 17, 2013 at 12:06 PM, Andy Bradford wrote:

> Thus said Stephan Beal on Thu, 17 Oct 2013 16:49:53 +0200:
>
> > As far  as the  other changes go  regarding the #  symbol -  i'm still
> > waiting for someone  else to volunteer :). As a  general rule, i don't
> > like to change features which have  survived the test of time (even if
> > they're  not  100%  ideal,  so  long as  their  limitations  are  well
> > understood and not generally problematic).
>
> I don't think changes are required:
>
> $ f ci -M - file < > This is a test
> > #this
> > EOF
> New_Version: a037b79c0b552ac0a2c60b6530f19ae5f4022155
> $ f stat
> repository:   /tmp/new/../new.fossil
> local-root:   /tmp/new/
> config-db:/home/amb/.fossil
> checkout: a037b79c0b552ac0a2c60b6530f19ae5f4022155 2013-10-17 16:04:45
> UTC
> parent:   950f43a6f0812dfb7b2a9b894b8bccb1aa056585 2013-10-17 16:04:20
> UTC
> tags: trunk
> comment:  This is a test #this (user: amb)
>
> Notice that it preserved my comment.
>
> Fossil FTW!
>
> Andy
> --
> TAI64 timestamp: 400052600b14
> ___
> 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] CGI and REQUEST_URI

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 6:37 PM, Ben Summers  wrote:

> and of course, Jetty isn't sending a REQUEST_URI. This environment
> variable isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty
> for not sending it:
>
>   http://tools.ietf.org/html/rfc3875
>
> It looks like the addition of SCGI support in
> http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the
> requirement for REQUEST_URI.
>
> Which one of fossil or Jetty needs fixing?
>

i don't have a definitive answer (i'd never heard of SCGI before those
patches arrived) but do have a tiny bit more info which might help someone
else...

http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface

shows an example which implies that REQUEST_URI is indeed required by SCGI.
As Ben says, though, it's not part of CGI.

My suspicion is that Fossil needs to be fixed but that this hasn't yet been
seen because Apache and friends provide REQUEST_URI even in CGI mode. i'll
see if i can get an SCGI environment running here to try this out (apache
appears to have a mod_scgi... let's see what that does...).

i can't make any promises, but i'm looking into it.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] CGI and REQUEST_URI

2013-10-17 Thread Ben Summers

Hello,

I've just tried upgrading from fossil 1.25 to fossil 1.27 on my server, which 
uses Jetty as the CGI server.

I just see an error:

  Bad Request: missing REQUEST_URI

and of course, Jetty isn't sending a REQUEST_URI. This environment variable 
isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty for not 
sending it:

  http://tools.ietf.org/html/rfc3875

It looks like the addition of SCGI support in 
http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the requirement 
for REQUEST_URI.

Which one of fossil or Jetty needs fixing?

Thanks,

Ben


--
http://bens.me.uk

___
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] 2-way sync between Git & Fossil

2013-10-17 Thread Ron Wilson
On Thu, Oct 17, 2013 at 11:33 AM, Remigiusz Modrzejewski  wrote:

> One important question: what is wrong with fossil import --git and fossil
> export --git?
>

I tried that about a year ago. Fossil's export command lacks an option to
specify which branches to export and marking all branches but the "to git"
branch would have caused other problems for me. Was just easier to checkout
exactly what I wanted to commit in git in a work area, then commit to git.

But, if you want/need all the commits duplicated, then export/import would
be worth setting up.
___
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] choice of default user for fresh clone

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 5:56 PM, Stephan Beal  wrote:

> On Thu, Oct 17, 2013 at 5:51 PM, Richard Hipp  wrote:
>
>> +  if( zDefaultUser==0 && g.urlUser!=0 ) zDefaultUser = g.urlUser;
>>
>
> Works for me!
>

please try:

http://fossil-scm.org/index.html/info/64aa75260f


if that works let us know and i'll close your ticket (Richard had it fixed
a few seconds before your ticket landed, i think!).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread Andy Bradford
Thus said Stephan Beal on Thu, 17 Oct 2013 16:49:53 +0200:

> As far  as the  other changes go  regarding the #  symbol -  i'm still
> waiting for someone  else to volunteer :). As a  general rule, i don't
> like to change features which have  survived the test of time (even if
> they're  not  100%  ideal,  so  long as  their  limitations  are  well
> understood and not generally problematic).

I don't think changes are required:

$ f ci -M - file < This is a test
> #this 
> EOF
New_Version: a037b79c0b552ac0a2c60b6530f19ae5f4022155
$ f stat
repository:   /tmp/new/../new.fossil
local-root:   /tmp/new/
config-db:/home/amb/.fossil
checkout: a037b79c0b552ac0a2c60b6530f19ae5f4022155 2013-10-17 16:04:45 UTC
parent:   950f43a6f0812dfb7b2a9b894b8bccb1aa056585 2013-10-17 16:04:20 UTC
tags: trunk
comment:  This is a test #this (user: amb)

Notice that it preserved my comment.

Fossil FTW!

Andy
--
TAI64 timestamp: 400052600b14
___
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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 5:46 PM, Ron Wilson  wrote:

> Once libfossil is far enough along, we might consider making plug-ins for
> the IDEs we currently use.
>

sidebar/status update: i'm currently in one of my slow phases. i tend to
develop in bursts of 3-5 months or so and then run out of steam for a
couple months. If history repeats itself as predicted, i'll get "back into
it" full speed around Christmas time (where i otherwise have little or
nothing to do because Germany basically shuts down from the 3rd week of
December until the 2nd week of January).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] choice of default user for fresh clone

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 5:51 PM, Richard Hipp  wrote:

> +  if( zDefaultUser==0 && g.urlUser!=0 ) zDefaultUser = g.urlUser;
>

Works for me!

[stephan@host:~/tmp]$ f clone http://192.168.1.59:8080 x.fsl
Round-trips: 2   Artifacts sent: 0  received: 3
Clone finished with 471 bytes sent, 1161 bytes received
Rebuilding repository meta-data...
  100.0% complete...
project-id: e7e284b800fba80fea27a00bdb67352a82584f24
> admin-user: stephan (password is "6c5901")

[stephan@host:~/tmp]$ f clone http://other:other@192.168.1.59:8080 y.fsl
Round-trips: 2   Artifacts sent: 0  received: 3
Clone finished with 536 bytes sent, 1162 bytes received
Rebuilding repository meta-data...
  100.0% complete...
project-id: e7e284b800fba80fea27a00bdb67352a82584f24
admin-user: other (password is "79c800")



-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] choice of default user for fresh clone

2013-10-17 Thread Richard Hipp
I think the following patch will resolve the issue:

Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -131,10 +131,11 @@
   }

   zDefaultUser = find_option("admin-user","A",1);

   url_parse(g.argv[2], URL_PROMPT_PW|URL_ASK_REMEMBER_PW);
+  if( zDefaultUser==0 && g.urlUser!=0 ) zDefaultUser = g.urlUser;
   if( g.urlIsFile ){
 file_copy(g.urlName, g.argv[3]);
 db_close(1);
 db_open_repository(g.argv[3]);
 db_record_repository_filename(g.argv[3]);


Can somebody apply the patch above and test it out for me?


On Thu, Oct 17, 2013 at 11:39 AM, Stephan Beal wrote:

> On Thu, Oct 17, 2013 at 5:34 PM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> why is it that after
>>
>> fossil clone 
>> http://k...@enterprise.us/**path_to_projectproject.fossil
>>
>> it still is the user name of the local account doing the clone that is
>> defining the initial "default user"? I've stumbled over this a few times.
>> it would seem wiser to automatically create and set the default user to
>> "kirk" in this example (i.e. to the specified user name, if any (and only
>> fall back to local user name if this is not the case). otherwise, if I
>> forget to do
>>
>
> That looks like a classic case of "historical usage." i suspect most of
> those who hack on Fossil itself tend to use the same login names across
> systems (i know that's true for me and Richard, in any case). It of course
> would make better sense to use the name provided in the URL.
>
> Could i convince you to open a ticket for this?
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Since tyranny's the only guaranteed byproduct of those who insist on a
> perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


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


Re: [fossil-users] commit message empty

2013-10-17 Thread Ron Wilson
On Thu, Oct 17, 2013 at 11:01 AM,  wrote:

> I'm asking why can't I perform a manual commit without comments being
> ignored, but not using -M.
>

Maybe a command option or a config option.

The underlying idea of providing and ignoring instructions to the user is
still sound and is in line with Fossil's philosophy of making it easy to
use out-of-the-box.

Also, for what it's worth, my team currently relies on Fossil doing this.
Yes, sometimes ignoring lines starting with # is inconvenient, but it's no
big deal to "hide" the #.

Again, for what it's worth, when we were still using MS Windows (because of
tools being tied to MS Windows), we used CodeWright as our IDE, which had
good support for command line tools. We configured the "Check In" command
as "fossil addremove; fossil commit -M %Q:Enter brief commit message%". For
this, CW would pop-up a text entry dialog with the title "Enter brief
commit message", Then CW would would create a temporary file with the the
entered text and run the command, replacing the %Q:...% with the file name.

Once libfossil is far enough along, we might consider making plug-ins for
the IDEs we currently use.
___
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] choice of default user for fresh clone

2013-10-17 Thread j. van den hoff
On Thu, 17 Oct 2013 17:39:23 +0200, Stephan Beal   
wrote:



On Thu, Oct 17, 2013 at 5:34 PM, j. van den hoff
wrote:


why is it that after

fossil clone  
http://k...@enterprise.us/**path_to_projectproject.fossil


it still is the user name of the local account doing the clone that is
defining the initial "default user"? I've stumbled over this a few  
times.

it would seem wiser to automatically create and set the default user to
"kirk" in this example (i.e. to the specified user name, if any (and  
only

fall back to local user name if this is not the case). otherwise, if I
forget to do



That looks like a classic case of "historical usage." i suspect most of
those who hack on Fossil itself tend to use the same login names across
systems (i know that's true for me and Richard, in any case). It of  
course

would make better sense to use the name provided in the URL.

Could i convince you to open a ticket for this?


convinced... should be there in a few minutes.





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] 2-way sync between Git & Fossil

2013-10-17 Thread Remigiusz Modrzejewski

On Oct 15, 2013, at 17:34 , Matt Welland wrote:

> I have done what Ron suggests before and it works well but it is initially
> complicated to set up. A generic script or tool to do this would be very
> nice to have available.
> 
> I created "vendor branches", one for each system, the git branch in fossil
> would track the git master and the fossil branch in git would track fossil.
> I use rsync to mirror the add/remove/change of files and then script up the
> commit to capture the comment, time stamp, user etc. of the incoming data.
> After rsync'ing in the change and committing it the script merges the
> change to the trunk.
> 
> It is very complicated but once set up it works great. BTW, I've done this
> for other systems but never tried it with git. I'm not sure if there are
> any git related gotchas.

One important question: what is wrong with fossil import --git and fossil 
export --git?


Kind regards,
Remigiusz Modrzejewski



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


Re: [fossil-users] choice of default user for fresh clone

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 5:34 PM, j. van den hoff
wrote:

> why is it that after
>
> fossil clone 
> http://k...@enterprise.us/**path_to_projectproject.fossil
>
> it still is the user name of the local account doing the clone that is
> defining the initial "default user"? I've stumbled over this a few times.
> it would seem wiser to automatically create and set the default user to
> "kirk" in this example (i.e. to the specified user name, if any (and only
> fall back to local user name if this is not the case). otherwise, if I
> forget to do
>

That looks like a classic case of "historical usage." i suspect most of
those who hack on Fossil itself tend to use the same login names across
systems (i know that's true for me and Richard, in any case). It of course
would make better sense to use the name provided in the URL.

Could i convince you to open a ticket for this?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] choice of default user for fresh clone

2013-10-17 Thread j. van den hoff

why is it that after

fossil clone http://k...@enterprise.us/path_to_project project.fossil

it still is the user name of the local account doing the clone that is  
defining the initial "default user"? I've stumbled over this a few times.  
it would seem wiser to automatically create and set the default user to  
"kirk" in this example (i.e. to the specified user name, if any (and only  
fall back to local user name if this is not the case). otherwise, if I  
forget to do


fossil user add kirk
fossil user default kirk

(and  at least `fossil user capabilities kirk v', I believe) the next  
checkin will unintentionally use my local user name (which I even might  
want not be broadcasted and ending up in the timeline display of the  
server repo).



am I missing some important point here?
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 5:01 PM,  wrote:

> If this is true, why couldn't fossil collapse that same effect for a
>> manual commit step?
>>
> i'm not sure what you mean by that?
>
> me -> I'm asking why can't I perform a manual commit without comments
> being ignored, but not using -M.
>

So you want a manual commit _with_ comments? Sorry, the quadruple negation
here is confusing me: can't... without ... ignored ... not using.

If you want to use '#' in your commit message, either use -M or type them
in using -m:

fossil commit -m '# part 1
# part 2
# part 3' file file2 file3


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread sky5walk
>
> If this is true, why couldn't fossil collapse that same effect for a
> manual commit step?
>
i'm not sure what you mean by that?

me -> I'm asking why can't I perform a manual commit without comments being
ignored, but not using -M.



On Thu, Oct 17, 2013 at 10:49 AM, Stephan Beal wrote:

> On Thu, Oct 17, 2013 at 4:37 PM,  wrote:
>
>> If this is true, why couldn't fossil collapse that same effect for a
>> manual commit step?
>>
>
> i'm not sure what you mean by that?
>
>
>> My commit use model is I always select all and delete all predefined
>> comments and paste in my own.
>>
>
> Mine is always to use -m ... ;).
>
> Unless I am doing a merge and then I take advantage of the autogenerated
>> sha1 artifact specified.
>>  But, then I have to remember to delete the dang '#' symbol!! :(
>>
>> It is more work to specify a message file, since my history/commit
>> documents are appended and not isolated or new per commit.
>>
>
> AFAIK, nobody really uses the -M option (probably because it's too tedious
> to use for most purposes, maybe unless you're auto-importing lists of
> changes from another SCM). It was added back in December 2009, and IIRC it
> was because someone on the list proposed it and i thought i'd be
> interesting (but then i never used it myself).
>
> As far as the other changes go regarding the # symbol - i'm still waiting
> for someone else to volunteer :). As a general rule, i don't like to change
> features which have survived the test of time (even if they're not 100%
> ideal, so long as their limitations are well understood and not generally
> problematic).
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Since tyranny's the only guaranteed byproduct of those who insist on a
> perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> 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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 4:37 PM,  wrote:

> If this is true, why couldn't fossil collapse that same effect for a
> manual commit step?
>

i'm not sure what you mean by that?


> My commit use model is I always select all and delete all predefined
> comments and paste in my own.
>

Mine is always to use -m ... ;).

Unless I am doing a merge and then I take advantage of the autogenerated
> sha1 artifact specified.
> But, then I have to remember to delete the dang '#' symbol!! :(
>
> It is more work to specify a message file, since my history/commit
> documents are appended and not isolated or new per commit.
>

AFAIK, nobody really uses the -M option (probably because it's too tedious
to use for most purposes, maybe unless you're auto-importing lists of
changes from another SCM). It was added back in December 2009, and IIRC it
was because someone on the list proposed it and i thought i'd be
interesting (but then i never used it myself).

As far as the other changes go regarding the # symbol - i'm still waiting
for someone else to volunteer :). As a general rule, i don't like to change
features which have survived the test of time (even if they're not 100%
ideal, so long as their limitations are well understood and not generally
problematic).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread sky5walk
"For those who don't know about it: fossil supports a -M (big emm) option
which reads the commit message from a file and doesn't not apply any
#-related special handling to the content (or it didn't at the time it was
implemented, and i'm assuming that hasn't changed)"
- stephan beal
Whoa, I didn't know that?
If this is true, why couldn't fossil collapse that same effect for a manual
commit step?
My commit use model is I always select all and delete all predefined
comments and paste in my own.
Unless I am doing a merge and then I take advantage of the autogenerated
sha1 artifact specified.
But, then I have to remember to delete the dang '#' symbol!! :(

It is more work to specify a message file, since my history/commit
documents are appended and not isolated or new per commit.


On Thu, Oct 17, 2013 at 10:23 AM,  wrote:

> I also take exception to this being only a recent phenomena. I have been
> burned several times now, but as you say, this is not a mission critical
> error.
> However, me and my users cherish the timeline view and are confused by
> random omissions of '#'this or '#'that. So I do not feel the comments are
> trivial.
>
> I would really appreciate any of the other suggestions.
> Multi-char lead being less onerous.
>
> #Thanks for fossil!
>
>
> On Thu, Oct 17, 2013 at 10:03 AM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> On Thu, 17 Oct 2013 15:59:45 +0200, Stephan Beal 
>> wrote:
>>
>>  On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff
>>> **wrote:
>>>
>>>  `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what
 somebody else already proposed). I'd say that will work better than `#'
 (i.e. accidentally names clash very very unlikely) and sufficiently
 stands
 out on the respective lines due to the capitalization.

>>>
>>>
>>> Historical note (i don't think you've been on the list long enough to
>>> have
>>> seen this): here's the summary from some code comments in fossil:
>>>
>>> /*
>>> ** Locate the root directory of the local repository tree.  The root
>>> ** directory is found by searching for a file named "_FOSSIL_" or
>>> ".fslckout"
>>> ** that contains a valid repository database.
>>> **
>>> ** For legacy, also look for ".fos".  The use of ".fos" is deprecated
>>> ** since "fos" has negative connotations in Hungarian, we are told.
>>> ...
>>>
>>> A user made us aware at some point that fos is an ugly/inappropriate word
>>> in his language (i concur with the code comment that it was Hungarian).
>>>
>>
>> well, there are _towns_ having offending names
>>
>> http://en.wikipedia.org/wiki/**Fucking,_Austria:-)
>>
>> so I presume the hungarian users will probably don't take real offense
>> but anyway "FOSSIL:" would be fine to.
>>
>>
>>
>>>
>>
>> --
>> Using Opera's revolutionary email client: http://www.opera.com/mail/
>> __**_
>> 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] commit message empty

2013-10-17 Thread sky5walk
I also take exception to this being only a recent phenomena. I have been
burned several times now, but as you say, this is not a mission critical
error.
However, me and my users cherish the timeline view and are confused by
random omissions of '#'this or '#'that. So I do not feel the comments are
trivial.

I would really appreciate any of the other suggestions.
Multi-char lead being less onerous.

#Thanks for fossil!


On Thu, Oct 17, 2013 at 10:03 AM, j. van den hoff  wrote:

> On Thu, 17 Oct 2013 15:59:45 +0200, Stephan Beal 
> wrote:
>
>  On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff
>> **wrote:
>>
>>  `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what
>>> somebody else already proposed). I'd say that will work better than `#'
>>> (i.e. accidentally names clash very very unlikely) and sufficiently
>>> stands
>>> out on the respective lines due to the capitalization.
>>>
>>
>>
>> Historical note (i don't think you've been on the list long enough to have
>> seen this): here's the summary from some code comments in fossil:
>>
>> /*
>> ** Locate the root directory of the local repository tree.  The root
>> ** directory is found by searching for a file named "_FOSSIL_" or
>> ".fslckout"
>> ** that contains a valid repository database.
>> **
>> ** For legacy, also look for ".fos".  The use of ".fos" is deprecated
>> ** since "fos" has negative connotations in Hungarian, we are told.
>> ...
>>
>> A user made us aware at some point that fos is an ugly/inappropriate word
>> in his language (i concur with the code comment that it was Hungarian).
>>
>
> well, there are _towns_ having offending names
>
> http://en.wikipedia.org/wiki/**Fucking,_Austria:-)
>
> so I presume the hungarian users will probably don't take real offense but
> anyway "FOSSIL:" would be fine to.
>
>
>
>>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> __**_
> 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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 4:03 PM, j. van den hoff
wrote:

> well, there are _towns_ having offending names
>

lol! There's a bus line (from Germany) which has got a nearly identical
name.

"FOSSIL:" seems reasonable to me, but i'm not going to volunteer to change
it for the simple reason that have only used the $EDITOR feature one time
ever (across all SCMs, going back about 16 years), and that was to test the
"comment"/"message" change you submitted a few days ago.

For those who don't know about it: fossil supports a -M (big emm) option
which reads the commit message from a file and doesn't not apply any
#-related special handling to the content (or it didn't at the time it was
implemented, and i'm assuming that hasn't changed), e.g.:

fossil commit -M messagefile file1 file2...

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread j. van den hoff
On Thu, 17 Oct 2013 15:59:45 +0200, Stephan Beal   
wrote:



On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff
wrote:


`FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what
somebody else already proposed). I'd say that will work better than `#'
(i.e. accidentally names clash very very unlikely) and sufficiently  
stands

out on the respective lines due to the capitalization.



Historical note (i don't think you've been on the list long enough to  
have

seen this): here's the summary from some code comments in fossil:

/*
** Locate the root directory of the local repository tree.  The root
** directory is found by searching for a file named "_FOSSIL_" or
".fslckout"
** that contains a valid repository database.
**
** For legacy, also look for ".fos".  The use of ".fos" is deprecated
** since "fos" has negative connotations in Hungarian, we are told.
...

A user made us aware at some point that fos is an ugly/inappropriate word
in his language (i concur with the code comment that it was Hungarian).


well, there are _towns_ having offending names

http://en.wikipedia.org/wiki/Fucking,_Austria :-)

so I presume the hungarian users will probably don't take real offense but  
anyway "FOSSIL:" would be fine to.







--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff
wrote:

> `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what
> somebody else already proposed). I'd say that will work better than `#'
> (i.e. accidentally names clash very very unlikely) and sufficiently stands
> out on the respective lines due to the capitalization.


Historical note (i don't think you've been on the list long enough to have
seen this): here's the summary from some code comments in fossil:

/*
** Locate the root directory of the local repository tree.  The root
** directory is found by searching for a file named "_FOSSIL_" or
".fslckout"
** that contains a valid repository database.
**
** For legacy, also look for ".fos".  The use of ".fos" is deprecated
** since "fos" has negative connotations in Hungarian, we are told.
...

A user made us aware at some point that fos is an ugly/inappropriate word
in his language (i concur with the code comment that it was Hungarian).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread j. van den hoff

my final 2c:

before my colleague tripped over this by _assuming_ that "comment" in the  
checkin template meant "shell (or perl, python, whatever) type comment"  
and, due to this misconception _intentionally_ formatted his commit  
message with leading `#' I was not aware of the potential problem (never  
happpened to me, anyway). another poster mentioned to trip over the same  
problem by referring to "#include" (or similar) in his commit message,  
which I presume _might_ happen by and then to the unwary user, too.


still I agree that the sanest way is to keep it simple and identify  
ignored lines by some leading short ring. here's what mercurial does:


8<


HG: Enter commit message.  Lines beginning with 'HG:' are removed.
HG: Leave message empty to abort commit.
HG: --
HG: user: someone
HG: branch 'default'
HG: added tt
8<

I'd say that is more reaonsable than `#' (and to abort the checkin when  
the message is left empty is, too, but that's another story...). so what  
about -- for one -- mimicking `mercurial' here and to use


`FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what  
somebody else already proposed). I'd say that will work better than `#'  
(i.e. accidentally names clash very very unlikely) and sufficiently stands  
out on the respective lines due to the capitalization.




On Thu, 17 Oct 2013 15:31:37 +0200, Stephan Beal   
wrote:



On Thu, Oct 17, 2013 at 3:14 PM, Stestagg  wrote:

Using a marker line would allow for commit messages to contain any  
content




i can't say that i would like commit messages to be able to contain "any
content." They're not intended to be general purposes documentation, but
_brief_ descriptions of changes made in the context of the current  
commit.

A commit message field is not intended to hold a whole changelog for a
release nor a combined list of all changes from commits imported en masse
from another SCM (for such uses, just keep the change list as a separate
file and check it in along with the commit).

IMO the whole thing is far more trouble than it's worth and introduces  
many
corner cases and bugs where we currently don't have any (or only have  
very

old, well-understood ones which we can blame on the other systems which
were emulated ;). "If it ain't broke, don't touch it."




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] commit message empty

2013-10-17 Thread Stephan Beal
On Thu, Oct 17, 2013 at 3:14 PM, Stestagg  wrote:

> Using a marker line would allow for commit messages to contain any content
>

i can't say that i would like commit messages to be able to contain "any
content." They're not intended to be general purposes documentation, but
_brief_ descriptions of changes made in the context of the current commit.
A commit message field is not intended to hold a whole changelog for a
release nor a combined list of all changes from commits imported en masse
from another SCM (for such uses, just keep the change list as a separate
file and check it in along with the commit).

IMO the whole thing is far more trouble than it's worth and introduces many
corner cases and bugs where we currently don't have any (or only have very
old, well-understood ones which we can blame on the other systems which
were emulated ;). "If it ain't broke, don't touch it."

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do." -- Bigby Wolf
___
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] commit message empty

2013-10-17 Thread Stestagg
Using a marker line would allow for commit messages to contain any content

For example:
==
[commit message goes here, any character accepted]

### End comment

Enter comments on this check-in.  Lines below the last '### End comment'
are ignored

 user: 
 tags: trunk

 EDITED ...


Thanks

Steve


On Thu, Oct 17, 2013 at 1:30 AM, Matt Welland  wrote:

> 1. "Until today, '#' fell into the category of "extremely unlikely" to
> cause a problem ;)"
>   => I've hit this limitation a couple times. It seemed a little silly to
> me to use
>  a single hash in this context but since I could go into the UI and
> "fix" things
>  I didn't consider it important enough to report.
>
> 2. "I think that's too long, especially when you un-comment lines
>
> to include them (unless your editor supports rectangular selection)."
>   => Make it shorter, how about "#fsl#"? Any decent modern editor has
> rectangular
>  selection I'm sure. Us antiquated vi and (x)emacs users are covered
> of course :)
>
> When I have a multi-line comment to enter I just put my -m at the end of
> line and use quotes however I generally prefer succinct one line comments.
>
>
>
> On Wed, Oct 16, 2013 at 11:51 AM, Ron Wilson  wrote:
>
>> On Wed, Oct 16, 2013 at 2:43 PM, Matt Welland wrote:
>>
>>> Simply make the ignore prefix something extremely unlikely to collide
>>> such as:
>>>
>>> ##-fossil-## Enter comments on this check-in.
>>> ##-fossil-## Lines beginning with "##-fossil-##" are ignored.
>>> ##-fossil-##
>>> ##-fossil-## user: matt
>>> ##-fossil-## tags: v1.55
>>> ##-fossil-##
>>> ##-fossil-## EDITED db.scm
>>> ##-fossil-## EDITED tests/Makefile
>>>
>>
>> I think that's too long, especially when you un-comment  lines to include
>> them (unless your editor supports rectangular selection).
>>
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>>
>
>
> --
> Matt
> -=-
> 90% of the nations wealth is held by 2% of the people. Bummer to be in the
> majority...
>
> ___
> 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] SSL certificate verification problem

2013-10-17 Thread j. van den hoff
On Thu, 17 Oct 2013 06:01:51 +0200, Andy Bradford  
 wrote:



Thus said Stephan Beal on Tue, 15 Oct 2013 19:08:30 +0200:

[stephan@host:~/cvs/fossil/fossil/src]$ grep 'server does not respond'  
*.*


The actual error is:

Accept certificate for host fossil (a=always/y/N)? y
server did not reply

$ grep 'server did not reply' *.*
http.c:fossil_fatal("server did not reply");

To cause this error message I just killed the remote fossil process that
was running before answering y.

I suspect  that something like  a dropped  connection may have  been the
cause  of  this,  but  it's  hard  to  say  without  more  details  (and
reproducibility).


I'm sorry, I don't have any of these details right now. I propose to ask  
my colleague to try to reproduce the error. I might take a bit of time,  
though. is this of interest?


for the record, what I do now is:

-- the problem occurred during the initial clone attempt of an essentially  
empty new repo (might have been 100kB)


-- if this makes a difference: it was a "cgi-served" repo and https

-- yes, there is a firewall involved

I've thought about a possible time-out problem but I would presume he (the  
colleague in the US) did just follow the provided recipe (he has no  
previous experience with fossil) step by step ("type fossil clone  
https:username@server repo.fossil and provide password"...) and it seems  
quite unlikely that he walked away for coffee at that point w/o answering  
the question).




Andy



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users