On Mon, 07 Dec 2009 15:16:50 +, you wrote:
Hello,
I am looking at the source and see that enumerated lists are defined by:
1. Hello
2. Goodbye
i.e. a two spaces, a number, a period, two spaces, text.
Why was it decided to use that syntax instead of the common # syntax? This
means
Will,
On Wed, Dec 9, 2009 at 12:11 AM, Will Duquette w...@wjduquette.com wrote:
I click on one of your links, and found myself at your fossil repo,
logged in as
btheado with full access to the Admin settings. Eeek!
Hmm. I noticed that shortly after I sent the email. I couldn't even
logout.
Hi,
Three things keep catching me with Fossil. Am I being stupid and
missing something? If not, I'd like to propose them as areas for
enhancement.
1) I'd like to be able to delete a folder. I think Fossil doesn't
track folder, which is fine – if I say:
fossil rm folder_name
… I'd
Michael Richter wrote:
I don't get it. We never had to number the list ourselves.
What was wrong with :
Numbered list
0 Number one
0 Number two
0 Number three
It gives you a list that looks like:
0. Number one
0. Number two
0. Number three
That's
Kees Nuyt k.n...@zonnet.nl wrote:
I don't get it. We never had to number the list ourselves.
What was wrong with :
Numbered list
0 Number one
0 Number two
0 Number three
Nothing, except it's not documented anywhere or readily noticable in the code.
I must have skipped right
2009/12/9 chi ml-fos...@qiao.in-berlin.de
I don't get it. We never had to number the list ourselves.
What was wrong with :
Numbered list
0 Number one
0 Number two
0 Number three
It gives you a list that looks like:
0. Number one
0. Number
Kees Nuyt k.n...@zonnet.nl wrote:
I don't get it. We never had to number the list ourselves.
What was wrong with :
Numbered list
0 Number one
0 Number two
0 Number three
With this new information, value=0 only working on IE and the value=
attribute being depreciated, I
Michael Richter ttmrich...@gmail.com wrote:
Ahhh ... in my Fossil wiki it gives me:
1. Number one
2. Number two
3. Number three
Try for yourself in the Fossil wiki's sandbox ...
I did before I posted.
But pay attention: Every number enclosed in *two* Blanks!
Yes, I
On Wed, 9 Dec 2009 18:56:13 +0800, you wrote:
I don't get it. We never had to number the list ourselves.
What was wrong with :
Numbered list
0 Number one
0 Number two
0 Number three
It gives you a list that looks like:
0. Number one
0. Number two
0. Number three
No, it doesn't
Kees Nuyt k.n...@zonnet.nl wrote:
Using
Google Chrome browser v3.0.195.33 and
Internet Explorer 8.0.6001.18865.
But indeed, Firefox v3.5.5 shows the zeroes!
You can download:
http://api.browsershots.org/screenshots/091209-075848-jeremy.cowgar.com-4005547.zip
and see the results in
On Wed, Dec 09, 2009 at 10:40:21PM +0800, Michael Richter wrote:
2009/12/9 Wilson, Ronald [1]rwils...@harris.com
2) This is a bit wooly, but sometimes I'd like to be able to do
something like:
� � � fossil rm file_name.*
... when these files don't exists on
Michael fos...@autosys.us wrote:
I find myself having removed files sometimes for which I have not
yet done 'fossil rm'. I do not have any missing files right now
so I cannot double check the following, but I think this is what
works for me in those situations (GNU/Linux) ...
$
2009/12/9 Wilson, Ronald rwils...@harris.com
2) This is a bit wooly, but sometimes I'd like to be able to do
something like:
fossil rm file_name.*
... when these files don't exists on disk, because I've deleted them
already. So I want some way to do a delete glob on what fossil
On Wed, 2009-12-09 at 09:00 -0800, Michael wrote:
I think this is what works for me in those situations (GNU/Linux) ...
$ for arg in $( fossil ls | egrep ^MISSING | awk '{print $2}' ) ;
do
fossil rm ${arg} ;
done
This was the command Michal Richter gave me a while ago when I
On Wed, Dec 09, 2009 at 12:19:19PM -0500, Joshua Paine wrote:
On Wed, 2009-12-09 at 09:00 -0800, Michael wrote:
I think this is what works for me in those situations (GNU/Linux) ...
$ for arg in $( fossil ls | egrep ^MISSING | awk '{print $2}' ) ;
do
fossil rm ${arg} ;
In the 3 features... thread, I read from Michael:
Secondly, I always get bit with my commit failing and then
having to type in my comment again (after the monkeying around
with 'fossil rm').
It seems that fossil is in need of two things:
1. Save the commit message to a file when the
Andreas Kupries andre...@activestate.com wrote:
Michael wrote:
Attached a few helper functions (bash) I use when working with fossil ...
Mostly to shorten the command line
I wonder if it wouldn't be helpful to provide a fossil config option for file
based operations. i.e. it would allow
On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com wrote:
It seems that fossil is in need of two things:
1. Save the commit message to a file when the commit failed
2. Provide a means of making fossil read the commit message from a file
If you're having to re-*type* your commit
On Wed, Dec 9, 2009 at 11:55 AM, Brian Theado brian.the...@gmail.comwrote:
Will,Hmm. I noticed that shortly after I sent the email. I couldn't even
logout.
i noticed a similar problem a couple days ago - it is impossible to log out
when connecting to a local fossil server over the localhost
Stephan Beal sgb...@googlemail.com wrote:
IMO, duplicating the shell functionality is the wrong approach, mainly
because there will be behavioural differences between fossil's and the
shell's globbing. i agree it would be convenient for us users, but it
technically could not be guaranteed to
In another discussion, I read:
i noticed a similar problem a couple days ago - it is impossible to log out
when connecting to a local fossil server over the localhost IP. i wanted to
test the anonymous captcha filler and had to log in over the IP my NIC gets
from my WLAN router in order to be
On Wed, 2009-12-09 at 19:49 +, Jeremy Cowgar wrote:
If it were a config option
What kind of config option are we talking about here? This isn't the
sort of thing that makes sense to be per-project or per-repo. If I want
`fossil rm` to delete files too, I want it all the time.
It could be an
On Wed, Dec 9, 2009 at 8:58 PM, Jeremy Cowgar jer...@cowgar.com wrote:
I tend to write lengthy (even formatting with the wiki syntax) commit
messages. Thus, I usually type at the prompt:
$ fossil commit
Which triggers fossil into launching my prefered editor to edit the commit
message.
Joshua Paine jos...@letterblock.com wrote:
On Wed, 2009-12-09 at 19:49 +, Jeremy Cowgar wrote:
If it were a config option
What kind of config option are we talking about here? This isn't the
sort of thing that makes sense to be per-project or per-repo. If I want
`fossil rm` to delete
On Dec 9, 2009, at 11:39 AM, Stephan Beal wrote:
IMO, duplicating the shell functionality is the wrong approach,
mainly because there will be behavioural differences between
fossil's and the shell's globbing. i agree it would be convenient
for us users, but it technically could not be
On Wed, Dec 9, 2009 at 10:09 PM, Jeremy Cowgar jer...@cowgar.com wrote:
I'd like to see the option be defaulted to on and then for that one in a
million time when you don't actually want to remove the file, you can
override it via the command line.
i would recommend the flag name --keep for
Stephan Beal sgb...@googlemail.com wrote:
Theoretically (i haven't tried it) you could use a workaround like this:
a) Put your commit in a file, e.g. msg.txt.
b) type:
EDITOR=cat msg.txt fossil commit foo.c
whether or not that works depends largely on how the EDITOR arg is passed on
On Dec 9, 2009, at 11:41 AM, Stephan Beal wrote:
On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com
wrote:
It seems that fossil is in need of two things:
1. Save the commit message to a file when the commit failed
2. Provide a means of making fossil read the commit message
Stephan Beal sgb...@googlemail.com wrote:
On Wed, Dec 9, 2009 at 10:09 PM, Jeremy Cowgar jer...@cowgar.com wrote:
I'd like to see the option be defaulted to on and then for that one in a
million time when you don't actually want to remove the file, you can
override it via the command
On Dec 9, 2009, at 12:39 PM, Jeremy Cowgar wrote:
In the 3 features... thread, I read from Michael:
Secondly, I always get bit with my commit failing and then
having to type in my comment again (after the monkeying around
with 'fossil rm').
It seems that fossil is in need of two things:
On Wed, Dec 9, 2009 at 10:21 PM, Jeremy Cowgar jer...@cowgar.com wrote:
It then does a system call something like: nano unique-filename.txt
Right, then a 'cat' kludge won't help. :/
So, fossil already writes/reads from a commit message, it just doesn't
expose the functionality to the user.
On Dec 9, 2009, at 1:29 PM, D. Richard Hipp wrote:
On Dec 9, 2009, at 12:39 PM, Jeremy Cowgar wrote:
In the 3 features... thread, I read from Michael:
Secondly, I always get bit with my commit failing and then
having to type in my comment again (after the monkeying around
with 'fossil
D. Richard Hipp d...@hwaci.com wrote:
It seems to me that a better approach would be to improve the commit
command so that it does a better job of detecting problems *before* it
asks you to type in the commit message. In other words, if the commit
is going to fail, have it fail early.
On Wed, 2009-12-09 at 22:22 +0100, Stephan Beal wrote:
That said, presumably when you rm a file, it already exists in the
repo, and the chance of a significant loss due to an unwanted unlink()
on the file seems to be small.
But the function that the current method provides is one that's
On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com wrote:
It seems that fossil is in need of two things:
1. Save the commit message to a file when the commit failed
2. Provide a means of making fossil read the commit message from a file
i've just added -M/--comment-file which
Stephan Beal sgb...@googlemail.com wrote:
On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com wrote:
It seems that fossil is in need of two things:
1. Save the commit message to a file when the commit failed
2. Provide a means of making fossil read the commit message from a
D. Richard Hipp d...@hwaci.com wrote:
On Dec 9, 2009, at 5:00 PM, Stephan Beal wrote:
On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com
wrote:
It seems that fossil is in need of two things:
1. Save the commit message to a file when the commit failed
2. Provide a
On Wed, Dec 9, 2009 at 11:04 PM, D. Richard Hipp d...@hwaci.com wrote:
On Dec 9, 2009, at 5:00 PM, Stephan Beal wrote:
i've just added -M/--comment-file which does #2. If there are no
objections to using -M/--comment-file for this, i will commit it.
I was looking into storing the commit
You can `fossil update` and then `fossil undo`.
I knew this one, but I would prefer an option that did not change the
files on disk. You know, things sometimes fail, and they can fail in
the middle of the operation.
This is specially true for a GUI tool that uses fossil and wants to
show to the
that -M filename is also a useful choice. Regarding the bloat factor: the
diff for -M is only a few lines of real code. i've pasted it below, but
In my opinion, the decision should not be based on the added
complexity to the code (we programmers can deal with complexity, can't
we?), but with
One of the thinks that I most dislike of other VCS is the excess of
options. Too many options means to much time reading the manuals and
to much time remembering the possibilities of the tool.
Fossil is very good at it. It has the minimum set of options to make the
tool useful.
In my
I was looking into storing the commit comment in the local _FOSSIL_
database and automatically reinitializing the commit message to the
old comment on the second attempt to commit after the first attempt
failed. In other words, make it fully automatic. Check back tomorrow
and see if I don't
... because it means more users. More users = better
testing. Better testing = less problems for you and I.
Sure? And the pleasure of using an elite tool, far away from the masses?
Compass Ing. y Sistemas Dr. Ramon Ribo
http://www.compassis.com ram...@compassis.com
c/
On Thu, Dec 10, 2009 at 12:48 AM, Wilson, Ronald rwils...@harris.comwrote:
I like DRH's idea but I agree with others that a --comment-file|-M
feature is needed for integration applications. However, I think
--comment-file could be less verbose and -M is begging for caps-lock
confusion. I
That makes three of us who've made this request. I asked for a fossil
-n (for -nochange, like cvs), which did everything an update did,
except for changing any files on disk. I had two related options that
were useful:
-v (or -verbose) to print even files that have not changed UNCHANGED
i apologize to all - i didn't mean to open up a can of worms. i'll wait on
DRH's vote/veto,
and commit (or not). If i do, i'll change it to --infile/-i unless there are
strong objections.
For those of you who want it now, the diff is in one of the previous posts.
No apology is ever
I have fossil version [732d7c406e] 2009-11-25 22:14:11 UTC. In the
older versions when I viewed a checkin page from the timeline, it listed the
changed files and viewing the diff on that file was a further click. Now it
shows the diff in-line on the checkin page. Is there a switch
Stephan Beal sgb...@googlemail.com wrote:
On Thu, Dec 10, 2009 at 12:48 AM, Wilson, Ronald rwils...@harris.comwrote:
I like DRH's idea but I agree with others that a --comment-file|-M
feature is needed for integration applications. However, I think
--comment-file could be less verbose
Synopsis:
I am trying to use a CGI/1.1 webserver to serve fossil repositories.
The pages do not display properly. Via 'view source' from the
browser, I see the extra word index inserted into paths.
---
Long version:
Per the synopsis, fossil pages are not display properly
with the
49 matches
Mail list logo
