Re: [fossil-users] Suggestion: WIKI command EXPORT clean of tags

[Warren Young]

On Jun 28, 2017, at 7:57 AM, Tony Papadimitriou  wrote:
> 
> However, these formatting tags are displayed cluttering the display (for some 
> heavily formatted pages to the point of being unreadable).

Why not use Markdown formatting then?  The same source file that produces 
pretty HTML is generally usable as plain text as well.

> With the filter, a cleaner view:

It feels like a violation of a separation of concerns boundary to me.

Fossil does already blur this line, doing transforms from the native data 
format (e.g. Markdown, Fossil Wiki, etc.) to HTML, but I don’t see that as a 
good reason why it should support an arbitrary number of other transforms.  
Where’s the limit?

HTML is special because the web is special.  No other output format has that 
same level of privilege.

Plain text has a different order of privilege from HTML.  Information should be 
stored in Fossil in the most universal form, then transformed at the end user’s 
computer as needed.

I view your problem as similar to storing C source code in Fossil in a Word 
document.  If you sometimes want plain C code and sometimes want a Word doc, 
store the file in plain C form and transform it into Word as needed, not the 
other way around.

> I currently use a Lua script to do this cleaning

You’ve reinvented a perfectly good wheel here.  Allow me to demonstrate it 
using Fossil’s own repo:

 $ f wiki exp 'To Do List' | pandoc -f mediawiki -t plain

This is what I mean by “separation of concerns:” use a tool like Pandoc when 
you want to transform markup formats.  Fossil should provide the untouched 
original or an HTML rendering, and that’s it.  Leave everything else up to 
format translators.

Pandoc also supports Markdown input and output, so you could strip even most of 
the Markdown formatting, if you wanted.

> However, if there are tags inside a  ...  they should 
> remain visible.

Yet another reason to leave this to specialist tools like Pandoc, in my view.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion: WIKI command EXPORT clean of tags

[Ron W]

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

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

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

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

fw page+name

The macro is defined as:

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

The only downside to this macro is needing to type + instead of spaces when
a page name has spaces. (Though, I'm old enough that my first use of a wiki
was with one that used the old "WikiWord" convention for naming pages, so I
tend to name wiki pages in that style.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion: WIKI command EXPORT clean of tags

[Tony Papadimitriou]

I use Wiki a lot for keeping short notes/memos about pretty much anything 
related to the host repo.
For cosmetic purposes when viewing from a Web browser these notes often contain 
 ...  or other such formatting tags.

However, doing most programming from the command-line, when I want to quickly 
look up some notes, I often do (f=fossil):

f wik exp PAGENAME

to get the related note displayed on the console screen.

However, these formatting tags are displayed cluttering the display (for some 
heavily formatted pages to the point of being unreadable).

My suggestion is when ‘wiki export’ command is used without the optional file 
(which would save wiki page to a file, as is), and the console is the target to 
filter out all those formatting tags.  A simple example:

The way it is now I would get: f wik exp "pinout"

BDM pinout

  *  PIN 1 - BKGD
  *  PIN 2 - GND
  *  PIN 3 - NC
  *  PIN 4 - RESET
  *  PIN 5 - NC
  *  PIN 6 - VCC

With the filter, a cleaner view:

BDM pinout

  *  PIN 1 - BKGD
  *  PIN 2 - GND
  *  PIN 3 - NC
  *  PIN 4 - RESET
  *  PIN 5 - NC
  *  PIN 6 – VCC

I currently use a Lua script to do this cleaning by piping the output through 
it, so I have to use something like:

f wik exp "pinout"  | cleanhtml

but it would be nice if FOSSIL could do this filtering on its own given you do 
not normally want to see those tags when displaying the wiki page on the 
console.  However, if there are tags inside a  ...  they 
should remain visible.

What do you think?

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

[fossil-users] Suggestion for MERGE default comment

[tonyp]

When merging one branch to another, the merge usually reflects more than a 
single commit.

So, just like when a commit is aborted, the next time you try to commit you’re 
given the previously typed comment as default, it would be nice if after 
merging, the default comment for the next COMMIT (i.e., when not using the –m 
command-line option but the editor) was the accumulated comments of all 
check-ins represented in the merge.  One can then edit out what’s not 
important.  This is less work than trying to (remember and) type all details 
about the changes merged in.  (This is also useful when the merged in content 
comes from a private branch which may later be deleted losing all detailed 
comments about the changes.)

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

Re: [fossil-users] Suggestion for MERGE default comment

[tonyp]

From: Stephan Beal 
Sent: Sunday, January 17, 2016 3:11 AM
To: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Suggestion for MERGE default comment

On Sun, Jan 17, 2016 at 1:53 AM, <to...@acm.org> wrote:

  important.  This is less work than trying to (remember and) type all details 
about the changes merged in.  (This is also useful when the merged in content 
comes from a private branch which may later be deleted losing all detailed 
comments about the changes.)

i would argue that most people write 'merged in [other-branch]' and let those 
interested go read the commits for that branch.

Which is exactly why I mentioned the possibility of deleted private branches, 
losing the detailed commit comments from those branches!
Anyway, it was just an idea that would certainly save me some typing as I do 
this kind of commenting a lot.
But, I’ll submit to the (assumed) ‘most people’ argument. :)

Thanks.

-- 

- stephan beal
http://wanderinghorse.net/home/stephan/ 
http://gplus.to/sgbeal
"Freedom is sloppy. But 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] Suggestion for local/global settings enhancement

[Ron W]

This would be a very helpful enhancement.

On Sat, Dec 5, 2015 at 1:05 PM,  wrote:
>
> My suggestion is this:
>
> Have some form of shorthand notation – a text replacement macro, if you
> like – (like the string “~global~”, for example – or some other that is
> very unlikely to be an actual filename – or even something that is
> impossible to be a filename depending on the underlying OS), to let one
> import all the global settings for the given setting when specifying the
> local setting.
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for local/global settings enhancement

[Ross Berteig]

On 12/5/2015 10:05 AM, to...@acm.org wrote:

Certain settings, like ignore-glob or binary-glob can have a really long
list of items, which may be edited from time to time.


This was the motivation for the invention of "versionable" settings, 
allowing the list to be maintained in a multi-line text file.



Ideally, the global setting should have the ones that apply to all
repos, while the local setting only the ones that apply only to that
specific repo.


IMHO, a repository should stand alone. It should provide all the 
specifications needed to work with and build. The "*-glob" settings are 
inherently project-specific, and could break scripts or other automation 
if they were changed unexpectedly. Specifying them completely as 
versionable settings minimizes that risk, and tracks them along with 
revisions of the project as a whole.


Global settings are for things that are obviously specific to a 
particular host and/or developer, and which need to be customized for 
each host and/or developer so that the repository works as intended. 
Settings like "proxy", any "*-command", and any described as providing a 
full pathname are obvious candidates for a global setting.



The problem is once you decide to use the local setting you need to
specify the whole long list of items again for each repo.  And if you
later change the global setting you need to remember to redefine all
local settings for repos that include more items in the same setting to
include the changes of the global setting.


I believe this is an intended effect.


My suggestion is this:

I hope I described this well enough to make sense.  I also hope you see
the usefulness of what I’m proposing.  (Well, at least if you normally
maintain more than just a few repos.)


It isn't too difficult to keep a reference set of default contents for 
the .fossil-settings folder and to write a site-specific script that 
tunes a new repository by copying in that folder and doing fossil add on 
it, and automating other customizations as needed.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion for local/global settings enhancement

[tonyp]

Certain settings, like ignore-glob or binary-glob can have a really long list 
of items, which may be edited from time to time.
Ideally, the global setting should have the ones that apply to all repos, while 
the local setting only the ones that apply only to that specific repo.

The problem is once you decide to use the local setting you need to specify the 
whole long list of items again for each repo.  And if you later change the 
global setting you need to remember to redefine all local settings for repos 
that include more items in the same setting to include the changes of the 
global setting.

My suggestion is this:

Have some form of shorthand notation – a text replacement macro, if you like – 
(like the string “~global~”, for example – or some other that is very unlikely 
to be an actual filename – or even something that is impossible to be a 
filename depending on the underlying OS), to let one import all the global 
settings for the given setting when specifying the local setting.

So, if the global setting is

binary-glob  (global) 
*.bin,*.bmp,*.com,*.dll,*.ico,*.exe,*.gif,*.jpg,*.mdb,*.mp3,*.mp4,*.obj,*.pdf,*.png,*.rar,*.jar,*.res,*.rtf,*.wav,*.zip,*.ppu,*.o

and the local setting needs to add to the above list just one item (*.pmp), one 
could do this:

fossil set binary-glob ~global~,*.pmp

(where ~global~ can appear anywhere, first, in-between, or last) and fossil set 
will display (in this case):

