Re: [fossil-users] Commit failing... retyping commit message
Hi Stephan, Please commit -M/--message-file changes v r waiting... - Altu -Original Message- From: Jeremy Cowgar To: fossil-users@lists.fossil-scm.org Sent: Fri, Dec 11, 2009 5:54 am Subject: Re: [fossil-users] Commit failing... retyping commit message 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.Where are we at with this? I've been looking forward to seeing a commit message :-DJeremy___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] user(), cgi(), wiki() report functions
On Wed, Dec 9, 2009 at 2:45 PM, Stephan Beal wrote: > 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??? Thanks for the guess, but that wasn't the issue. The output of this url: http://tkoutline.sourceforge.net/cgi-bin/fossil/test_env shows the REMOTE_ADDR env variable is being passed into fossil as 127.0.0.1. So it thought every connection was coming from localhost. I fixed it by enabling the setting that forces authentication even for localhost. Brian ___ 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 10, 2009, at 7:30 AM, Ramon Ribó wrote: >> If I then do >> >>rm *.foo >> >> when I meant to do >> >>fossil rm *.foo >> >> I can then do >> >>fossil update >> >> which will give me my *.foo files back. > > Are you sure that this command is going to give that files back? Have > you tried it? > > This is another field where there are currently proposals to change > current behavior and > do what you think that it does. The "principle of least surprise" is > not followed here. This is a proposal for how I think "fossil rm" should work. It's consistent with how "svn rm" works. At present it's not what happens. Will > > 2009/12/10 Will Duquette : >> I was unclear, apparently. >> >> Suppose "fossil rm *.foo" deletes the files from the file system and >> from Fossil. >> >> If I then do >> >>rm *.foo >> >> when I meant to do >> >>fossil rm *.foo >> >> I can then do >> >>fossil update >> >> which will give me my *.foo files back. Then, I can do >> >>fossil rm *.foo >> >> Note that I'd expect "fossil rm *.foo" only to remove files from the >> file system that it can remove from the repository, i.e., if I had an >> extra file, not_added.foo, I'd expect "fossil rm *.foo" to live it >> alone. >> >> Will >> >> On Dec 10, 2009, at 3:20 AM, Benjohn Barnes wrote: >> >>> >>> On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org >>> wrote: >>> 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 >>> >>> Although, I think, as you don't have any globbing, when you "ask >>> fossil to give you the files back", you do need to type in all the >>> names :-) (unless those deletions are the only changes that you've >>> made to the working copy). >>> >>> ___ >>> 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 >> > ___ > 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] Commit failing... retyping commit message
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. Where are we at with this? I've been looking forward to seeing a commit message :-D 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 4:45 PM, Joshua Paine wrote: > 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. > > [...] Re: --keep > 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. This is not consistent with svn --force (and so I think it will confuse people); svn does: Files (and directories that have not been committed) are immediately removed from the working copy. The command will not remove any unversioned or modified items; use the --force switch to override this behavior. In other words, svn always deletes locally unless there are uncommitted modifications. > I agree with Jeremy's proposal to prompt before destroying work that > hasn't been committed (and the consequent necessity of the --force > option). Right, this is what --force should do. It should not be required for locally deleting versioned and unmodified files. e ___ 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
> Hm, I just browsed the man pages of many VCS systems (CVS included) to find > examples of parameters for the message file. I had no problem locating their > pages, browsing the manual and finding them for 6 VCS systems in about 3 > minutes. > You must be cleverer than me ... or I felt my 3 minutes as long as 3 hours due to the non-pleasure nature of the task. > I *really* fail to see why an option like this should even be debated or why > one would deny a helpful feature to make our job easier just because there > are already 6 options, that as said, are very easy to get help on. I do not deny anything. In fact, I am not in the position of doing it, as someone else will take decisions about it, not me. I am just adding arguments to a fruitful debate. 2009/12/10 Jeremy Cowgar : > =?ISO-8859-1?Q?Ramon_Rib=F3?= wrote: >> > If there is an option that a user has no interest in using, why would >> > the user attempt to remember what it was? >> >> I recently had to read the cvs manual to find an option of one >> subcommand. I assure you that it was not a pleasant task to surf >> between the thousands of stupid options that cvs has gained with the >> years. >> > > Hm, I just browsed the man pages of many VCS systems (CVS included) to find > examples of parameters for the message file. I had no problem locating their > pages, browsing the manual and finding them for 6 VCS systems in about 3 > minutes. > >> > I personally like -M / --message-file and would value any features that >> > make fossil easier to integrate >> >> I have recently integrated fossil inside a GUI tool in RamDebugger (is >> it the first integration?), and have not missed at all the >> "-message-file" option. Why? It is fairly easy from an external tool >> to massage the log message to fit in the "-m" option. >> > > Some tools it would not be a problem, you are right. Currently I am trying to > integrate with one tool and it provides a simple macro recorder, nothing > really more. So, what you can type with your keyboard, it will record. I > suppose I could figure out some crazy regexp to do what I want, or we could > do like every other VCS under the sun and provide a -M/--message-file option. > > I *really* fail to see why an option like this should even be debated or why > one would deny a helpful feature to make our job easier just because there > are already 6 options, that as said, are very easy to get help on. > > 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
=?ISO-8859-1?Q?Ramon_Rib=F3?= wrote: > > If there is an option that a user has no interest in using, why would > > the user attempt to remember what it was? > > I recently had to read the cvs manual to find an option of one > subcommand. I assure you that it was not a pleasant task to surf > between the thousands of stupid options that cvs has gained with the > years. > Hm, I just browsed the man pages of many VCS systems (CVS included) to find examples of parameters for the message file. I had no problem locating their pages, browsing the manual and finding them for 6 VCS systems in about 3 minutes. > > I personally like -M / --message-file and would value any features that > > make fossil easier to integrate > > I have recently integrated fossil inside a GUI tool in RamDebugger (is > it the first integration?), and have not missed at all the > "-message-file" option. Why? It is fairly easy from an external tool > to massage the log message to fit in the "-m" option. > Some tools it would not be a problem, you are right. Currently I am trying to integrate with one tool and it provides a simple macro recorder, nothing really more. So, what you can type with your keyboard, it will record. I suppose I could figure out some crazy regexp to do what I want, or we could do like every other VCS under the sun and provide a -M/--message-file option. I *really* fail to see why an option like this should even be debated or why one would deny a helpful feature to make our job easier just because there are already 6 options, that as said, are very easy to get help on. 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.
> If I then do > > rm *.foo > > when I meant to do > > fossil rm *.foo > > I can then do > > fossil update > > which will give me my *.foo files back. Are you sure that this command is going to give that files back? Have you tried it? This is another field where there are currently proposals to change current behavior and do what you think that it does. The "principle of least surprise" is not followed here. 2009/12/10 Will Duquette : > I was unclear, apparently. > > Suppose "fossil rm *.foo" deletes the files from the file system and > from Fossil. > > If I then do > > rm *.foo > > when I meant to do > > fossil rm *.foo > > I can then do > > fossil update > > which will give me my *.foo files back. Then, I can do > > fossil rm *.foo > > Note that I'd expect "fossil rm *.foo" only to remove files from the > file system that it can remove from the repository, i.e., if I had an > extra file, not_added.foo, I'd expect "fossil rm *.foo" to live it > alone. > > Will > > On Dec 10, 2009, at 3:20 AM, Benjohn Barnes wrote: > >> >> On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org >> wrote: >> >>> 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 >> >> Although, I think, as you don't have any globbing, when you "ask >> fossil to give you the files back", you do need to type in all the >> names :-) (unless those deletions are the only changes that you've >> made to the working copy). >> >> ___ >> 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 > ___ 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
> If there is an option that a user has no interest in using, why would > the user attempt to remember what it was? I recently had to read the cvs manual to find an option of one subcommand. I assure you that it was not a pleasant task to surf between the thousands of stupid options that cvs has gained with the years. On the other side, it is a real pleasure to do "fossil help ..." and discover that the description of the subcommand takes less than 10 lines. > I personally like -M / --message-file and would value any features that > make fossil easier to integrate I have recently integrated fossil inside a GUI tool in RamDebugger (is it the first integration?), and have not missed at all the "-message-file" option. Why? It is fairly easy from an external tool to massage the log message to fit in the "-m" option. RR 2009/12/10 Daniel Clark : > Ramon Ribó 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... > > If there is an option that a user has no interest in using, why would > the user attempt to remember what it was? > > I personally like -M / --message-file and would value any features that > make fossil easier to integrate, as I'll probably be writing fossil > support for one of the python (d)vcs abstraction layers soon. > > Cheers, > -- > Daniel JB Clark | Sys Admin, Free Software Foundation > pobox.com/~dclark | http://www.fsf.org/about/staff#danny > > ___ > 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] [long] fossil html and CGI environment vars
On Thu, Dec 10, 2009 at 06:25:57AM -0500, D. Richard Hipp wrote: > > On Dec 9, 2009, at 11:26 PM, Michael wrote: > > > 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. > > Fossil does a redirect to the "index" page from time to time. But > this works on the webservers I've tried. Maybe something is different > on your server. > > What does the "test_env" page show you? Analogous to > http://www.fossil-scm.org/fossil/test_env > > D. Richard Hipp > d...@hwaci.com > ___ http://delora.autosys.us:/cgi/x.cgi/test_env inserts "test_env" rather than "index", e.g. http://delora.autosys.us:/cgi/x.cgi/test_env/style.css"; type="text/css" media="screen"> with same display problem. Full test_env.html file attached copy/pasted from 'view source' from browser. ~Michael Title: Erlang view server: Environment Test Erlang view server Environment Test Not logged in Home Leaves Timeline Branches Tags Tickets Wiki Login uid=1000, gid=1000 g.zBaseURL = http://delora.autosys.us:/cgi/x.cgi/test_env g.zTop = /cgi/x.cgi/test_env HTTP_HOST = delora.autosys.us: PATH_INFO = /test_env REMOTE_ADDR = 0:0:0:0:0::7F00:1 SCRIPT_NAME = /cgi/x.cgi/test_env 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
Re: [fossil-users] 3 Feature requests - globbing using the repository.
On Dec 10, 2009, at 6:39 AM, Jeremy Cowgar wrote: > Will Duquette wrote: >> I was unclear, apparently. >> >> Suppose "fossil rm *.foo" deletes the files from the file system and >> from Fossil. >> >> If I then do >> >>rm *.foo >> >> when I meant to do >> >>fossil rm *.foo >> >> I can then do >> >>fossil update >> >> which will give me my *.foo files back. Then, I can do >> >>fossil rm *.foo >> >> Note that I'd expect "fossil rm *.foo" only to remove files from the >> file system that it can remove from the repository, i.e., if I had an >> extra file, not_added.foo, I'd expect "fossil rm *.foo" to live it >> alone. >> > > What's wrong with that? I would expect that to be good behavior? Nothing's wrong with that; everything's right with that. :-) This is apparently my week for being unclear. In case I'm still unclear, I'm very much in favor of "fossil rm" working in the way described above. Will > > Jeremy > > ___ > 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.
Will Duquette wrote: > I was unclear, apparently. > > Suppose "fossil rm *.foo" deletes the files from the file system and > from Fossil. > > If I then do > > rm *.foo > > when I meant to do > > fossil rm *.foo > > I can then do > > fossil update > > which will give me my *.foo files back. Then, I can do > > fossil rm *.foo > > Note that I'd expect "fossil rm *.foo" only to remove files from the > file system that it can remove from the repository, i.e., if I had an > extra file, not_added.foo, I'd expect "fossil rm *.foo" to live it > alone. > What's wrong with that? I would expect that to be good behavior? 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.
I was unclear, apparently. Suppose "fossil rm *.foo" deletes the files from the file system and from Fossil. If I then do rm *.foo when I meant to do fossil rm *.foo I can then do fossil update which will give me my *.foo files back. Then, I can do fossil rm *.foo Note that I'd expect "fossil rm *.foo" only to remove files from the file system that it can remove from the repository, i.e., if I had an extra file, not_added.foo, I'd expect "fossil rm *.foo" to live it alone. Will On Dec 10, 2009, at 3:20 AM, Benjohn Barnes wrote: > > On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org > wrote: > >> 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 > > Although, I think, as you don't have any globbing, when you "ask > fossil to give you the files back", you do need to type in all the > names :-) (unless those deletions are the only changes that you've > made to the working copy). > > ___ > 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
[fossil-users] Feature idea: per-page RSS feeds and links (was: Re: rss link?)
IMHO it would be nice to have and RSS link on the page text. I'd also really love if each page could also have its own RSS feed. This way people could subscribe and be notified of changes only to pages they are interested in, instead of all changes which can be overwhelming. This would be esp. useful for bugs - currently I just have a table of bugs I am interested in at http://dclark.us/wiki?name=fossil+scm+notes that I check on every few months - it would be much nicer for changes to just pop up in my RSS reader. -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark | http://www.fsf.org/about/staff#danny Wilson, Ronald wrote: > Ah that may explain it. I'm using google chrome (a modern browser) which has > no rss support at all. > > RW > > Ron Wilson, Engineering Project Lead > (o) 434.455.6453, (m) 434.851.1612, www.harris.com > > HARRIS CORPORATION | RF Communications Division > assuredcommunications(tm) > >> -Original Message- >> From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users- >> boun...@lists.fossil-scm.org] On Behalf Of Jeremy Cowgar >> Sent: Tuesday, December 08, 2009 2:55 PM >> To: fossil-users@lists.fossil-scm.org >> Subject: Re: [fossil-users] rss link? >> >> >> "Wilson, Ronald" wrote: >>> All this talk about RSS prompted me to look for an RSS link on the >>> fossil gui. I can't find one. I figured it out by scouring the list >>> archive. Where should we document the timeline.rss link? I think it >>> would be cool to have it on the footer but somewhere on the top of the >>> timeline page would suffice. Any suggestions? >>> >> You can put it there but most modern browsers detect it automatically due >> to the link in the header, for example: >> >> > href="http://jeremy.cowgar.com/mailroom/index.cgi/timeline.rss";> >> >> but... it never hurts. Not all browser light up a button when an RSS feed >> is available. >> >> 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
Ramon Ribó 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... If there is an option that a user has no interest in using, why would the user attempt to remember what it was? I personally like -M / --message-file and would value any features that make fossil easier to integrate, as I'll probably be writing fossil support for one of the python (d)vcs abstraction layers soon. Cheers, -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark | http://www.fsf.org/about/staff#danny ___ 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 wrote: > > i'm with Jeremy on this one: -M/--message-file. That said, Richard's been > interestingly quiet throughout this conversation, which leads me to suspect > that he's hacking away at some clever alternative which will make all this > moot :). > SVN uses -F and --file BZR uses -F and --file HG uses -l and --logfile CVS uses -F Git uses -F Monotone uses --message-file Darcs uses --logfile ... now, one side note... all these tools support the loading of a commit log message via a file. I did not look at the other 100 tools, only the ones that I have used in the past for any length of time. We already have on the commit command: --comment|-m COMMENT-TEXT --branch NEW-BRANCH-NAME --bgcolor COLOR --nosign --force|-f --private So, if we were to use -F, we'd be overloading --force. That's probably not a good idea as it will not err out, I wouldn't think, on a "CAPS" lock error (has anyone ever done that or are we programming around a 1 in a million case? i.e. -m vs. -M. HG using --logfile|-l seems OK, but I think I like --message-file|-M better still. One thing to think about is we don't *have* to have a short option. My guess is that we will not be using --message-file from the command line that often. It's probably going to be used mainly from other tools, but that's just a guess, no real data backing that thought other than my own usage. 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] --dry-run (WAS Commit failing... retyping commit message)
Wilson, Ronald wrote: >> 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 For what it's worth I think --dry-run (short form -n) is more common in *nix land; at least GNU project software, rsync and bcfg2 use it. [1] GNU coding standards: 4.8 Table of Long Options http://www.gnu.org/prep/standards/html_node/Option-Table.html -- Daniel JB Clark | Sys Admin, Free Software Foundation pobox.com/~dclark | http://www.fsf.org/about/staff#danny ___ 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
My intuition says: Use -M|--message-file.
- Altu
-Original Message-
From: Stephan Beal
To: fossil-users@lists.fossil-scm.org
Sent: Thu, Dec 10, 2009 4:19 pm
Subject: Re: [fossil-users] Commit failing... retyping commit message
On Thu, Dec 10, 2009 at 9:41 AM, Daniel Hoolihan wrote:
i completely agree with "lets keep options to a minimum" and i
appreciate the comment "we shouldn't mind code complexity"
so .. might i suggest that -m be overloaded?? so both of these would work..
Good morning!
i've changed it to -ZZZ and --read-message-from-file.
Just kidding.
The original justification for using "-M" was "-M is an alternate form of -m,"
and my instinct says to use -M over -i/--infile (which i find a bit confusing
in this context because the committed files are the "input files"). Jeremy's
suggestion of --message-file is a good alternative to --comment-file, and seems
more intuitive to me.
fossil commit -m ./file.txt would
fossil commit -m "commit message"
essentially -m would first check to see if resolves to a
valid file, otherwise take to be the comment text..
This would actually more than double the code needed, i think. Currently i use
blob.c::blob_read_from_file() to populate the comment string from, and that
function calls fossil_panic() (i.e. exit app) if the file doesn't exist:
if( zComment ){ /* -m TEXT */
blob_zero(&comment);
blob_append(&comment, zComment, -1);
}else if( zCommentFile ){ /* -M FILENAME */
blob_zero(&comment);
blob_read_from_file(&comment, zCommentFile);
}else{ /* use editor */
prepare_commit_comment(&comment);
}
We'd need to merge the first 'if' and 'else if', and then add the logic to test
for file existence (or just try to open it), and fall back to using zComment as
a -m string if we can't find/open the file. While that would work 99.9% of the
time, it would fail with unexpected results when a commit message string really
does resolve to a readable file. i honestly don't think it would ever happen,
but the possibility is there:
f commit -m /etc/hosts foo.c
Not tragic, but mildly disturbing to look at in the commit log (and may require
a purge of the artifact, depending on the security/sensitivity level of the
system it was pulled from). On a similar note:
f commit -m /etc/sudoers foo.c
would fail (via fossil_panic()) for non-root users because /etc/sudoers is mode
0440 on most systems.
Again, far-fetched but possible.
i'm with Jeremy on this one: -M/--message-file. That said, Richard's been
interestingly quiet throughout this conversation, which leads me to suspect
that he's hacking away at some clever alternative which will make all this moot
:).
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___fossil-users mailing
listfossil-us...@lists.fossil-scm.orghttp://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] 3 Feature requests - globbing using the repository.
My 2 cents. --keep and --force options are intuitive, I would prefer them. - Altu -Original Message- From: Joshua Paine To: fossil-users@lists.fossil-scm.org Sent: Thu, Dec 10, 2009 3:15 am Subject: 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 reallyneeded sometimes. I.e., "don't keep track of this file anymore". I likethat that's convenient, too.So, for what little it's worth, I'd like fossil mv and fossil rm toreally perform the file system operations by default, and let me accessthe 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 thathasn't been committed (and the consequent necessity of the --forceoption).-- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Bug? A file moved outside of checkin tree
I offered a (horrible) work around. Fortunately, I thought better of it for my particular case, where my working set was in the middle of a merge. Instead, I've used sqlite on the command line to find a row in the vfile table and correct it's "pathname" so it's where I meant to move it to, rather than outside of the versioned tree. It all _seems_ to be okay now :-} ... Cheers, Benjohn ___ 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 don't care what the long name for the option is but I do think -M is
a mistake. off the top of my head I can't think of any fossil
parameters that are not lowercase but perhaps there is. can someone
confirm that the fossil command line parameters are even case sensitive?
I agree that overloading -m is also a mistake. how about --comment-
file|-i? -f is already used for --force.
rw
from my mobile 434.851.1612
On Dec 10, 2009, at 5:49 AM, "Stephan Beal"
wrote:
On Thu, Dec 10, 2009 at 9:41 AM, Daniel Hoolihan
wrote:
i completely agree with "lets keep options to a minimum" and i
appreciate the comment "we shouldn't mind code complexity"
so .. might i suggest that -m be overloaded?? so both of these would
work..
Good morning!
i've changed it to -ZZZ and --read-message-from-file.
Just kidding.
The original justification for using "-M" was "-M is an alternate
form of -m," and my instinct says to use -M over -i/--infile (which
i find a bit confusing in this context because the committed files
are the "input files"). Jeremy's suggestion of --message-file is a
good alternative to --comment-file, and seems more intuitive to me.
fossil commit -m ./file.txt would
fossil commit -m "commit message"
essentially -m would first check to see if resolves
to a
valid file, otherwise take to be the comment text..
This would actually more than double the code needed, i think.
Currently i use blob.c::blob_read_from_file() to populate the
comment string from, and that function calls fossil_panic() (i.e.
exit app) if the file doesn't exist:
if( zComment ){ /* -m TEXT */
blob_zero(&comment);
blob_append(&comment, zComment, -1);
}else if( zCommentFile ){ /* -M FILENAME */
blob_zero(&comment);
blob_read_from_file(&comment, zCommentFile);
}else{ /* use editor */
prepare_commit_comment(&comment);
}
We'd need to merge the first 'if' and 'else if', and then add the
logic to test for file existence (or just try to open it), and fall
back to using zComment as a -m string if we can't find/open the
file. While that would work 99.9% of the time, it would fail with
unexpected results when a commit message string really does resolve
to a readable file. i honestly don't think it would ever happen, but
the possibility is there:
f commit -m /etc/hosts foo.c
Not tragic, but mildly disturbing to look at in the commit log (and
may require a purge of the artifact, depending on the security/
sensitivity level of the system it was pulled from). On a similar
note:
f commit -m /etc/sudoers foo.c
would fail (via fossil_panic()) for non-root users because /etc/
sudoers is mode 0440 on most systems.
Again, far-fetched but possible.
i'm with Jeremy on this one: -M/--message-file. That said, Richard's
been interestingly quiet throughout this conversation, which leads
me to suspect that he's hacking away at some clever alternative
which will make all this moot :).
--
- 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bug? A file moved outside of checking tree.
Hi, I've managed to get my working copy in to a funny state. I performed a "fossil mv" on a file, and gave a destination outside of the checkin tree. Fossil was happy to perform this operation, but now I'm not able to correct the mistake. If I try to move the file back in, I get the error "file outside of checkout tree". This is pretty easy to recreate with an empty repo... fossil new ~/Repos/FossilTest mkdir FossilTest cd FossilTest fossil open ~/Repos/FossilTest touch a_file fossil add a_file fossil com -m "adding a test file." fossil mv a_file .. mv a_file .. From here on, I don't see how to get fossil back to being happy again. If I to: fossil mv ../a_file ./ Fossil tells me: fossil: file outside of checkout tree: ../a_file The only workaround I've found so far (using a test repo, and not the merge I've been working on...) is to: remove the _FOSSIL_, manifest, and manifest.uuid files checkout my project (pre merge) in to somewhere. copy the mentioned files back from the new checkout in to my working folder make changes as necessary using fossil's commands Which seems a bit dangerous. Sorry if this email isn't clear :-( Thanks, Benjohn ___ 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] [long] fossil html and CGI environment vars
On Dec 9, 2009, at 11:26 PM, Michael wrote: > 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. Fossil does a redirect to the "index" page from time to time. But this works on the webservers I've tried. Maybe something is different on your server. What does the "test_env" page show you? Analogous to http://www.fossil-scm.org/fossil/test_env 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] 3 Feature requests - globbing using the repository.
On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org wrote: > 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 Although, I think, as you don't have any globbing, when you "ask fossil to give you the files back", you do need to type in all the names :-) (unless those deletions are the only changes that you've made to the working copy). ___ 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 9:41 AM, Daniel Hoolihan wrote:
> i completely agree with "lets keep options to a minimum" and i
> appreciate the comment "we shouldn't mind code complexity"
> so .. might i suggest that -m be overloaded?? so both of these would work..
>
Good morning!
i've changed it to -ZZZ and --read-message-from-file.
Just kidding.
The original justification for using "-M" was "-M is an alternate form of
-m," and my instinct says to use -M over -i/--infile (which i find a bit
confusing in this context because the committed files are the "input
files"). Jeremy's suggestion of --message-file is a good alternative to
--comment-file, and seems more intuitive to me.
> fossil commit -m ./file.txt would
> fossil commit -m "commit message"
> essentially -m would first check to see if resolves to a
> valid file, otherwise take to be the comment text..
>
This would actually more than double the code needed, i think. Currently i
use blob.c::blob_read_from_file() to populate the comment string from, and
that function calls fossil_panic() (i.e. exit app) if the file doesn't
exist:
if( zComment ){ /* -m TEXT */
blob_zero(&comment);
blob_append(&comment, zComment, -1);
}else if( zCommentFile ){ /* -M FILENAME */
blob_zero(&comment);
blob_read_from_file(&comment, zCommentFile);
}else{ /* use editor */
prepare_commit_comment(&comment);
}
We'd need to merge the first 'if' and 'else if', and then add the logic to
test for file existence (or just try to open it), and fall back to using
zComment as a -m string if we can't find/open the file. While that would
work 99.9% of the time, it would fail with unexpected results when a commit
message string really does resolve to a readable file. i honestly don't
think it would ever happen, but the possibility is there:
f commit -m /etc/hosts foo.c
Not tragic, but mildly disturbing to look at in the commit log (and may
require a purge of the artifact, depending on the security/sensitivity
level of the system it was pulled from). On a similar note:
f commit -m /etc/sudoers foo.c
would fail (via fossil_panic()) for non-root users because /etc/sudoers is
mode 0440 on most systems.
Again, far-fetched but possible.
i'm with Jeremy on this one: -M/--message-file. That said, Richard's been
interestingly quiet throughout this conversation, which leads me to suspect
that he's hacking away at some clever alternative which will make all this
moot :).
--
- 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
i completely agree with "lets keep options to a minimum" and i appreciate the comment "we shouldn't mind code complexity" so .. might i suggest that -m be overloaded?? so both of these would work.. fossil commit -m ./file.txt would fossil commit -m "commit message" essentially -m would first check to see if resolves to a valid file, otherwise take to be the comment text.. Daniel On 10/12/2009 1:58 PM, Jeremy Cowgar wrote: > Stephan Beal wrote: > >> On Thu, Dec 10, 2009 at 12:48 AM, Wilson, Ronaldwrote: >> >> >>> 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
