Re: [fossil-users] Numbered list syntax?
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 that if I have a list of ten things and want to add in an item after position 4, I have to reorder the entire list. In the fossil docs for the rationale of the wiki markup, I read: The wiki markup used by fossil, though limited, is common to most other wiki engines, is intuitive, and is sufficient for 90% of all formatting tasks. I've used a lot of wiki's and have not seen the numbered list syntax of above and it does not seem intuitive either. I made the change to fossil to support # Hello # Goodbye can I commit the change drh? The 1. Hello 2. Goodbye syntax is intact and unchanged. 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 -- ( Kees Nuyt ) c[_] ___ 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] user(), cgi(), wiki() report functions
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. All I did was upload my fossil database and create the two line cgi script. I seem to remember some emails in this list about creating a repo in one place and getting it installed somewhere else. Later I can read those and see if it helps me figure out my mistake. If anyone else knows what is going on, please let me know. In the meantime, the database file is and has been readonly (to the cgi script user), so any modification attempts sa me will fail. I don't think it is possible to securely run fossil in read/write mode on sourceforge. I would need to make the repo file writable by the webuser and anyone who is a member of any sourceforge project can run a script as the webuser. Plus, it seems that fossil stores all passwords in plain text, so anyone with sourceforge access can read those. Thanks for pointing it out. Brian ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] 3 Feature requests – globbing u sing the repository.
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 like it to be taken to mean that I want all files under those folders to be removed. 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 has in its repo, not what is on disk. 3) I often type: fossil revert file_name.* … but only one of the matching files gets reverted, which is a bummer if I have edited the .c and .h files, say. 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] Numbered list syntax?
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 not really a numbered list, now, is it? 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 ... But pay attention: Every number enclosed in *two* Blanks! Ciao, chi. ___ 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] Numbered list syntax?
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 over it! In the wiki_rules, I see: Enumeration Lists. An enumeration list item is a line that begins with one or more digits optionally followed by a . and is surrounded on both sides by two or more spaces or by a tab. The number is significant and becomes the number shown in the rendered enumeration item. Only a single level of enumeration list is supported by wiki. For nested enumerations or for enumerations that count using letters or roman numerials, use HTML. I do, however, by far prefer # over 0 as in many web browsers the default font of 0 looks like an O. Also, in keeping with the idea that The wiki markup used by fossil, though limited, is common to most other wiki engines, # is much more common, I've never run into using 0 before in a wiki system. People will intuitively use * and #. As proof, look at how many people never knew Fossil did numeric lists! Also, the purpose of a wiki is to make the text both human readable and able to be formatted by a computer at the same time. So, when reading a numbered list, compare these two items: John Doe had many pets as a child: 0 Dog 0 Cat 0 Fish 0 Rabbit 0 Horse or. John Doe had many pets as a child: # Dog # Cat # Fish # Rabbit # Horse Also, I wanted to make note that even in the fossil wiki where numeric lists are used, I see the syntax of: 1. Dog 2. Cat 3. Fish 4. which is the defined syntax. Jeremy ___ 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] Numbered list syntax?
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 two 0. Number three That's not really a numbered list, now, is it? 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 know this. I got a list of 0. (Note the period in my list there?) ___ 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] Numbered list syntax?
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 have committed the # list change to fossil. The old syntax is still intact and can be used if you like to order your own lists, however, I would highly suggest converting over to the new syntax of using # for your ordered lists. Jeremy ___ 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] Numbered list syntax?
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 know this. I got a list of 0. (Note the period in my list there?) It's not your syntax or fossil, it's the web browser. So far, it looks like only IE will turn value=0 into a numbered list. The rest give 0... but do not fear, I just committed the # list change. Jeremy ___ 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] Numbered list syntax?
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 in my version of fossil, [732d7c406e] 2009-11-25 22:14:11 , nor in the newest, [484c8f9f86] 2009-12-08 18:43:51 Using Google Chrome browser v3.0.195.33 and Internet Explorer 8.0.6001.18865. But indeed, Firefox v3.5.5 shows the zeroes! Fossil generates (edited for readability): pNumbered list !-- 0 0 0 case -- ol li value=0Number one/li li value=0Number two/li li value=0Number three/li /ol/p pNumbered list !-- 1 2 3 case -- ol li value=1Number one/li li value=2Number two/li li value=3Number three/li /ol/p That's not really a numbered list, now, is it? Indeed, I think we could even consider this an (understandable) bug. Ok, Jeremy has a point in adding a non-digit as a token for a automatically numbered list, and seeding the enumeration value only if an explicit digit is given. -- ( Kees Nuyt ) c[_] ___ 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] Numbered list syntax?
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 53 different browsers. IE, Avant, Safari and Chrome all show 1. 2. 3. The rest show 0. 0. 0. Further, all text based browsers I've found show 0 0 0. Ok, Jeremy has a point in adding a non-digit as a token for a automatically numbered list, and seeding the enumeration value only if an explicit digit is given. I committed the change, however, it does not seed anything. It just uses normal HTML syntax. For instance: # Red # Green # Blue is output as: ol liRed/li liGreen/li liBlue/li /ol The old syntax of: 12. Red 98. Green 3. Blue still exists and still outputs: ol li value=12Red/li li value=98Green/li li value=3Blue/li /ol Jeremy ___ 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] 3 Feature requests - globbing using the repository.
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 disk, because I've deleted
them
already. So I want some way to do a delete glob on what fossil has
in
its repo, not what is on disk.
I think the fossil team tries not to reproduce in fossil what can be
done in the shell. � I'm not a *nix guy so most of that is arcane to
me
because I don't use cygwin enough; but I think all three of your
enhancements are trivial to do in the shell.
I highlighted the key point that renders the shell bit a little
moot.� ;)
References
1. mailto:rwils...@harris.com
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) ...
$ for arg in $( fossil ls | egrep ^MISSING | awk '{print $2}' ) ;
do
fossil rm ${arg} ;
done
I usually run 'echo fossil rm ${arg}' first just to make sure
it looks good before I commit to the 'fossil rm'.
'fossil changes' probably works as well as the 'fossil ls'
~Michael
___
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] 3 Feature requests - globbing using the repository.
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) ...
$ for arg in $( fossil ls | egrep ^MISSING | awk '{print $2}' ) ;
do
fossil rm ${arg} ;
done
I usually run 'echo fossil rm ${arg}' first just to make sure
it looks good before I commit to the 'fossil rm'.
'fossil changes' probably works as well as the 'fossil ls'
One thing that we need to remember is that Fossil is cross platform and that
means, in our case, Windows, which has an inferior shell. Aside from that, I
wouldn't want to make someone learn awk just so they can use our SCM system.
There are many tricks that can be done but none should really be required for a
daily task.
Jeremy
___
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] 3 Feature requests - globbing using therepository.
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 has in its repo, not what is on disk. I think the fossil team tries not to reproduce in fossil what can be done in the shell. I'm not a *nix guy so most of that is arcane to me because I don't use cygwin enough; but I think all three of your enhancements are trivial to do in the shell. I highlighted the key point that renders the shell bit a little moot. ;) Actually, I think there was a thread about how to do that... and Jeremy has beat me to it. RW Ron Wilson, Engineering Project Lead (o) 434.455.6453, (m) 434.851.1612, www.harris.com HARRIS CORPORATION | RF Communications Division assuredcommunications™ ___ 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] 3 Feature requests - globbing using the repository.
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 was
trying to do the same thing.
fossil changes | grep ^MISSING | sed 's/^MISSING *//' | xargs fossil rm
I understand the above command, but sed and xargs are still not familiar
tools for me, so to use this means going out of my work flow to look it
up. (Not to mention it's really long!) And of course it won't work at
all on Windows.
I think the key missing feature is a fossil command to automatically
remove missing files, and perhaps a prompt to autoremove missing files
when commit complains about them.
--
Joshua Paine
LetterBlock: Web applications built with joy
http://letterblock.com/
301-576-1920
___
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] 3 Feature requests - globbing using the repository.
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} ;
done
This was the command Michal Richter gave me a while ago when I was
trying to do the same thing.
fossil changes | grep ^MISSING | sed 's/^MISSING *//' | xargs fossil rm
I understand the above command, but sed and xargs are still not familiar
tools for me, so to use this means going out of my work flow to look it
up. (Not to mention it's really long!) And of course it won't work at
all on Windows.
I think the key missing feature is a fossil command to automatically
remove missing files, and perhaps a prompt to autoremove missing files
when commit complains about them.
__
Agreed - I would prefer this feature as well, esp. the prompt.
Firstly, too much room for error with shell shenanigans.
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').
~Michael
--
Joshua Paine
LetterBlock: Web applications built with joy
http://letterblock.com/
301-576-1920
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Commit failing... retyping commit message
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 commit failed 2. Provide a means of making fossil read the commit message from a file i.e. $ fossil commit (enter your message in the editor that was loaded) ... ERROR ... ... Your commit message was saved to fossil-commit.a493bd8 ... $ # fix error $ fossil commit -cf fossil-commit.a493bd8 ... SUCCESS ... This would also make it easier to integrate into various editors/IDEs, i.e. being able to ask a commit message, save it to a file then call the appropriate fossil command. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
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 fossil rm, fossil mv to actually perform those actions on the file system as well, if enabled. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 message, you're using the wrong shell. All modern shells support up-arrow to scroll back through your command history. If you're in the Bash shell, try tapping Ctrl-R, then tap -m (the commit message argument), and the history will jump back to the most recent command with -m in it. Then just tap enter. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] user(), cgi(), wiki() report functions
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 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 able to log in and out. Any connections over localhost were automatically my admin account, and i couldn't log out. Were you perhaps logged in to your repo when you made it read-only? Perhaps fossil now cannot erase your login credentials? Try making it read/write, logging out, then making it read-only??? :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] 3 Feature requests - globbing using the repository.
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 behave the same as the user's shell, and therefore could cause confusion or even data loss (e.g. accidental removal or even purging by using an incompatible glob pattern). While I agree that we should not get into globbing and making the user do '*.c' I do think we should allow the option of making fossil mv and fossil rm actually move or remove the file. That is 'semi-shell' functionality added. Almost every single time I use fossil rm or fossil mv, I do: C:\Development\MyProject fossil rm abc.c DELETED abc.c C:\Development\MyProject del abc.c C:\Development\MyProject If it were a config option, then there wouldn't be troubles like this (I don't think). The user should be able to override the default option via a command line argument, maybe: $ fossil rm --no-action abc.c def.xyz $ fossil mv --no-action abc.d 123.789 Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Login/Logout while on localhost
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 able to log in and out. Any connections over localhost were automatically my admin account, and i couldn't log out. If you turn on the Require password for local access option found under AdminAccess, then you will be able to login/logout while connecting via localhost. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
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 environment variable, I guess, but I can't say I like that option either--it means remembering to set a fossil-specific env variable on every virtual private server I use. What about fossil rm --do foo.bar fossil mv --do foo.bar foo.baz or fossil rm --force foo.bar fossil mv --force foo.bar foo.baz ? -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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. Thus, many times there is no history in the command shell to get the commit message back. It's gone forever. 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 to the system (as a single arg via execvp() and friends or as part of a concated string passed to system()). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] 3 Feature requests - globbing using the repository.
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 files too, I want it all the time. It could be an environment variable, I guess, but I can't say I like that option either--it means remembering to set a fossil-specific env variable on every virtual private server I use. What about fossil rm --do foo.bar fossil mv --do foo.bar foo.baz or fossil rm --force foo.bar fossil mv --force foo.bar foo.baz I am thinking of a config option that is per repo, much like the Require password for local access, Automatically synchronize with repository or Sign all commits with GPG. Although it's the default behavior of many SCM systems, I'm afraid some will not like it all of a sudden removing their files when it never did before. 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. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
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 guaranteed to behave the same as the user's shell, and therefore could cause confusion or even data loss (e.g. accidental removal or even purging by using an incompatible glob pattern). Which is exactly why fossil rm *.foo should delete *.foo from the file system as well as from the repository. If you forget, and do rm *.foo, then you can ask fossil to give you the files back, and then do fossil rm *.foo so that you don't need to type in all of the names. Will -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] 3 Feature requests - globbing using the repository.
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 that. 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. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 to the system (as a single arg via execvp() and friends or as part of a concated string passed to system()). Hm, I just relized how your EDITOR= example works. That will not work with Fossil, as the way the EDITOR= variable works is: $ export EDITOR=nano $ fossil commit --- Here fossil see's that no message has been supplied on the command line so it generates a unique filename and then writes something like: # All text below this line will be ignored. # ADDED abc.xyz # DELETED def.123 # MODIFIED john.doe It then does a system call something like: nano unique-filename.txt You are then presented with the editor editing unique-filename.txt. You add your comment, quit the editor (saving of course) and fossil continues. If fossil sees that you have not added any content to the file (i.e. didn't save it), then it will say Empty commit message, continue? [yN]. So, fossil already writes/reads from a commit message, it just doesn't expose the functionality to the user. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 from a file If you're having to re-*type* your commit message, you're using the wrong shell. All modern shells support up-arrow to scroll back through your command history. If you're in the Bash shell, try tapping Ctrl-R, then tap -m (the commit message argument), and the history will jump back to the most recent command with -m in it. Then just tap enter. Unless you like to type long commit messages, and so do not use the -m option. -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ 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] 3 Feature requests - globbing using the repository.
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 line. i would recommend the flag name --keep for that. Yes, that's good, however, what about for mv ? I guess --keep would work as well and if you mv with a --keep, then it turns into a copy, as far as the file system is concerned. 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. :-? Yes. I am sure that we can do a check such as the one when calling revert. In this case it could be: remove file 'abc.txt'? this file has changed since last commit [yN]? So, the chances of loss go down further. Now, if no changes were made, then obviously no message would appear. We would then also have to provide a --force to both the mv and rm options so that a rm/mv could be scripted (not get the prompt). Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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: 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 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. What is it that is causing your commits to fail so frequently? What can we do to get fossil to detect these problems before you type in your commit message? i.e. $ fossil commit (enter your message in the editor that was loaded) ... ERROR ... ... Your commit message was saved to fossil-commit.a493bd8 ... $ # fix error $ fossil commit -cf fossil-commit.a493bd8 ... SUCCESS ... This would also make it easier to integrate into various editors/ IDEs, i.e. being able to ask a commit message, save it to a file then call the appropriate fossil command. Jeremy ___ 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...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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. IIRC, CVS and SVN leave a temp file if the commit fails. A clumsy workaround: in your editor, save without exiting, then save-as to a different name, then exit. fossil will pick up the first file and leave your new one intact. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 rm'). 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 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. What is it that is causing your commits to fail so frequently? What can we do to get fossil to detect these problems before you type in your commit message? What's bitten me a time or two is saying fossil commit, seeing the list of files, and then saying, Oh, rats, I forgot to do a fossil add, or I forgot to update a doc file. So I do it; and then fossil tells me that the checksum has changed (or something like that) and doesn't commit. This case comes up often enough that it would be nice if fossil allowed it to work, possibly with a confirmation from the user. -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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. Yes, that does make sense, but I believe the suggested functionality still has merit, especiallt for being able to script/integrate fossil into other products easily. i.e. reading a commit message from a file instead of on the command line. What is it that is causing your commits to fail so frequently? What can we do to get fossil to detect these problems before you type in your commit message? I'm not so sure that I have had commit's fail frequently. It has happened to me but I can't remember why. I was simply providing possible solutions to fix the retyping issue of the original author. I did spawn this thread from the 3 features request thread. Michael wrote: 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'). in: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01012.html Jeremy ___ 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] 3 Feature requests - globbing using the repository.
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 really needed sometimes. I.e., don't keep track of this file anymore. I like that that's convenient, too. So, for what little it's worth, I'd like fossil mv and fossil rm to really perform the file system operations by default, and let me access the current behavior with the --keep flag. If that's not acceptable, let them keep their current default function, but add a --do or --force flag to make them work on the filesystem, too. I agree with Jeremy's proposal to prompt before destroying work that hasn't been committed (and the consequent necessity of the --force option). -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 does #2. If there are no objections to using -M/--comment-file for this, i will commit it. Demo: step...@jareth:~/cvs/fossil/foo$ f=~/cvs/fossil/fossil/fossil step...@jareth:~/cvs/fossil/foo$ $f open ../foo.fsl step...@jareth:~/cvs/fossil/foo$ cp ../whalloc/*.[ch] . step...@jareth:~/cvs/fossil/foo$ $f add foo.c ADDED foo.c step...@jareth:~/cvs/fossil/foo$ echo Test of --comment-file msg step...@jareth:~/cvs/fossil/foo$ $f commit -M msg foo.c New_Version: 99721d647756507d922a4e0d8744e1573292987f step...@jareth:~/cvs/fossil/foo$ f time === 2009-12-09 === 21:56:39 [99721d6477] *CURRENT* Test of --comment-file (user: stephan tags: trunk) 21:55:32 [91a381e625] initial empty check-in (user: stephan tags: trunk) step...@jareth:~/cvs/fossil/foo$ echo '/*touch*/' foo.c step...@jareth:~/cvs/fossil/foo$ $f commit foo.c emacs /home/stephan/cvs/fossil/foo/ci-comment-12A6999BA351.txt New_Version: 3643c910cecf5e66340916637a9a546c08b6e93f step...@jareth:~/cvs/fossil/foo$ $f time === 2009-12-09 === 21:58:54 [3643c910ce] *CURRENT* edited message in $EDITOR (user: stephan tags: trunk) 21:56:39 [99721d6477] Test of --comment-file (user: stephan tags: trunk) 21:55:32 [91a381e625] initial empty check-in (user: stephan tags: trunk) -m trumps -M, and if neither are given it falls back to the $EDITOR. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 file 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 like this functionality and think it's very necessary for the ability to easily script fossil. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 means of making fossil read the commit message from a file 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 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 have something working I don't think that the -M/--comment-file really has much to do with a failing commit or the previous commit message. It would help with this problem, of course, but your solution is equally as well. The place that I really see -M/--comment-file working is with scripting and integration of fossil into 3rd party products. Many editors/IDE's provide the ability to commit from the editor. They will bring up a dialog or query the user in some manner, write the message to disk and call svn, cvs, hg or whatever withe the commit message file. We too should provide that option if we want to see fossil become more widely accepted. Now, on another note (a bit more personal to my work flow)... I will keep a file open in my editor that is changes. I'll document my changes in that file. Then, when I commit, I simply pass it on the command line. Thus, I never forget what I did between commits. Once I commit, I clear the file and start the process over again. On both accounts, the -M/--comment-file are necessary and a good idea, apart from the problem being discussed. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 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 have something working That's a very nice idea. i'll wait on news from you, then. i do agree with Jeremy's argument that the ability to specify an input file is probably important for general integration with scripts and other tools (e.g. the recently-posted emacs support). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 user what would happen in case of update. Would any user ever forgive the tool if it accidentally deleted one file in the course of its automatic operations? Compass Ing. y Sistemas Dr. Ramon Ribo http://www.compassis.com ram...@compassis.com c/ Tuset, 8 7-2 tel. +34 93 218 19 89 08006 Barcelona, Spainfax. +34 93 396 97 46 2009/12/9 Joshua Paine jos...@letterblock.com: On Wed, 2009-12-09 at 23:41 +0100, Ramon Ribó wrote: An option that I would like to see in fossil, as it is not easy to perform in fossil without changing any file is a way to know what an update would do without actually doing it. You can `fossil update` and then `fossil undo`. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 the added complexity for the final user. One more
option to read in the help, one more option to remember...
RR
2009/12/9 Stephan Beal sgb...@googlemail.com:
On Wed, Dec 9, 2009 at 11:41 PM, Ramon Ribó ram...@compassis.com wrote:
category. I do not see it useful for scripting or external tools, as
these tools can perfectly use the -m message option.
The -m option is not generically usable in scripts or makefiles because the
content might need extra escaping to accommodate embedded quotes, and that's
difficult (or at least troublesome) to handle properly in many scripting
environments. Whether escaping is needed or not would depend on whether the
script uses -m '...' or -m ..., newlines might need special treatment, and
it all gets hairy quickly.
i like the idea of storing the commit in _FOSSIL_, but Jeremy's convinced me
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 keep
in mind that most of the changes are in the docs, not the code:
step...@jareth:~/cvs/fossil/fossil$ f diff src/checkin.c
--- src/checkin.c
+++ src/checkin.c
@@ -388,15 +388,22 @@
**
** Usage: %fossil commit ?OPTIONS? ?FILE...?
**
** Create a new version containing all of the changes in the current
** checkout. You will be prompted to enter a check-in comment unless
-** the -m option is used to specify a comment line. You will be
-** prompted for your GPG passphrase in order to sign the new manifest
-** unless the --nosign options is used. All files that have
-** changed will be committed unless some subset of files is specified
-** on the command line.
+** one of the -m or -M options are used to specify a comment.
+** -m takes a single string for the commit message and -M requires
+** a filename from which to read the commit message. If neither -m
+** nor -M are specified then the editor defined in the editor
+** fossil option (see %fossil help set) will be used, or from the
+** VISUAL or EDITOR environment variables (in that order) if no
+** editor is set.
+**
+** You will be prompted for your GPG passphrase in order to sign the
+** new manifest unless the --nosign options is used. All files that
+** have changed will be committed unless some subset of files is
+** specified on the command line.
**
** The --branch option followed by a branch name cases the new check-in
** to be placed in the named branch. The --bgcolor option can be followed
** by a color name (ex: '#ffc0c0') to specify the background color of
** entries in the new branch when shown in the web timeline interface.
@@ -413,10 +420,11 @@
** --branch NEW-BRANCH-NAME
** --bgcolor COLOR
** --nosign
** --force|-f
** --private
+** --comment-file|-M COMMENT-FILE
**
*/
void commit_cmd(void){
int rc;
int vid, nrid, nvid;
@@ -432,10 +440,11 @@
int nBasename; /* Length of g.zLocalRoot/ */
const char *zBranch; /* Create a new branch with this name */
const char *zBgColor; /* Set background color when branching */
const char *zDateOvrd; /* Override date string */
const char *zUserOvrd; /* Override user name */
+ const char *zCommentFile; /* Read commit message from this file */
Blob filename; /* complete filename */
Blob manifest;
Blob muuid; /* Manifest uuid */
Blob mcksum; /* Self-checksum on the manifest */
Blob cksum1, cksum2; /* Before and after commit checksums */
@@ -445,10 +454,11 @@
noSign = find_option(nosign,0,0)!=0;
zComment = find_option(comment,m,1);
forceFlag = find_option(force, f, 0)!=0;
zBranch = find_option(branch,b,1);
zBgColor = find_option(bgcolor,0,1);
+ zCommentFile = find_option(comment-file, M, 1);
if( find_option(private,0,0) ){
g.markPrivate = 1;
if( zBranch==0 ) zBranch = private;
if( zBgColor==0 ) zBgColor = #fec084; /* Orange */
}
@@ -537,20 +547,23 @@
vfile_aggregate_checksum_disk(vid, cksum1);
if( zComment ){
blob_zero(comment);
blob_append(comment, zComment, -1);
+ }else if( zCommentFile ){
+ blob_zero(comment);
+ blob_read_from_file(comment, zCommentFile);
}else{
prepare_commit_comment(comment);
- if( blob_size(comment)==0 ){
- Blob ans;
- blob_zero(ans);
- prompt_user(empty check-in comment. continue [y/N]? , ans);
- if( blob_str(ans)[0]!='y' ){
- db_end_transaction(1);
- exit(1);
- }
+ }
+ if( blob_size(comment)==0 ){
+ Blob ans;
+ blob_zero(ans);
+ prompt_user(empty check-in comment. continue [y/N]? , ans);
[fossil-users] --dry-run (WAS Commit failing... retyping commit message)
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 opinion, fossil -M file commit falls clearly into this category. I do not see it useful for scripting or external tools, as these tools can perfectly use the -m message option. And for the casual user, DRH option of saving automatically the comment and inserting it in the new commit is much more clever. An option that I would like to see in fossil, as it is not easy to perform in fossil without changing any file is a way to know what an update would do without actually doing it. I see two ways of doing it: fossil --dry-run update or fossil changes ?version? In the last case, there should be an easy way of knowing which is the version to which fossil would update by default RR Sometimes I wish for such a feature also. I think the following syntax similar to pkzip would be clear: fossil commit --test fossil update --test etc. RW Ron Wilson, Engineering Project Lead (o) 434.455.6453, (m) 434.851.1612, www.harris.com HARRIS CORPORATION | RF Communications Division assuredcommunications(tm) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 have something working D. Richard Hipp d...@hwaci.com 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 suggest --infile|-i COMMENT-FILE-NAME. RW Ron Wilson, Engineering Project Lead (o) 434.455.6453, (m) 434.851.1612, www.harris.com HARRIS CORPORATION | RF Communications Division assuredcommunications(tm) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
... 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/ Tuset, 8 7-2 tel. +34 93 218 19 89 08006 Barcelona, Spainfax. +34 93 396 97 46 2009/12/10 Jeremy Cowgar jer...@cowgar.com: =?ISO-8859-1?Q?Ramon_Rib=F3?= ram...@compassis.com wrote: 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 the added complexity for the final user. One more option to read in the help, one more option to remember... and a whole lot of functionality. To me we shouldn't decide based on code complexity nor the number of options available but the necessity. -M is necessary for many tools to integrate with fossil and we do want more tools to integrate because it means more users. More users = better testing. Better testing = less problems for you and I. Another side effect is a larger number of users = a few more devs from that user bank, which starts the cycle all over again. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users tools to integrate because it means more users. More users = better testing. Better testing = less problems for you and I. Another side effect Compass Ing. y Sistemas Dr. Ramon Ribo http://www.compassis.com ram...@compassis.com c/ Tuset, 8 7-2 tel. +34 93 218 19 89 08006 Barcelona, Spainfax. +34 93 396 97 46 2009/12/10 Jeremy Cowgar jer...@cowgar.com: =?ISO-8859-1?Q?Ramon_Rib=F3?= ram...@compassis.com wrote: 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 the added complexity for the final user. One more option to read in the help, one more option to remember... and a whole lot of functionality. To me we shouldn't decide based on code complexity nor the number of options available but the necessity. -M is necessary for many tools to integrate with fossil and we do want more tools to integrate because it means more users. More users = better testing. Better testing = less problems for you and I. Another side effect is a larger number of users = a few more devs from that user bank, which starts the cycle all over again. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 suggest --infile|-i COMMENT-FILE-NAME. 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. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] --dry-run (WAS Commit failing... retyping commit message)
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 filename -l (or -local) to not do a remote pull before the run. I'm not married to the options or their sense (e.g. -r for -remote instead). This is required for sensible integration into emacs-23, and I have patches for this (+ a minor change to finfo.c). - Venkat ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 required for intelligent discourse. Ron Wilson, Engineering Project Lead (o) 434.455.6453, (m) 434.851.1612, www.harris.com HARRIS CORPORATION | RF Communications Division assuredcommunications(tm) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Checkin display: Does it have to show the file changes ?
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 or flag that I can change to go back to the old behavior and just list the files with a link to click to show the diff ? --jim schimpf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit failing... retyping commit message
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 and -M is begging for caps-lock confusion. I suggest --infile|-i COMMENT-FILE-NAME. 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. I personally would be confused looking at just an option list: fossil commit [-m|--message commit-message] [-i|--infile filename] [...] [file] Infile what? I wouldn't worry about --comment-file, it may seem a bit verbose but who's going to use that directly? tools for clarity, but for users, they would use -M (or whatever it winds up being). Actually, thinking about it, I'd keep both -M and --commit-file. If they mess up and type fossil commit -M Commit Message they will get an error: File 'Commit Message' could not be opened. Now, look at: fossil commit -m|--message commit-message] [-M|--message-file filename] [...] [file] It makes sense with no further help information. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [long] fossil html and CGI environment vars
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 webserver I am using. [FYI, httpd server included
in Erlang/OTP]
The script I am using, x.cgi, contains
#!/usr/local/bin/fossil
repository: /home/fossil/repositories/erlview.fossil.old
I have run the same script from a different webserver which
displays as expected.
I did a 'view source' from the browser in both cases.
The difference between the two generated html is that
for the incorrectly displayed page, all 'href' and 'img src'
links contain the word index between the script name and
the next word (e.g. style.css, home, logo, etc.).
e.g.
GOOD html
link rel=alternate type=application/rss+xml title=RSS Feed
href=https://delora.autosys.us/cgi/x.cgi/timeline.rss;
link rel=stylesheet href=https://delora.autosys.us/cgi/x.cgi/style.css;
type=text/css media=screen
BAD html
link rel=alternate type=application/rss+xml title=RSS Feed
href=http://delora.autosys.us:/cgi/x.cgi/index/timeline.rss;
link rel=stylesheet
href=http://delora.autosys.us:/cgi/x.cgi/index/style.css; type=text/css
media=screen
Of course, with the word index in there, the path for the style sheet
is incorrect hence the poorly displayed page. This is for the home
page. If I click on one of the links, then that name also gets
inserted into the path. So, where the proper path should have been
/cgi/x.cgi/brlist it would be /cgi/x.cgi/index/brlist
Here are the CGI environment variables created by the webserver for
which the BAD html is generated:
[{SERVER_SOFTWARE,inets/develop},
{SERVER_NAME,delora},
{GATEWAY_INTERFACE,CGI/1.1},
{SERVER_PROTOCOL,HTTP/1.1},
{SERVER_PORT,},
{REQUEST_METHOD,GET},
{REMOTE_ADDR,0:0:0:0:0::7F00:1},
{SCRIPT_NAME,/cgi/x.cgi},
{HTTP_HOST,delora.autosys.us:},
{HTTP_USER_AGENT,
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.15) Gecko/2009102815
Ubuntu/9.04 (jaunty) Firefox/3.0.15},
{HTTP_ACCEPT,
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8},
{HTTP_ACCEPT_LANGUAGE,en,es;q=0.8,en-us;q=0.5,es-es;q=0.3},
{HTTP_ACCEPT_ENCODING,gzip,deflate},
{HTTP_ACCEPT_CHARSET,ISO-8859-1,utf-8;q=0.7,*;q=0.7},
{HTTP_KEEP_ALIVE,300},
{HTTP_CONNECTION,keep-alive},
{QUERY_STRING,[]}]
Could it be the case that one of the above variables is causing fossil
to insert the spurious index (or tag names) in paths ? Or perhaps
there is a CGI variable missing ?
I have attached the 'view source' html files good.html and bad.html
in case anyone would like to see the entire files. They are from
the home page when first executing the x.cgi script.
I can change or add CGI environment variables to the webserver if
that is the solution.
Maybe I have uncovered an obscure bug in fossil.
Any suggestions (other than use a different webserver) are welcome.
~Michael
--
Michael McDaniel
Portland, Oregon, USA
http://trip.autosys.us
Title: Erlang view server: Erlang view server
Erlang view server
Erlang view server
Not logged in
Home Leaves Timeline Branches Tags Tickets Wiki Login
Global copy at http://github.com/mmcdanie/erlview
This is an Erlang view server for CouchDB, a document database.
fossil repos
Fossil version [083cad82ff] 2009-12-08 10:10:04
Title: Erlang view server: Erlang view server
Erlang view server
Erlang view server
Not logged in
Home Leaves Timeline Branches Tags Tickets Wiki Login
Global copy at http://github.com/mmcdanie/erlview
This is an Erlang view server for CouchDB, a document database.
fossil repos
Fossil version [083cad82ff] 2009-12-08 10:10:04
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