binary-glob  (local) 
*.bin,*.bmp,*.com,*.dll,*.ico,*.exe,*.gif,*.jpg,*.mdb,*.mp3,*.mp4,*.obj,*.pdf,*.png,*.rar,*.jar,*.res,*.rtf,*.wav,*.zip,*.ppu,*.o,*.pmp

However, the substitution of (macro) ~local~ should occur only at run-time so 
that a possible later update of the global setting will be automatically 
carried over to all local settings using ~global~

I hope I described this well enough to make sense.  I also hope you see the 
usefulness of what I’m proposing.  (Well, at least if you normally maintain 
more than just a few repos.)

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

Re: [fossil-users] Suggestion for command-line timeline display

[Warren Young]

On Oct 1, 2015, at 3:46 PM, Barry Arthur  wrote:
> 
> My favourite tool for this sort of thing is supercat: 
> http://supercat.nosredna.net/
> I don't know if it compiles on Windows.

Not unless you build it under Cygwin.  A quick scan of the source turns up a 
number of Linux/POSIXisms: getopt_long(), regcomp(), etc.

The program also uses hard-coded ANSI sequences, rather than an abstraction 
layer that could do things differently on Windows.  (Or on a non-ANSI-derived 
terminal, for that matter!)

Cygwin solves not only the build problem, but also the ANSI problem, since its 
stock terminal is mintty, which is a full-featured xterm-256color type terminal 
program.

...And Fossil is in the standard Cygwin package repository. :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Suggestion for command-line timeline display

[Tony Papadimitriou]

Hello,

Not too long ago SQLite3 shell got a colored startup message about using 
“transient in-memory database”.

I was wondering if the same idea could be used to highlight the *CURRENT* entry 
in the timeline (with some soft color – a shade of blue or green would be nice).
This is because in a timeline with a lot of sequential *MERGE* entries, finding 
*CURRENT* becomes a little ‘difficult’.  Why not have some color make it very 
obvious?

(BTW, in the way things are, I think the *CURRENT* message would stand out a 
little better if it came first, i.e., before the *MERGE* message.)

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

Re: [fossil-users] Suggestion for command-line timeline display

[Andy Bradford]

Thus said "Tony Papadimitriou" on Thu, 01 Oct 2015 15:29:05 +0300:

> I  was wondering  if the  same  idea could  be used  to highlight  the
> *CURRENT* entry  in the  timeline (with some  soft color---a  shade of
> blue or green would be nice).

You mean like this:

fossil time | sed -e 's/\*CURRENT\*/^[[0;32m&^[[0;m/'

Where ^[ is an escape character.

Andy
-- 
TAI64 timestamp: 4000560d414a


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

Re: [fossil-users] Suggestion for command-line timeline display

[Andy Bradford]

Thus said "Tony Papadimitriou" on Thu, 01 Oct 2015 19:19:55 +0300:

> 1. highlight the whole entry, not just the word *CURRENT*, and

fossil time | sed -e '/\*CURRENT\*/ { s/.*/^[[1;32m&^[[0;m/ }'

I don't know  how to detect the  current foreground color so  if you can
figure that out, you can put it in there instead of green.

> 2. it should also work without ANSI escape sequence under Windows console.

Someone using Windows will have to do this.

The point  is, fossil output  can be wrapped in  any tool that  makes it
prettier for your eyes.

Andy
--
TAI64 timestamp: 4000560d68a8
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for command-line timeline display

[Tony Papadimitriou]

I didn't actually try it but from what it looks like, yes, almost, BUT

1. highlight the whole entry, not just the word *CURRENT*, and
2. it should also work without ANSI escape sequence under Windows console.

Also, the best 'color' would probably be just bold print to make it stand 
out from the rest.


-Original Message- 
From: Andy Bradford 
Sent: Thursday, October 01, 2015 5:20 PM 
To: Tony Papadimitriou 
Cc: Fossil SCM user's discussion 
Subject: Re: [fossil-users] Suggestion for command-line timeline display 


Thus said "Tony Papadimitriou" on Thu, 01 Oct 2015 15:29:05 +0300:


I  was wondering  if the  same  idea could  be used  to highlight  the
*CURRENT* entry  in the  timeline (with some  soft color---a  shade of
blue or green would be nice).


You mean like this:

fossil time | sed -e 's/\*CURRENT\*/^[[0;32m&^[[0;m/'

Where ^[ is an escape character.

Andy
--
TAI64 timestamp: 4000560d414a

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

Re: [fossil-users] Suggestion for command-line timeline display

[Barry Arthur]

My favourite tool for this sort of thing is supercat:
http://supercat.nosredna.net/
I don't know if it compiles on Windows.

On 2 October 2015 at 01:08, Andy Bradford  wrote:

> Thus said "Tony Papadimitriou" on Thu, 01 Oct 2015 19:19:55 +0300:
>
> > 1. highlight the whole entry, not just the word *CURRENT*, and
>
> fossil time | sed -e '/\*CURRENT\*/ { s/.*/^[[1;32m&^[[0;m/ }'
>
> I don't know  how to detect the  current foreground color so  if you can
> figure that out, you can put it in there instead of green.
>
> > 2. it should also work without ANSI escape sequence under Windows
> console.
>
> Someone using Windows will have to do this.
>
> The point  is, fossil output  can be wrapped in  any tool that  makes it
> prettier for your eyes.
>
> Andy
> --
> TAI64 timestamp: 4000560d68a8
> ___
> 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] Suggestion: new TH1 command 'dir' similar to cli 'ls'

[Stephan Beal]

On Mon, Aug 10, 2015 at 6:05 PM, Chris ckolum...@ac-drexler.de wrote:

 I had the need for a very simple blog-like page within the embedded doc
 functionality where a th1 page (with enabled th1-doc feature) displays a
 list with  links to all documents within a specific folder. Whenever a
 new file gets added to the folder the script will automatically pick
 it up and display a link to it.


Who can complain about feature requests with patches :).


 In addition I added 'index.th1' to the automatically searched index files
 if
 TH1-DOC are enabled during compile time.


+1


 The code can be reviewed at
 https://server.ac-drexler.de/fossil/fossil/ci/adcc95e64d?sbs=1

 Please let me know if you think that could be helpful for a wider
 audience  and/or if you have improvement ideas.


 Thanks for this cool piece of software and for any feedback you
 might have :-)



We (unfortunately) can't copy/paste it as-is without a copyright waiver on
file:

http://www.fossil-scm.org/index.html/doc/trunk/www/copyright-release.html

but if you can get that filled out and mailed to Richard, we can integrate
it. Alternately, someone who has a waiver on file might take your idea and
re-implement it.


Gruss aus Muenchen,

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But 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] Suggestion: new TH1 command 'dir' similar to cli 'ls'

[Chris ckolumbus]

Hi Stephan,

thanks for the Feedback :-)

On Tue, 11 Aug 2015 08:43:28 +0200
Stephan Beal sgb...@googlemail.com wrote:

 On Mon, Aug 10, 2015 at 6:05 PM, Chris ckolum...@ac-drexler.de
 wrote:
   
  I had the need for a very simple blog-like page within the embedded
  [...]  
 
 Who can complain about feature requests with patches :).  

That's what i hoped for ;-)

 We (unfortunately) can't copy/paste it as-is without a copyright
 waiver on file:  

Waiver is already waiting, just wanted to check with the ML before on
whether the idea/code is OK. I'll send it out today.

Greetings from Frankonia,
Chris


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

[fossil-users] Suggestion: new TH1 command 'dir' similar to cli 'ls'

[Chris]

Dear ML members,

I had the need for a very simple blog-like page within the embedded doc
functionality where a th1 page (with enabled th1-doc feature) displays a
list with  links to all documents within a specific folder. Whenever a
new file gets added to the folder the script will automatically pick
it up and display a link to it.

In addition I added 'index.th1' to the automatically searched index files if
TH1-DOC are enabled during compile time.

Another use case would be to auto generate some kind of sitemap with a
glob mask of e.g. index.md providing links to index.md files in all
subdirectories.

I've added the Readme describing the patch and a screen shot which shows
the example code and output.

The code can be reviewed at
https://server.ac-drexler.de/fossil/fossil/ci/adcc95e64d?sbs=1

Please let me know if you think that could be helpful for a wider
audience  and/or if you have improvement ideas.

Thanks for this cool piece of software and for any feedback you
might have :-)

Chris







# TH1 command: dir

## Help documentation

**TH1 command: dir CHECKIN ?GLOB?**

Returns a list containing all files in CHECKIN. If GLOB is given only the
files matching the pattern GLOB within CHECKIN will be returned.

## Problem

I wanted to have automated listing of documentation files so that there is
no need to manually update an index file when new files are added.

The idea was to provide a simple blog functionality. It should take a CHECKIN
and a GLOB and output a list with all filenames matching the glob on that
given checkin.

## Approach

I first analyzed the www command dir but later found that the cli command
ls already provides the needed functionality.

To stay closer with www interface I created a new TH1 command function
dirCmd in th\_main.c and also copied the ls\_cmd\_rev from checkin.c
as new function dir\_cmd\_rev.

Function calls were adjusted to use the appropriate th1\_\* versions and the
parameter handling was simplified by stripping out most of the original
options (reverse date sorting and extended output).

## Todo

* so far the GLOB cannot limited to one specific directory but all files in
  all sub-directories are listed as well. Maybe the use of LIKE instead of
  GLOB in the query could help.
* additional sorting options as in the original implementation could be
  added
* no test exist yet, not sure how to write proper test for such TH1 commands

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

Re: [fossil-users] [Suggestion] Branch descriptions

[Stephan Beal]

On Tue, Jan 6, 2015 at 6:41 AM, Matt Welland estifo...@gmail.com wrote:

 +1 IMHO this is a good idea. How technically feasible it is I have no idea.


 agreed. AFAIK, branches currently do not use the VALUE part of the tag.
Perhaps such a description could be set there when making a branch, e.g.:


fossil commit -b new-branch -d branch description -m commit message

That would require no incompatible changes (provided i'm correct about
branch tags not having a value).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But 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] [Suggestion] Branch descriptions

[Ron W]

On Tue, Jan 6, 2015 at 4:04 AM, Stephan Beal sgb...@googlemail.com wrote:


  agreed. AFAIK, branches currently do not use the VALUE part of the tag.
 Perhaps such a description could be set there when making a branch, e.g.:


 fossil commit -b new-branch -d branch description -m commit message

 That would require no incompatible changes (provided i'm correct about
 branch tags not having a value).


Looking at Fossil's time line, branches appear to have 2 propagating tags:

 branch=name
 sym-name

The sym- one not having a value. Strange to me that 2 tags would be used
(I would have thought only the branch tag), but looks like the sym- tag
could be used to hold a branch description.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Suggestion] Branch descriptions

[Richard Hipp]

On 1/6/15, Ron W ronw.m...@gmail.com wrote:
 On Tue, Jan 6, 2015 at 4:04 AM, Stephan Beal sgb...@googlemail.com wrote:


  agreed. AFAIK, branches currently do not use the VALUE part of the tag.
 Perhaps such a description could be set there when making a branch, e.g.:


 fossil commit -b new-branch -d branch description -m commit message

 That would require no incompatible changes (provided i'm correct about
 branch tags not having a value).


 Looking at Fossil's time line, branches appear to have 2 propagating tags:

  branch=name
  sym-name

 The sym- one not having a value. Strange to me that 2 tags would be used


The sym-name tag is there so that command like fossil update trunk
will be able to resolve the name trunk to be the most recent
check-in with the sym-trunk tag, which is also the latest trunk
check-in.

-- 
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] [Suggestion] Branch descriptions

[Ron W]

On Tue, Jan 6, 2015 at 11:50 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jan 6, 2015 at 5:12 PM, Ron W ronw.m...@gmail.com wrote:

 The sym- one not having a value. Strange to me that 2 tags would be
 used (I would have thought only the branch tag), but looks like the
 sym- tag could be used to hold a branch description.


 One downside: this precludes modifying the description without yet another
 tag applied to amend it. Similar to the comment tag, but a comment tag is
 cached in the 'event' table (ecomment field), so it's not expensive to
 calculate later on. It sounds like this change would need a similar place
 to store the most recent description.


In that case, a possible alternative would be a simple way to display
(including amendments) the comment from the branch's first commit (as that
seems to be a common convention for describing a branch).
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Suggestion] Branch descriptions

[Stephan Beal]

On Tue, Jan 6, 2015 at 5:12 PM, Ron W ronw.m...@gmail.com wrote:

 The sym- one not having a value. Strange to me that 2 tags would be used
 (I would have thought only the branch tag), but looks like the sym- tag
 could be used to hold a branch description.


One downside: this precludes modifying the description without yet another
tag applied to amend it. Similar to the comment tag, but a comment tag is
cached in the 'event' table (ecomment field), so it's not expensive to
calculate later on. It sounds like this change would need a similar place
to store the most recent description.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But 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] [Suggestion] Branch descriptions

[Warren Young]

On Jan 4, 2015, at 10:55 AM, Philip Bennefall phi...@blastbay.com wrote:

 I don't know what a lot of the branches are and I have no obvious way of 
 finding out.

If it’s a temporary branch, e.g. to develop a risky feature before it gets into 
good enough shape that it can be committed to the trunk, you can just click on 
the branch name anywhere you see it, and get a list of the checkins made on 
that branch.  The first checkin’s comment should tell you why the branch was 
created.  You might have to click the “200 entries” link to see back to the 
first checkin on the branch.

If a branch has more than 200 entries, you could edit the URL (n=BIGNUM) but in 
that case, you’re probably dealing with a major branch.  The purpose of such 
branches should be obvious given the content of the repository.  (Stable 
release forks, for example.)

If you had a tree big and complex enough that these things were not clear from 
context, you could add a “Navigation” wiki article.  You’d probably want such a 
thing regardless, for such a complex project.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Suggestion] Branch descriptions

[Matt Welland]

+1 IMHO this is a good idea. How technically feasible it is I have no idea.
On Jan 4, 2015 10:59 AM, Philip Bennefall phi...@blastbay.com wrote:

 Hi all,

 I have a quick suggestion to present. While browsing the SqLite timeline,
 it struck me that I don't know what a lot of the branches are and I have no
 obvious way of finding out. I was thinking that it might be nice to be able
 to specify an optional description for a given branch. The branch names
 themselves are obviously meant to be kept relatively short (and without
 spaces presumably), so I think the descriptions would be a nice addition.
 Any thoughts?

 Kind regards,

 Philip Bennefall
 ___
 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] [Suggestion] Branch descriptions

[Philip Bennefall]

Hi all,

I have a quick suggestion to present. While browsing the SqLite 
timeline, it struck me that I don't know what a lot of the branches are 
and I have no obvious way of finding out. I was thinking that it might 
be nice to be able to specify an optional description for a given 
branch. The branch names themselves are obviously meant to be kept 
relatively short (and without spaces presumably), so I think the 
descriptions would be a nice addition. Any thoughts?


Kind regards,

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

[fossil-users] Suggestion for win/Makefile.msc

[Tony Papadimitriou]

Chances are when you use FOSSIL_BUILD_SSL you also want to enable SSL.
So, to avoid having to give both FOSSIL_BUILD_SSL and FOSSIL_ENABLE_SSL on the
make command line, I propose something like this change in the win/Makefile.msc:

--- OLD ---
# Uncomment to enable SSL support
# FOSSIL_ENABLE_SSL = 1

# Uncomment to build SSL libraries
# FOSSIL_BUILD_SSL = 1

--- NEW ---

# Uncomment to build SSL libraries
# FOSSIL_BUILD_SSL = 1

# Uncomment to enable SSL support
# FOSSIL_ENABLE_SSL = 1

!ifdef FOSSIL_BUILD_SSL
!ifndef FOSSIL_ENABLE_SSL
FOSSIL_ENABLE_SSL = 1
!endif
!endif

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

Re: [fossil-users] Suggestion for cloning

[Baruch Burstein]

On Tue, Jul 29, 2014 at 5:10 AM, Andy Bradford amb-fos...@bradfords.org
wrote:

  When  cloning a  repository, if  I  don't have  write privileges,  can
  autosync by  default be  set to  pullonly in  the clone,  to prevent
  annoying pull only - not authorized to push?

 Are you suggesting that the clone detect whether or not the account used
 has  write privileges  and  then automatically  enable the  ``pullonly''
 autosync setting?  Or simply to  have a way  to turn on  ``pullonly'' at
 clone time?


I was suggesting the first option. Maybe auto-sync can be one of the
settings that are cloned, and the server can send the correct value
(1/pullonly) depending on the permissions.


  Maybe  this  should be  the  default  always,  even  if I  have  write
  permission, in order to prevent accidental pushes?

 I believe  changing the default for  autosync in Fossl would  go against
 the general  preference (and I  suspect intentional design  decision) to
 minimize unintentional forks.


I think this may depend on the type of use. I had in mind open-source style
projects, where many people will be cloning and playing with their copy,
while most of them will never want/need to push back to the main
repository. I guess that in a company type usage, where just about every
clone will probably later be used to push, the current behavior may prevent
the occasional unintentional fork.

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for cloning

[Ron W]

On Mon, Jul 28, 2014 at 10:10 PM, Andy Bradford amb-fos...@bradfords.org
wrote:

 Thus said Baruch Burstein on Sun, 27 Jul 2014 23:31:17 +0300:
  Maybe  this  should be  the  default  always,  even  if I  have  write
  permission, in order to prevent accidental pushes?

 I believe  changing the default for  autosync in Fossl would  go against
 the general  preference (and I  suspect intentional design  decision) to
 minimize unintentional forks.


Making autosync default to pull-only would not impact minimize
unintentional forks. When autosync is on, the fossil commit first does a
pull from the remembered remote repo. Then the proposed commit is checked
against the freshly received updates to detect potential conflicts,
including forks. If there are no detectable potential conflicts, the commit
is done, then the push (assuming autosunc isn't pull-only AND the local
repo is not no-push).

As I undertand it, the rational for defaulting autosync to on is to
encourage its use. Given that, it makes sense to me that the repo being
cloned notify the cloner if she/he doesn't have write privilege, so will
not be able to push changes back.

Whether that notification results in automatically defaulting autosync (on
the receiving side) to pull-only is a corellary question. Personally, I
would prefer htat happen AND I get notified. At the very least, being
warned would remind me to set it to pull-only.

(Outside of work, the only projects I have push privilege for are my own.
All other projects I send either a patch or a pull request.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for cloning

[Andy Bradford]

Thus said Ron W on Tue, 29 Jul 2014 12:25:08 -0400:

 Making  autosync  default  to  pull-only  would  not  impact  minimize
 unintentional forks.

Actually, it would.  Consider this scenario.

Tizio clones and uses default autosync.
Caglio clones and enabled pull-only.
Tizio commits something.
Caglio commits, pull-only pulls in changes and merges, no fork yet.
Tizio commits something else.
Caglio commits again and this time decides to push afterward.  *FORK*

If this is not what you meant, I apologize.  Feel free to clarify.

Andy
--
TAI64 timestamp: 400053d7cfb8
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for cloning

[Stephan Beal]

On Tue, Jul 29, 2014 at 6:25 PM, Ron W ronw.m...@gmail.com wrote:

 the push (assuming autosunc isn't pull-only AND the local repo is not
 no-push).


i didn't know about that option (it's called dont-push, though)

   dont-pushPrevent this repository from pushing from client to
server.  Useful when setting up a private branch.


Maybe that offers a solution. i think Baruch's suggestion could be
implemented as:

- if the clone is done from a user with write permissions, behave as it
does now.
- if the cloning user has no write permissions, set dont-clone=1 in the
cloned repo.

i think that approach affects nobody's current use while providing the
enhancement Baruch is looking for?


:-?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But 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] Suggestion for cloning

[Ron W]

On Tue, Jul 29, 2014 at 12:46 PM, Stephan Beal sgb...@googlemail.com
wrote:

 On Tue, Jul 29, 2014 at 6:25 PM, Ron W ronw.m...@gmail.com wrote:

 the push (assuming autosunc isn't pull-only AND the local repo is not
 no-push).


 i didn't know about that option (it's called dont-push, though)

dont-pushPrevent this repository from pushing from client to
 server.  Useful when setting up a private branch.


That is a separate option from autosync. Autosync has 3 possible values:

   autosync   If enabled, automatically pull prior to commit or
update and
automatically push after commit or tag or
branch creation.
If the value is pullonly then only pull
operations occur automatically.
Default: on
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for cloning

[Andy Bradford]

Thus said Baruch Burstein on Sun, 27 Jul 2014 23:31:17 +0300:

 When  cloning a  repository, if  I  don't have  write privileges,  can
 autosync by  default be  set to  pullonly in  the clone,  to prevent
 annoying pull only - not authorized to push?

Are you suggesting that the clone detect whether or not the account used
has  write privileges  and  then automatically  enable the  ``pullonly''
autosync setting?  Or simply to  have a way  to turn on  ``pullonly'' at
clone time?

By the way, you can turn it on for all of your clones:

fossil settings --global autosync pullonly

 Maybe  this  should be  the  default  always,  even  if I  have  write
 permission, in order to prevent accidental pushes?

I believe  changing the default for  autosync in Fossl would  go against
the general  preference (and I  suspect intentional design  decision) to
minimize unintentional forks.

As I  mentioned above,  it can  be enabled  by default  for all  of your
projects with:

fossil settings --global autosync pullonly

Andy
-- 
TAI64 timestamp: 400053d702b6


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

[fossil-users] Suggestion for cloning

[Baruch Burstein]

When cloning a repository, if I don't have write privileges, can autosync
by default be set to pullonly in the clone, to prevent annoying pull
only - not authorized to push? Maybe this should be the default always,
even if I have write permission, in order to prevent accidental pushes?

-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion about fossil commit

[Chad Perrin]

On Mon, Apr 14, 2014 at 12:47:11PM -0400, Martin Gagnon wrote:
 Le 14 avr. 2014 11:48, Stephan Beal sgb...@googlemail.com a écrit :
 
  But, in my defense, (and I just re-read it to be sure I didn't miss
  it) nowhere in the help documentation (FOSSIL HELP COMMIT) or the
  comment in the editor (# Enter commit message for this check-in.
  Lines beginning with # are ignored.) does it say, or even imply,
  that an empty comment is one of the reasons that will 'abort' the
  commit.
 
  LOL!!!

 If i'm not mistaken, svn does the same thing (but i haven't got an svn
 with changes to try it out at the moment). Possibly even git - most
 SCMs do not like the users to enter empty commit messages.
 
 Even the famous CVS does the same...

s/famous/infamous/

-- 
Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] Suggestion about fossil commit

[B Harder]

That sounds like a bad idea to me. IMO, this is a case of good enough
getting in the way of good as far as solutions to your annoyance.

Off the top of my head, I can think of two workflow habits that may help
you:

1) set up/turn on gpg signing, so you'll be required to sign commits before
they're actually applied.
2) do not use -m, but let fossil through you into the default editor to
type your commit message interactively. There are interesting articles on
git commit messages that dovetails with this problem, too, which may add
even further value [0] [1]. Currently, by default, I think we're not really
setup to take advantage of the advice in the articles, but (to my mind) it
sounds like a great place to be, and getting there (directly via canonical
fossil, or libfossil or other tool) is really easy to imagine.

-bch

[0]
http://stackoverflow.com/questions/15324900/standard-to-follow-when-writing-git-commit-messages

[1] http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
On Apr 13, 2014 4:41 PM, Stanislav Paskalev ksh...@gmail.com wrote:

 Hi fossil-devs,
 I often reuse a console to work with fossil as well as something else
 (e.g. compile, run tests, etc)

 Due to my trigger-happy fingers I've had quite a few cases where
 I inadvertently ran fossil commit -m .. from history when in reality I
 wanted to run my tests for example.

 Fossil could compare the current message against the latest checkin in the
 active branch and warn if they match. If this sounds fine - I can make and
 send a patch :)

 Regards,
 Stanislav Paskalev

 ___
 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] Suggestion about fossil commit

[Tony Papadimitriou]

I often have the same problem for a different reason.  I type “f cha” and “f 
com” so often that sometime instead of “f cha” I accidentally type “f com”.

What I would like to have is an extra prompt, “Are you sure (y/N)?” with No 
default for commits.  Since commits are irreversible, I think the extra prompt 
to safeguard against typing accidents will be welcome by most users without 
adding too much burden to each commit.  Then again, it could also be activated 
via some setting so those who don’t want it can do without it.

Tony P.

From: Stanislav Paskalev 
Sent: Monday, April 14, 2014 2:41 AM
To: Fossil SCM user's discussion 
Subject: [fossil-users] Suggestion about fossil commit

Hi fossil-devs, 
I often reuse a console to work with fossil as well as something else (e.g. 
compile, run tests, etc)

Due to my trigger-happy fingers I've had quite a few cases where I 
inadvertently ran fossil commit -m .. from history when in reality I wanted 
to run my tests for example.

Fossil could compare the current message against the latest checkin in the 
active branch and warn if they match. If this sounds fine - I can make and send 
a patch :)

Regards,

Stanislav Paskalev



___
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] Suggestion about fossil commit

[Tony Papadimitriou]

WHAT?

Oh, this is embarrassing...

All this time I've been typing something (like the word 'ACCIDENT') in the 
editor thinking I have already started the commit process and I would 
complete the commit when I exit the editor, so I always typed something to 
know that this commit was a mistake.  I didn't know that typing nothing 
would cancel the operation.


But, in my defense, (and I just re-read it to be sure I didn't miss it) 
nowhere in the help documentation (FOSSIL HELP COMMIT) or the comment in the 
editor (# Enter commit message for this check-in. Lines beginning with # are 
ignored.) does it say, or even imply, that an empty comment is one of the 
reasons that will 'abort' the commit.


LOL!!!

Thanks.

-Original Message- 
From: Martin Gagnon

Sent: Monday, April 14, 2014 3:24 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Suggestion about fossil commit

On Mon, Apr 14, 2014 at 02:55:51PM +0300, Tony Papadimitriou wrote:
I often have the same problem for a different reason.  I type “f cha” and 
“f

com” so often that sometime instead of “f cha” I accidentally type “f com”.

What I would like to have is an extra prompt, “Are you sure (y/N)?” with 
No
default for commits.  Since commits are irreversible, I think the extra 
prompt
to safeguard against typing accidents will be welcome by most users 
without
adding too much burden to each commit.  Then again, it could also be 
activated

via some setting so those who don’t want it can do without it.



Since fossil commit start an editor and having empty commit message give
you a kind of Are you sure prompt already, how can you commit by
mistake when typing f com instead of f cha ?

It's not like you will type:   f com -m some text when you were about
to type f cha ...

Regards.

--
Martin G.
___
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] Suggestion about fossil commit

[Stephan Beal]

On Mon, Apr 14, 2014 at 3:39 PM, Tony Papadimitriou to...@acm.org wrote:

 But, in my defense, (and I just re-read it to be sure I didn't miss it)
 nowhere in the help documentation (FOSSIL HELP COMMIT) or the comment in
 the editor (# Enter commit message for this check-in. Lines beginning with
 # are ignored.) does it say, or even imply, that an empty comment is one of
 the reasons that will 'abort' the commit.

 LOL!!!


If i'm not mistaken, svn does the same thing (but i haven't got an svn with
changes to try it out at the moment). Possibly even git - most SCMs do not
like the users to enter empty commit messages.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But 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] Suggestion about fossil commit

[Martin Gagnon]

Le 14 avr. 2014 11:48, Stephan Beal sgb...@googlemail.com a écrit :

 On Mon, Apr 14, 2014 at 3:39 PM, Tony Papadimitriou to...@acm.org wrote:

 But, in my defense, (and I just re-read it to be sure I didn't miss it)
nowhere in the help documentation (FOSSIL HELP COMMIT) or the comment in
the editor (# Enter commit message for this check-in. Lines beginning with
# are ignored.) does it say, or even imply, that an empty comment is one of
the reasons that will 'abort' the commit.

 LOL!!!


 If i'm not mistaken, svn does the same thing (but i haven't got an svn
with changes to try it out at the moment). Possibly even git - most SCMs do
not like the users to enter empty commit messages.

Even the famous CVS does the same...

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

Re: [fossil-users] Suggestion about fossil commit

[B Harder]

On 4/14/14, Martin Gagnon eme...@gmail.com wrote:
 Le 14 avr. 2014 11:48, Stephan Beal sgb...@googlemail.com a écrit :

 On Mon, Apr 14, 2014 at 3:39 PM, Tony Papadimitriou to...@acm.org
 wrote:

 But, in my defense, (and I just re-read it to be sure I didn't miss it)
 nowhere in the help documentation (FOSSIL HELP COMMIT) or the comment in
 the editor (# Enter commit message for this check-in. Lines beginning with
 # are ignored.) does it say, or even imply, that an empty comment is one of
 the reasons that will 'abort' the commit.

 LOL!!!


 If i'm not mistaken, svn does the same thing (but i haven't got an svn
 with changes to try it out at the moment). Possibly even git - most SCMs do
 not like the users to enter empty commit messages.

 Even the famous CVS does the same...

Our users shouldn't need CVS, SVN, etc experience to know this. I
added documentation to clarify.

 --
 Martin G.



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion about fossil commit

[David Given]

On 4/14/14, 9:31 PM, B Harder wrote:
[...]
 Our users shouldn't need CVS, SVN, etc experience to know this. I
 added documentation to clarify.

It might also be useful to add:

# (To abort the commit, leave this file unchanged)

...to the commit message, too.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│
│ You cannot truly appreciate _Atlas Shrugged_ until you have read it
│ in the original Klingon. --- Sea Wasp on r.a.sf.w



signature.asc
Description: OpenPGP digital 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] Suggestion about fossil commit

[B Harder]

On 4/14/14, David Given d...@cowlark.com wrote:
 On 4/14/14, 9:31 PM, B Harder wrote:
 [...]
 Our users shouldn't need CVS, SVN, etc experience to know this. I
 added documentation to clarify.

 It might also be useful to add:

 # (To abort the commit, leave this file unchanged)

 ...to the commit message, too.

+1, done.

New_Version: 0484ccf2e9335e2f4c9914afabe7d66c28b0be99

-- 
Brad Harder
Method Logic Digital Consulting
http://twitter.com/bcharder
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion about fossil commit

[Andy Bradford]

Thus said David Given on Mon, 14 Apr 2014 22:28:07 +0100:

 It might also be useful to add:
 
 # (To abort the commit, leave this file unchanged)

I was about  to point out that  this wouldn't be a good  idea when using
merge  --cherrypick  because  it  actually  automatically  includes  the
original commit message from the checkin, but apparently Fossil is smart
enough to  figure out that even  with an uncommented line  in the commit
message, it  still treats it  as an empty  message unless you  alter it!
Impressive.

Andy
-- 
TAI64 timestamp: 4000534caa33


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

Re: [fossil-users] Suggestion about fossil commit

[Andy Bradford]

Thus said Andy Bradford on Mon, 14 Apr 2014 21:40:00 -0600:

 ... but apparently Fossil is smart enough to figure out that even with
 an uncommented  line in the commit  message, it still treats  it as an
 empty message unless you alter it!

Correction, unchanged, not empty.

Andy
-- 
TAI64 timestamp: 4000534caa95


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

[fossil-users] Suggestion about fossil commit

[Stanislav Paskalev]

Hi fossil-devs,
I often reuse a console to work with fossil as well as something else (e.g.
compile, run tests, etc)

Due to my trigger-happy fingers I've had quite a few cases where
I inadvertently ran fossil commit -m .. from history when in reality I
wanted to run my tests for example.

Fossil could compare the current message against the latest checkin in the
active branch and warn if they match. If this sounds fine - I can make and
send a patch :)

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

Re: [fossil-users] Suggestion about fossil commit

[Joe Knapka]

This might better be handled with an alias or wrapper script.

#!/bin/bash
read -p You just ran fossil $@ ; are you sure?   yn
case $yn in
  [Yy]* ) /usr/bin/fossil $@ ;;
  [Nn]* ) echo Whew! Dodged a bullet there! ;;
esac

Elaborated to suit.

- JK

On Sun, Apr 13, 2014 at 5:41 PM, Stanislav Paskalev ksh...@gmail.com wrote:
 Hi fossil-devs,
 I often reuse a console to work with fossil as well as something else (e.g.
 compile, run tests, etc)

 Due to my trigger-happy fingers I've had quite a few cases where I
 inadvertently ran fossil commit -m .. from history when in reality I
 wanted to run my tests for example.

 Fossil could compare the current message against the latest checkin in the
 active branch and warn if they match. If this sounds fine - I can make and
 send a patch :)

 Regards,
 Stanislav Paskalev

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




-- 
It is always best to think of reality as perfectly normal.  Since the
beginning, not one unusual thing has ever happened. - Less Wrong
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] suggestion

[Joan Picanyol i Puig]

* Richard Hipp d...@sqlite.org [20121120 01:13]:
 On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff 
 veedeeh...@googlemail.comwrote:
 
  -- fossil timeline: I find this really hard to read and use for at least
  two reasons:
 
 
 I seldom use fossil timeline, preferring instead to run fossil ui and
 look at the timeline with the graph in my web-browser.  Am I the only one
 that thinks this way?

Well, I use fossil in many places where I can't easily use fossil ui
(no graphic environment). Even when if available, I tend to use it only
because I've yet ito find out how to quickly go from fossil timeline to
let me see how file F changed in changeset C in the command line.

I'd suggest an option to include more vertical space, even if it breaks
the current one-line-per-commit paradigm. Also, an option as in hg log
--patch -r 123 (show me the patch corresponding to that version)

 
 
  -- the `fossil diff --from rev1 --to rev2' syntax deviates from the much
  more common (and easier to type `-r rev1:rev2') for no good reason I can
  see.
 
 
 You think that -r rev1:rev2 is more intuitive than --from rev1 --to
 rev2?  Really?  If it's important, we could add it as alternative syntax,
 I suppose.  But what would you do if the name of rev1 contained an embedded
 colon?  Do we have to invent some kind of escape syntax to accompany this
 notation?

No more intuitive, but shorter and more standard. Instead of an escape
syntax, I understand that forbidding ':' from branch names would
suffice?

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

Re: [fossil-users] suggestion

[Martin Gagnon]

Le 2012-11-20 à 04:58, Joan Picanyol i Puig lists-fos...@biaix.org a écrit :

 * Richard Hipp d...@sqlite.org [20121120 01:13]:
 On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff 
 veedeeh...@googlemail.comwrote:
 
 -- fossil timeline: I find this really hard to read and use for at least
 two reasons:
 
 I seldom use fossil timeline, preferring instead to run fossil ui and
 look at the timeline with the graph in my web-browser.  Am I the only one
 that thinks this way?
 
 Well, I use fossil in many places where I can't easily use fossil ui
 (no graphic environment). Even when if available, I tend to use it only
 because I've yet ito find out how to quickly go from fossil timeline to
 let me see how file F changed in changeset C in the command line.
 
 I'd suggest an option to include more vertical space, even if it breaks
 the current one-line-per-commit paradigm. Also, an option as in hg log
 --patch -r 123 (show me the patch corresponding to that version)
 
 
 
 -- the `fossil diff --from rev1 --to rev2' syntax deviates from the much
 more common (and easier to type `-r rev1:rev2') for no good reason I can
 see.
 
 You think that -r rev1:rev2 is more intuitive than --from rev1 --to
 rev2?  Really?  If it's important, we could add it as alternative syntax,
 I suppose.  But what would you do if the name of rev1 contained an embedded
 colon?  Do we have to invent some kind of escape syntax to accompany this
 notation?
 
 No more intuitive, but shorter and more standard. Instead of an escape
 syntax, I understand that forbidding ':' from branch names would
 suffice?
 

Or CVS style:
$ cvs diff -r rev1 -r rev2

And if specified once. It's against current version on disk.

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

Re: [fossil-users] suggestion

[Mike Meyer]

On Mon, Nov 19, 2012 at 6:13 PM, Richard Hipp d...@sqlite.org wrote:
 On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff veedeeh...@googlemail.com
 mostly I would like to get information here whether there are changes
 (edits, adds, removals...) or not and what files are not tracked.
 `hg stat' does provide that. in fossil I have to do `fossil changes' _and_
 `fossil extras'.
[...]
 Maybe we could invent a system whereby a user could create their own fossil
 commands to suite their own tastes?  So you could define a site-specific
 fossil stat command that simply runs changes and extras in succession.
 Would that help?

Mercurial has a couple of such features, and they are useful. The
reason there are a couple (and the reason I bring it up) is that they
learned the hard way that letting users override standard commands
breaks scripts. So either a script command (that defines and
executes such scripts), making the above fossil script stat, or make
sure that builtin commands are checked first, and possibly warn about
defining commands that are shadowed by builtins.

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

Re: [fossil-users] suggestion

[j. van den hoff]

On Tue, 20 Nov 2012 00:53:04 +0100, Themba Fletcher  
themba.fletc...@gmail.com wrote:



On Mon, Nov 19, 2012 at 3:46 PM, Themba Fletcher
themba.fletc...@gmail.com wrote:

On Mon, Nov 19, 2012 at 3:12 PM, j. v. d. hoff
veedeeh...@googlemail.com wrote:


On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org  
wrote:


On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff  
veedeeh...@googlemail.comwrote:



hi there,

a modest suggestion:
snip


-- there seems no easy way to get a list of ignored files (as per the  
`fsl set ignore-glob' setting.
in most cases I find that this setting should be part of the global  
state of the project. in `hg'
there is a default file `.hgignore' where the glob patterns can be  
put. I find this most useful since
in this way the ignore patterns can (but need not) be made part of the  
project state that is transfered

to the other side.



This should help:
http://www.fossil-scm.org/index.html/doc/trunk/www/settings.wiki



Grrr. sorry for the rtfm -- I meant to add more here but hit send  
instead


At the very bottom of the page you'll find a general discussion about
versionable settings and specific reference to the
.fossil-settings/ignore-glob file, which is exactly what you're
looking for I believe.


thank you very much for this hint. I was not aware of this facility and,  
yes, it's essentially what
I was looking for regarding making the ignore-glob settings an intrinsic  
property of the project.


joerg




Themba


 snip



I'd like to emphazise: this sure is not a complaint but just  
expression of my opinion that the UI (and in turn adoption of  
`fossil') might profit from some changes.
and I'd like to learn what the community thinks of these issues. are  
all of them irrelavant?




Fossil was the first VCS that I used with any regularity. So, from
that point of view, I find when I'm working with bzr, git, and
particularly svn that they each seem really idiosyncratic and weird to
me. So there's *a* point of view, for what little it's worth.

I find fossil to be really scriptable, and over time I've either
scripted over the pain points, learned to accept them, or as often as
not learned to appreciate them. As a case in point, I too originally
found the chattiness of the autosync cycle to be kind of irritating.
Over time, however, I've found it provides a bit of peace of mind when
the network gets slow or something else happens (unexpectedly large
repo?) and I can clearly see that fossil's still doing or trying to do
something. Compare git, where you just type git clone and wait, never
knowing if you fat fingered the url or if you're slowly filling your
drive with 40G of nonsense...

Best regards,

Themba



j.







regards,
joerg

--
Using Opera's revolutionary email client: http://www.opera.com/mail/
__**_
fossil-users mailing list
fossil-users@lists.fossil-scm.**org  
fossil-users@lists.fossil-scm.org

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








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



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

[j. van den hoff]

On Tue, 20 Nov 2012 01:13:51 +0100, Richard Hipp d...@sqlite.org wrote:

On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff  
veedeeh...@googlemail.comwrote:




some more remarks from a new user:
I've been trying out fossil only for the last two weeks or so. and  
coming

from `mercurial'
(and knowing `subversion' to some extent) I find the user interface  
quite

idiosyncratic in places (such an impression was not caused when first
using mercurial, e.g.):



Constructive feedback is always appreciated.  Thank you!

User feedback is enormously important, and I do pay close attention to  
it.
And Fossil has been greatly improved as a result of user feedback.   
Perhaps

the most striking example of this is the change graph on the web timeline
that was suggested by Andreas Kupries - I probably would not have thought
of that on my own, and yet now I don't see how I ever survived without  
it.


That said, please also recognize that I wrote Fossil because the other
VCSes out there (or that were out there 7 years ago) did not meet my
needs.  And so one should not expect Fossil to be just like all the
others.  Fossil works how I want a VCS to work.  If you find Fossil  
useful
as well, that's cool tool, and I am happy to make reasonable  
accommodations

for differing tastes.  Even so, one should not expect Fossil to be like
every other DVCS.  That would defeat the purpose, no?


sure right and that's definitely not my attitude.







-- the sparse `fossil set' output I've mentioned already.

-- `fossil stat, changes, info, extras': of course, there is no
requirement to mimic `hg', `svn' or what else but
the signal to noise ratio for the average user is quite low in my  
view.

`stat' and `info' seem
to differ only by the mostly irrelvant `project-name' entry while both
reporting full lenghts
SHA1 codes which mostly seem not to be needed here (well, I did not, up  
to

now...).



stat is (mostly) a combination of changes and info.




mostly I would like to get information here whether there are changes
(edits, adds, removals...) or not and what files are not tracked.
`hg stat' does provide that. in fossil I have to do `fossil changes'  
_and_

`fossil extras'.



That would not work well with my workflows, since I tend to keep lots of
extraneous unmanaged files laying around, and I do not use ignore-glob.


well, I do heavily so.


So
it would never occur to me to have a command that shows both changes to
managed files and lists unmanaged files, all at the same time.  In my
check-outs, such a command is likely to drown the user in a list of
unmanaged files that is so huge that it obscures the changes to managed
files.


on the contrary I find this very useful from my experience with `hg':
first thing I do when putting some dir/procject under revision control, is  
set up the ignore-glob list (e.g. *.o or

all the auxiliary files generated by `pdflatex'). than I do `fossil add .'.
if in the course of the project new files are created but I forget to  
explicitely
`add' them I do get a notification from `hg stat', listing untracked (not  
the ignored!),
added, removed, modified files. from this list it's easy to decide whether  
untracked
files have to be `add'ed or whether the ignore-glob pattern has to be  
extended.


so, in a workflow where one _does_ make extended use of ignore-glob, such  
a listing will
never be long. it only will be (as in your case, if, e.g. the *.o files  
are simply untracked,
but not ignored. I hope you can see my point. since such a listing  
obiously collides
with your own workflow: how about a long or comprehensive option for  
`changes' (which seems
the neares equivalent to `hg stat') to make it put out the combined list  
of changed (!) tracked

files and (not-ignored!) untracked files?





Maybe we could invent a system whereby a user could create their own  
fossil

commands to suite their own tastes?  So you could define a site-specific
fossil stat command that simply runs changes and extras in
succession.  Would that help?


yes, I would something like that. this approach indeed works very well in  
`hg' in my view.
(potential problems with overriding intrinsic commands have been  
mentionend in this thread

already, but should be manageable in my view).






-- there seems no easy way to get a list of ignored files (as per the  
`fsl

set ignore-glob' setting.
in most cases I find that this setting should be part of the global
state of the project. in `hg'
there is a default file `.hgignore' where the glob patterns can be put.  
I

find this most useful since
in this way the ignore patterns can (but need not) be made part of the
project state that is transfered
to the other side.

-- fossil timeline: I find this really hard to read and use for at least
two reasons:



I seldom use fossil timeline, preferring instead to run fossil ui and
look at the timeline with the graph in my web-browser.  Am I the only one
that thinks this way?


I am sure you are not the only one 

[fossil-users] suggestion

[j. v. d. hoff]

hi there,

a modest suggestion:

I would prefer (and I believe it actually would be more correct, thought  
what's correct is always arguable)
if `fossil set' would explicitly report not only explicitly set (local)  
and (global) parameters but also the
default values (whose values I tend to only partly memorize...). so  
filling in all the empty fields a la


autosync (default) on

would be better, I believe. any opinions on that?

regards,
joerg

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

[Richard Hipp]

On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:

 hi there,

 a modest suggestion:

 I would prefer (and I believe it actually would be more correct, thought
 what's correct is always arguable)
 if `fossil set' would explicitly report not only explicitly set (local)
 and (global) parameters but also the
 default values (whose values I tend to only partly memorize...). so
 filling in all the empty fields a la

 autosync (default) on

 would be better, I believe. any opinions on that?


I don't know about the user interface, but I've been thinking for a long
time that the internal C APIs for settings need to be fixed to make use of
a single global table of default values, rather than depending each setting
query to specify the default value.




 regards,
 joerg

 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/
 __**_
 fossil-users mailing list
 fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] suggestion

[j. v. d. hoff]

On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org wrote:

On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff  
veedeeh...@googlemail.comwrote:



hi there,

a modest suggestion:

I would prefer (and I believe it actually would be more correct, thought
what's correct is always arguable)
if `fossil set' would explicitly report not only explicitly set (local)
and (global) parameters but also the
default values (whose values I tend to only partly memorize...). so
filling in all the empty fields a la

autosync (default) on

would be better, I believe. any opinions on that?



I don't know about the user interface, but I've been thinking for a long
time that the internal C APIs for settings need to be fixed to make use  
of
a single global table of default values, rather than depending each  
setting

query to specify the default value.


I understand that you are maybe more concerned about the software  
engineering
aspect and if I get the meaning of your mail right: yes that would be  
better.


but switching back to a simple user perspective: why not report the  
default settings
(at least optionally: I realize that the `fsl set' report would no longer  
allow to
easily identify the (few?) explicit settings if all defaults are reported  
but I'm not sure

if that really would be an issue)?

some more remarks from a new user:
I've been trying out fossil only for the last two weeks or so. and coming  
from `mercurial'

(and knowing `subversion' to some extent) I find the user interface quite
idiosyncratic in places (such an impression was not caused when first  
using mercurial, e.g.):


-- the sparse `fossil set' output I've mentioned already.

-- `fossil stat, changes, info, extras': of course, there is no  
requirement to mimic `hg', `svn' or what else but
the signal to noise ratio for the average user is quite low in my view.  
`stat' and `info' seem
to differ only by the mostly irrelvant `project-name' entry while both  
reporting full lenghts
SHA1 codes which mostly seem not to be needed here (well, I did not, up to  
now...).


mostly I would like to get information here whether there are changes  
(edits, adds, removals...) or not and what files are not tracked.
`hg stat' does provide that. in fossil I have to do `fossil changes' _and_  
`fossil extras'.


-- there seems no easy way to get a list of ignored files (as per the `fsl  
set ignore-glob' setting.
in most cases I find that this setting should be part of the global  
state of the project. in `hg'
there is a default file `.hgignore' where the glob patterns can be put. I  
find this most useful since
in this way the ignore patterns can (but need not) be made part of the  
project state that is transfered

to the other side.

-- fossil timeline: I find this really hard to read and use for at least  
two reasons:
   * the forced line breaks in the commit messages: would it not be better  
to let the terminal to line wrapping if need be? than I could keep the  
commit messages mostly on a single line

 if I prefer this by increasing the terminal width.
   * updating/merging etc. requires leading unique (at least 4) characters  
from the SHA1 hashes. the `hg' approach to allow (of course only locally  
vaild) incremental revision numbers as an alternative is much nicer in my  
view.


-- the `fossil diff --from rev1 --to rev2' syntax deviates from the much  
more common (and easier to type `-r rev1:rev2') for no good reason I can  
see.


-- the command line parser needs some getting used to and seems to have  
some quirks. e.g., commands accept unique abbreviations as being valid,  
but options do not.
   at least `fossil timeline -showfiles' does not: `fossil time -show'  
does nothing...). there are some more over which I stumbled but I don't  
recall right now
   (except that spaces are enforced even after short options but again:  
matter of taste).


-- rather frequent typos in the help pages (reports of those are desirable  
or not?)


-- the transfer statistics stuff reported at every checkin. usually I  
don't want to see this. maybe this should be made configurable (or is it  
already?) in the UI.



I'd like to emphazise: this sure is not a complaint but just expression of  
my opinion that the UI (and in turn adoption of `fossil') might profit  
from some changes.
and I'd like to learn what the community thinks of these issues. are all  
of them irrelavant?


j.







regards,
joerg

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








--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list

Re: [fossil-users] suggestion

[Themba Fletcher]

On Mon, Nov 19, 2012 at 3:12 PM, j. v. d. hoff
veedeeh...@googlemail.com wrote:

 On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org wrote:

 On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff 
 veedeeh...@googlemail.comwrote:

 hi there,

 a modest suggestion:
 snip

 -- there seems no easy way to get a list of ignored files (as per the `fsl 
 set ignore-glob' setting.
 in most cases I find that this setting should be part of the global state 
 of the project. in `hg'
 there is a default file `.hgignore' where the glob patterns can be put. I 
 find this most useful since
 in this way the ignore patterns can (but need not) be made part of the 
 project state that is transfered
 to the other side.


This should help:
http://www.fossil-scm.org/index.html/doc/trunk/www/settings.wiki

 snip


 I'd like to emphazise: this sure is not a complaint but just expression of my 
 opinion that the UI (and in turn adoption of `fossil') might profit from some 
 changes.
 and I'd like to learn what the community thinks of these issues. are all of 
 them irrelavant?


Fossil was the first VCS that I used with any regularity. So, from
that point of view, I find when I'm working with bzr, git, and
particularly svn that they each seem really idiosyncratic and weird to
me. So there's *a* point of view, for what little it's worth.

I find fossil to be really scriptable, and over time I've either
scripted over the pain points, learned to accept them, or as often as
not learned to appreciate them. As a case in point, I too originally
found the chattiness of the autosync cycle to be kind of irritating.
Over time, however, I've found it provides a bit of peace of mind when
the network gets slow or something else happens (unexpectedly large
repo?) and I can clearly see that fossil's still doing or trying to do
something. Compare git, where you just type git clone and wait, never
knowing if you fat fingered the url or if you're slowly filling your
drive with 40G of nonsense...

Best regards,

Themba


 j.





 regards,
 joerg

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






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

[Themba Fletcher]

On Mon, Nov 19, 2012 at 3:46 PM, Themba Fletcher
themba.fletc...@gmail.com wrote:
 On Mon, Nov 19, 2012 at 3:12 PM, j. v. d. hoff
 veedeeh...@googlemail.com wrote:

 On Mon, 19 Nov 2012 22:49:22 +0100, Richard Hipp d...@sqlite.org wrote:

 On Mon, Nov 19, 2012 at 4:30 PM, j. v. d. hoff 
 veedeeh...@googlemail.comwrote:

 hi there,

 a modest suggestion:
 snip

 -- there seems no easy way to get a list of ignored files (as per the `fsl 
 set ignore-glob' setting.
 in most cases I find that this setting should be part of the global state 
 of the project. in `hg'
 there is a default file `.hgignore' where the glob patterns can be put. I 
 find this most useful since
 in this way the ignore patterns can (but need not) be made part of the 
 project state that is transfered
 to the other side.


 This should help:
 http://www.fossil-scm.org/index.html/doc/trunk/www/settings.wiki


Grrr. sorry for the rtfm -- I meant to add more here but hit send instead

At the very bottom of the page you'll find a general discussion about
versionable settings and specific reference to the
.fossil-settings/ignore-glob file, which is exactly what you're
looking for I believe.

Themba

  snip


 I'd like to emphazise: this sure is not a complaint but just expression of 
 my opinion that the UI (and in turn adoption of `fossil') might profit from 
 some changes.
 and I'd like to learn what the community thinks of these issues. are all of 
 them irrelavant?


 Fossil was the first VCS that I used with any regularity. So, from
 that point of view, I find when I'm working with bzr, git, and
 particularly svn that they each seem really idiosyncratic and weird to
 me. So there's *a* point of view, for what little it's worth.

 I find fossil to be really scriptable, and over time I've either
 scripted over the pain points, learned to accept them, or as often as
 not learned to appreciate them. As a case in point, I too originally
 found the chattiness of the autosync cycle to be kind of irritating.
 Over time, however, I've found it provides a bit of peace of mind when
 the network gets slow or something else happens (unexpectedly large
 repo?) and I can clearly see that fossil's still doing or trying to do
 something. Compare git, where you just type git clone and wait, never
 knowing if you fat fingered the url or if you're slowly filling your
 drive with 40G of nonsense...

 Best regards,

 Themba


 j.





 regards,
 joerg

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






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

[Richard Hipp]

On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:


 some more remarks from a new user:
 I've been trying out fossil only for the last two weeks or so. and coming
 from `mercurial'
 (and knowing `subversion' to some extent) I find the user interface quite
 idiosyncratic in places (such an impression was not caused when first
 using mercurial, e.g.):


Constructive feedback is always appreciated.  Thank you!

User feedback is enormously important, and I do pay close attention to it.
And Fossil has been greatly improved as a result of user feedback.  Perhaps
the most striking example of this is the change graph on the web timeline
that was suggested by Andreas Kupries - I probably would not have thought
of that on my own, and yet now I don't see how I ever survived without it.

That said, please also recognize that I wrote Fossil because the other
VCSes out there (or that were out there 7 years ago) did not meet my
needs.  And so one should not expect Fossil to be just like all the
others.  Fossil works how I want a VCS to work.  If you find Fossil useful
as well, that's cool tool, and I am happy to make reasonable accommodations
for differing tastes.  Even so, one should not expect Fossil to be like
every other DVCS.  That would defeat the purpose, no?




 -- the sparse `fossil set' output I've mentioned already.

 -- `fossil stat, changes, info, extras': of course, there is no
 requirement to mimic `hg', `svn' or what else but
 the signal to noise ratio for the average user is quite low in my view.
 `stat' and `info' seem
 to differ only by the mostly irrelvant `project-name' entry while both
 reporting full lenghts
 SHA1 codes which mostly seem not to be needed here (well, I did not, up to
 now...).


stat is (mostly) a combination of changes and info.



 mostly I would like to get information here whether there are changes
 (edits, adds, removals...) or not and what files are not tracked.
 `hg stat' does provide that. in fossil I have to do `fossil changes' _and_
 `fossil extras'.


That would not work well with my workflows, since I tend to keep lots of
extraneous unmanaged files laying around, and I do not use ignore-glob.  So
it would never occur to me to have a command that shows both changes to
managed files and lists unmanaged files, all at the same time.  In my
check-outs, such a command is likely to drown the user in a list of
unmanaged files that is so huge that it obscures the changes to managed
files.

Maybe we could invent a system whereby a user could create their own fossil
commands to suite their own tastes?  So you could define a site-specific
fossil stat command that simply runs changes and extras in
succession.  Would that help?



 -- there seems no easy way to get a list of ignored files (as per the `fsl
 set ignore-glob' setting.
 in most cases I find that this setting should be part of the global
 state of the project. in `hg'
 there is a default file `.hgignore' where the glob patterns can be put. I
 find this most useful since
 in this way the ignore patterns can (but need not) be made part of the
 project state that is transfered
 to the other side.

 -- fossil timeline: I find this really hard to read and use for at least
 two reasons:


I seldom use fossil timeline, preferring instead to run fossil ui and
look at the timeline with the graph in my web-browser.  Am I the only one
that thinks this way?



* the forced line breaks in the commit messages: would it not be better
 to let the terminal to line wrapping if need be? than I could keep the
 commit messages mostly on a single line
  if I prefer this by increasing the terminal width.
* updating/merging etc. requires leading unique (at least 4) characters
 from the SHA1 hashes. the `hg' approach to allow (of course only locally
 vaild) incremental revision numbers as an alternative is much nicer in my
 view.


I tend to use symbolic names.  Ex:  fossil up trunk;  fossil merge
experimental;



 -- the `fossil diff --from rev1 --to rev2' syntax deviates from the much
 more common (and easier to type `-r rev1:rev2') for no good reason I can
 see.


You think that -r rev1:rev2 is more intuitive than --from rev1 --to
rev2?  Really?  If it's important, we could add it as alternative syntax,
I suppose.  But what would you do if the name of rev1 contained an embedded
colon?  Do we have to invent some kind of escape syntax to accompany this
notation?



 -- the command line parser needs some getting used to and seems to have
 some quirks. e.g., commands accept unique abbreviations as being valid, but
 options do not.
at least `fossil timeline -showfiles' does not: `fossil time -show'
 does nothing...). there are some more over which I stumbled but I don't
 recall right now
(except that spaces are enforced even after short options but again:
 matter of taste).

 -- rather frequent typos in the help pages (reports of those are desirable
 or not?)


Typo reports are desirable.



 -- the 

Re: [fossil-users] suggestion

[Martin Gagnon]

Le 2012-11-19 à 19:13, Richard Hipp d...@sqlite.org a écrit :

 On Mon, Nov 19, 2012 at 6:12 PM, j. v. d. hoff veedeeh...@googlemail.com 
 wrote:
 

 snip

 -- the transfer statistics stuff reported at every checkin. usually I don't 
 want to see this. maybe this should be made configurable (or is it already?) 
 in the UI.
 
 We can consider an option to control this.
  

Or I suggest a version that refresh always the same line showing a kind of 
incrementing counter of 'cards' or bytes, so we can see there's activity 
without being too verbose.

  snip

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

Re: [fossil-users] suggestion

[Dirk Reiners]

On Mon, Nov 19, 2012 at 6:30 PM, Martin Gagnon eme...@gmail.com wrote:

 Or I suggest a version that refresh always the same line showing a kind of
 incrementing counter of 'cards' or bytes, so we can see there's activity
 without being too verbose.

... or something that doesn't start showing the statistics until 5 or
10 seconds (configurable?) into the transfer. So fast operations don't
spam, and slow ones give feedback.

Just my $.02

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

Re: [fossil-users] suggestion

[Richard Hipp]

On Mon, Nov 19, 2012 at 7:36 PM, Dirk Reiners dirk.rein...@gmail.comwrote:

 On Mon, Nov 19, 2012 at 6:30 PM, Martin Gagnon eme...@gmail.com wrote:
 
  Or I suggest a version that refresh always the same line showing a kind
 of
  incrementing counter of 'cards' or bytes, so we can see there's activity
  without being too verbose.

 ... or something that doesn't start showing the statistics until 5 or
 10 seconds (configurable?) into the transfer. So fast operations don't
 spam, and slow ones give feedback.

 Just my $.02


Please, yall, try this version (
http://www.fossil-scm.org/fossil/info/407cd4c534) and let me know if you
think the sync output is more reasonable.



Dirk
 ___
 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] suggestion

[Martin Gagnon]

On Mon, Nov 19, 2012 at 9:06 PM, Richard Hipp d...@sqlite.org wrote:



 On Mon, Nov 19, 2012 at 7:36 PM, Dirk Reiners dirk.rein...@gmail.comwrote:

 On Mon, Nov 19, 2012 at 6:30 PM, Martin Gagnon eme...@gmail.com wrote:
 
  Or I suggest a version that refresh always the same line showing a kind
 of
  incrementing counter of 'cards' or bytes, so we can see there's activity
  without being too verbose.

 ... or something that doesn't start showing the statistics until 5 or
 10 seconds (configurable?) into the transfer. So fast operations don't
 spam, and slow ones give feedback.

 Just my $.02


 Please, yall, try this version (
 http://www.fossil-scm.org/fossil/info/407cd4c534) and let me know if you
 think the sync output is more reasonable.



Wow, that was fast...

Look very good for the test I did.

One thing I notice, when the sync is done on a fossil up with autosync
enabled, the --verbose will not affect the sync (it will do a verbose
update, as expected).  May be the verbose sync could have an option
configurable via fossil set, so it can be considered from any command
that does sync operation ...

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

[fossil-users] Suggestion: Ask for login when authorization fails

[Bernd Paysan]

One of our users complained that he couldn't check in something.  Well, it 
turned out that he had checked out the repository as anonymous. Fossil 
responds to that with

$ fossil push 
Server:http://fossil.forth-ev.de/vd-2012-04
Bytes  Cards  Artifacts Deltas
Sent:4730101  0  0
Error: not authorized to write
Received:  65  1  0  0
Total network traffic: 2759 bytes sent, 301 bytes received

The Error message is a bit burried between other, less relevant facts, and 
there's no obvious and intuitive way to log in.  IMHO, the most intuitive 
response is to respond with

Error: not authorized to write
Login: enter your user name here
Password: enter your password here

and then to retry.  That's how a lot of other interactive services do it.

-- 
Bernd Paysan
If you want it done right, you have to do it yourself
http://bernd-paysan.de/


signature.asc
Description: This is a digitally signed message part.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Suggestion for the 'ticket' command

[Wolfgang]

Ron Aaron r...@... writes:

 
 
 Is there a reason why it has to be in a valid fossil checkout?
 
 It would be convenient if it were possible to specify -R my.fossil, as can
be done with a number of other commands.
 

I added the -R option to the ticket command.

Wolfgang



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

[fossil-users] Suggestion for the 'ticket' command

[Ron Aaron]

Is there a reason why it has to be in a valid fossil checkout?

It would be convenient if it were possible to specify -R my.fossil, as can 
be done with a number of other commands.

-- 
For privacy, my GPG key signature is: AD29415D
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users