Re: [fossil-users] clone a repository over ssh where the path includes whitespace characters
Thus said Stephan Beal on Thu, 08 Aug 2019 12:06:30 +0200: > fossil clone 'ssh://user@domain://path/to/"directory with > spaces"/my.fossil' my.fossil Yes, that works, but it's a hack really because the user has to know that Fossil is using /bin/sh instead of simply calling exec() with appropriate arguments. In my opinion, Fossil really should not be using execl with /bin/sh here: https://www.fossil-scm.org/home/artifact?udc=1&ln=203&name=036510c48cbc9212 Instead, I think it would be preferable to do something like: https://www.fossil-scm.org/home/info/ce7baa9798de21aa Otherwise, Fossil will have to be enhanced to start quoting things shell-style so the user doesn't have to worry about anything more than quoting it in his shell. In other words, what Poor Yorick did by quoting the entire string should have been sufficient, but what he didn't know was that another level of quotes was needed because Fossil is going to pass it to another /bin/sh interpreter will will require additional quoting---surprise. Thanks, Andy -- TAI64 timestamp: 40005d4c30ff ___ 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] Corrupt database at first commit after a Fossil update
Thus said Stephan Beal on Thu, 08 Nov 2018 02:24:40 +0100: > Unlike the mailing list, the forum allows anonymous posts, but such > posts are always moderated before they're visible to the public. The mailing list actually does allow anonymous posts to a degree. The From header does not have to match the Envelope FROM and can be whatever one desires, including a bogus address. All that matters to the mailing list software is that the Envelope FROM matches what's in the MLM database. I exploit this feature by making my From different from the email address that is actually subscribed to the mailing list; notice that here my actual subscriber email address is never exposed: https://marc.info/?l=fossil-users&m=153400926421821&w=2 If I had wanted, I could have put entirely bogus information in the From and the MLM would still send the email as long as the Envelope FROM is correct---only the MLM owner knows my Envelope From and it is not exposed to anyone. Andy -- TAI64 timestamp: 40005be4513a ___ 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] Fossil update
Thus said Zolt?n K?csi on Wed, 07 Nov 2018 20:48:11 +1100: > 'fossil update' (autosync/push/pull enabled) updates the local tree > but not to the latest version. This sounds like a cluster synchronization bug that was squashed after Fossil 1.29 was released: https://www.fossil-scm.org/index.html/timeline?c=2014-07-22+22:26:50 Check your ``fossil version'' to be certain. If it is indeed the same bug, then you can use ``fossil pull --verily'' to pull down the missing content. Andy -- TAI64 timestamp: 40005be44f6c ___ 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] Test From masquerading
Thus said Jungle Boogie on Sun, 12 Aug 2018 00:39:53 -0700: > Just curious, how did you masquerade your address? It might still work > on other mailing lists you're subscribed to. I have a script which sits as a wrapper around the /usr/sbin/sendmail interface that takes care of it all for me. I have a simple ``database'' of recipient addresses and what the expected From and Envelope From addresses should be and when the script is invoked, it parses the mess822 headers out and rewrites them according to the rules. In the case of Fossil Users, I have an instruction that causes the Envelope From to be my subscriber address found in the mailing list database, and the From to be a timestamped email address that expires after 30 days. The mailing list permits the message because it finds my subscription via the Envelope From and permits it to be delivered. The From address can be harvested and will only be useful for 30 days which allows individuals to respond directly to my emails if they want without undergoing any spam blocking. Arguably, this script belongs in the MUA and while I use an MUA that is highly extensible, I've never bothered to take the time to figure out how to make it work there. :-) If you look closely, and if gmail permits it (because it lamely suppresses things that it thinks are duplicate messages), you'll see two different email addresses based on which email you receive---the one that gets used when I send directly to you, and the one that arrives in the mailing list delivered email. Andy -- TAI64 timestamp: 40005b7097ae ___ 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] This mailing list is now deprecated
Thus said Warren Young on Fri, 10 Aug 2018 08:34:24 -0600: > > http://sqlite.1065341.n5.nabble.com/Problems-with-v3-9-0-entry-point-sqlite3-finalize-could-not-be-located-td85005.html#a85069 > > You only need to read the first post, not the whole thread. > > Fossil forums prevent that problem. Throwing a rock through an 747's window is one way to solve the problem of getting a plane to drop in altitude, but that doesn't mean it's the best way. The problem described on that link is about spammers subscribing to the mailing lists and then sending automated spam to those who post to the mailing list. We've discussed this before on this mailing list and some suggestions were made, and I guess this new forum feature was easier to implement, even if it does make communication less useful. Oddly enough, I haven't seen much of the spam that people are complaining about lately---maybe that means my spam blocking is getting it, or maybe it means the spammers have left? Andy -- TAI64 timestamp: 40005b6f2492 ___ 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] Test From masquerading
Thus said "Andy Bradford" on 11 Aug 2018 11:41:01 -0600: > This is just a test. Only now at the end do I realize that Fossil Users allowed subscribers to hide their subscriber email address... pity. Andy -- TAI64 timestamp: 40005b6f213b ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Test From masquerading
Hello, This is just a test. Andy -- TAI64 timestamp: 40005b6f1fd2 ___ 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] This mailing list is now deprecated
Thus said sky5w...@gmail.com on Fri, 10 Aug 2018 13:35:15 -0400: > Whoa, I still receive spam from this mail list. :( Correction: You received spam from spammers. The mailing list has yet to deliver spam as far as I can tell. I believe what you mean is that your email address that you use on this mailing list has been harvested by spammers and that they are contacting you directly. That can be easily thwarted by simply setting your From address to be an invalid address, much like Will Parsons does: From: Will Parsons To: fossil-users@lists.fossil-scm.org Date: Wed, 8 Aug 2018 19:49:27 -0400 (17:49 MDT) Subject: Re: [fossil-users] This mailing list is now deprecated I wasn't aware that fossil-users actually allowed using a different From header than is in the Envelope From or I would have been doing this ages ago. Andy -- TAI64 timestamp: 40005b6f1ea9 ___ 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] This mailing list is now deprecated
Thus said Warren Young on Wed, 08 Aug 2018 11:45:09 -0600: > > Will this ever be enabled? I prefer email over web forum posting. > > How would you prevent spammers from using an email submission > mechanism? Most mailing list managers prevent this by only allowing subscribers to submit emails. I cannot recall the last time I saw spam sent to fossil-users@lists.fossil-scm.org... > I've got an email address that got onto the spamners' lists despite > only ever being published in a short-run book distributed to about 50 > people. If your concern is that email addresses are being harvested, most mailing list managers have the ability to hide sender email addresses. Few of the mailing lists I'm subscribed to use this feature, but it does exist. I believe even Fossil tried to use it once, but the general feedback was that nobody liked it. A better solution is for the subscriber to simply use a different email address for the mailing list---even Gmail supports email aliases. > If we don't solve that problem first, we'll be right back in much the > same mess as today. Replacing a mailing list with a web forum seems to simply trade one set of problems for another. I'm on dozens of other public mailing lists that get a lot more traffic than Fossil Users does and there seems to be no problems there... Why don't we leave both in place and see what people prefer to use? Those who are willing to live with the problems that come with email will express their preference by continuing to use email. > Moderation doesn't help. Someone could weed the current mailing list > archives, too. Is the web forum now moderated? Does it help? Andy -- TAI64 timestamp: 40005b6d9114 ___ 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] This mailing list is now deprecated
Thus said Richard Hipp on Wed, 08 Aug 2018 08:40:37 -0400: > New submissions via email are disallowed as an anti-spam > measure. Will this ever be enabled? I prefer email over web forum posting. Also, would it be a good idea to subscribe some of the mail archiving addresses for continuity? I personally prefer reading archives via: https://marc.info/?l=fossil-users https://marc.info/?l=fossil-dev Thanks, Andy -- TAI64 timestamp: 40005b6aff59 ___ 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] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
Thus said Richard Hipp on Tue, 07 Aug 2018 11:02:03 -0400: > That would delay the second HTTP request coming over the SSH connection. When I suggested that, I didn't understand enough about the backoffice design---specifically that it was a long-running task. After reading the forum page you sent, I see that what you're looking for is a way to fork() off a backend process and only have one of those operating at a given time. Andy -- TAI64 timestamp: 40005b69ea80 ___ 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] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
Thus said Richard Hipp on Tue, 07 Aug 2018 10:21:34 -0400: > yes, we do want backoffice to run for SSH transport. Then I suggest that we simply make backoffice_run() smart enough to know that it has already run once: For example, perhaps instead of a panic here, backoffice_run() should just return? http://www.fossil-scm.org/index.html/artifact?udc=1&ln=225-227&name=d2cf5ceb442267a8 Thanks, Andy -- TAI64 timestamp: 40005b69ae87 ___ 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] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
Thus said joerg van den hoff on Tue, 07 Aug 2018 16:10:15 +0200: > why did I see the problem only when actually cloning from another > machine, whereas a clone using ssh while being loggedin to the server > machine still worked? in both cases the ssh communication should be > the same, no? How were you cloning while logged in to the server machine? What commands did you use while loggged in to the server to clone? Thanks, Andy -- TAI64 timestamp: 40005b69a9d2 ___ 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] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
Thus said Richard Hipp on Tue, 07 Aug 2018 09:53:35 -0400: > Please build the from the tip of the forum-v2 branch and let me know > whether or not it is working for you. I was just about to submit a similar fix but you beat me to it. The reason why this doesn't work the same as a traditional HTTP connection is because the SSH transport uses a single connection for all communications, whereas the HTTP transport uses one connection per request. If we want to continue to have backoffice_run() work with an SSH client we would need a counter to keep track of how many times a sync has happened (there may already be one available but I would have to look at the code). Does it make sense to have backoffice_run() in the SSH transport? If not, then your fix is apropos. Thanks, Andy -- TAI64 timestamp: 40005b69a76f ___ 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] Feature slideshow on fossil homepage
Thus said Jungle Boogie on Thu, 12 Jul 2018 13:54:04 -0700: > > http://fossil.bradfords.org/fossilthings.gif > > > > Does this look more enticing? > > That doesn't appear to establish a connection. Is your server down? The server was up, so is the firewall. :-) Try this instead: http://fossil.bradfords.org:81/fossilthings.gif Thanks for the note. Andy -- TAI64 timestamp: 40005b4a4eec ___ 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] Feature slideshow on fossil homepage
Thus said mario on Mon, 09 Jul 2018 18:06:52 +0200: > Our current homepage is a bit wall of textish / too bland I'd think. > While it already gets all interesting features across, it's not likely > enticing to new users. Here's a GIF animation of what it looks like in my browser: http://fossil.bradfords.org/fossilthings.gif Does this look more enticing? Thanks, Andy -- TAI64 timestamp: 40005b47aeee ___ 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] Mailing list shutting down...
Thus said Richard Hipp on Wed, 13 Jun 2018 07:28:02 -0400: > The most recent problem is that robots are visiting the subscription > page and entering innocent user's email addresses and names. What about simply disabling web-based subscriptions and require people to subscribe via email? Thanks, Andy -- TAI64 timestamp: 40005b2164f7 ___ 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 in /finfo not showing Deleted anymore.
Hello, I haven't had the time to investigate further, but it seems that with this commit, the /finfo timeline no longer shows when a file gets Deleted: http://www.fossil-scm.org/index.html/info/4c268999d5 Thanks, Andy -- TAI64 timestamp: 40005b212f3a ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to rename a directory
Thus said Dingyuan Wang on Sun, 06 May 2018 00:37:23 +0800: > The fossil mv command seems can't rename a directory. I thought Fossil only tracked files (which is their complete path relative to the repository checkout) and does not actually track directories by themselves. For example, this works fine: $ mkdir first $ touch first/file $ ./fossil add first/file ADDED first/file $ ./fossil ci -m go New_Version: 600ce3e31ee64a3ff98a9af360b50d5ca24323acac04ee25d26eee82de78fa58 $ ./fossil mv --hard first/file second/file RENAME first/file second/file MOVED_FILE /tmp/first/file $ ./fossil ci -m again New_Version: 5107ce9a7299518f44799149094ace083f7cec994578d429ca94897e3b09e395 $ ls first $ ls second file Andy -- TAI64 timestamp: 40005aee8760 ___ 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] Detecting checkout/repo mismatch
Thus said Richard Hipp on Thu, 29 Mar 2018 06:51:45 -0400: > You can't. But in more than a decade of use, this has never come up > before? Is this really a serious problem? Do we need to add new checks > to verify that the _FOSSIL_ file refers to the correct repository? I would say it's a ``nice to have'' as I cannot imagine it happening very often. For this to present an actual problem the repositories would have to have identical filenames and rids would have to at least be somewhat consisent. Fossil did return an error about there being a mismatch: > $ fossil commit -m "test 2" > Could not find a valid check-in for RID 6. Possible checkout/repo mismatch. What are the chances that RID 6 would have actually matched a checkin and that those files would also have been found in the repository? Had the right conditions existed, I supposed the commit would have succeeded? Andy -- TAI64 timestamp: 40005abe4741 ___ 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] Any way to cleanup global _fossil or .fossil?
Thus said The Tick on Mon, 19 Mar 2018 15:43:07 -0500: > That did not seem to do much (if anything). There are still records > for repositories that no longer exist. What specific things in the .fossil file are you looking to have removed? fossil all ls seemed to clean up old entries for me (though perhaps we're talking about a different ``old entry''). Also, I'm not on Windows. Before running ``fossil all ls'' here: $ echo "SELECT * FROM global_config WHERE name GLOB 'repo:*';" | sqlite3 .fossil | wc -l 39 After: $ echo "SELECT * FROM global_config WHERE name GLOB 'repo:*';" | sqlite3 .fossil | wc -l 27 Are you talking about repo:* entries? Or something else? Thanks, Andy -- TAI64 timestamp: 40005ab16af1 ___ 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] Experimental timeline "View Mode" changes.
Thus said Richard Hipp on Sat, 17 Mar 2018 12:02:41 -0400: > A new "Classic" viewing mode has been added to the timeline. I had a look at the test run sites... I prefer using the "Classic" view and also I think it makes sense to call it "Classic" as long as it retains the classic style of the timeline. The name "Verbose" always seemed to be a poor fit in my opinion. It does mean that those who were previously using the "Verbose" will have to express their preference one more time to return to the "Classic" view but in this case as long as people are given fair warning, I think it makes sense. Andy -- TAI64 timestamp: 40005aad4742 ___ 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] Setting up an internet Fossil server
Thus said Scott Doctor on Sat, 24 Feb 2018 10:57:58 -0800: > I am having trouble getting fossil to work. What specifically are you having trouble with? Thanks, Andy -- TAI64 timestamp: 40005a91c739 ___ 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] Why is i...@papier.host4free.ovh spamming the list?
Thus said Richard Hipp on Sat, 06 Jan 2018 17:06:31 -0500: > Either way, they have been permanently banished from the list, as of > about this time last night. You shouldn't be getting any new message > from i...@papier.host4free.ovh. Oh, I didn't realize it had already been squashed. Thanks. Andy -- TAI64 timestamp: 40005a514ac7 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Why is i...@papier.host4free.ovh spamming the list?
Hello, i...@papier.host4free.ovh has sent roughly 98 emails to this mailing list with nothing but ``Hallöchen!'' as the text (and a signature form an iPhone). The Subject in each is a variation of the original from Matt Welland, but often seems to have just a few characters altered, looking like: Subject: Re: [fossil-users] fossil help set no longer provides essen ti a l i n f o r m a t i o n Subject: Re: [fossil-users] fossil help set no longer provides essen tia l i n f o r m a t i o n Subject: Re: [fossil-users] fossil help set no longer provides essen tial information Subject: Re: [fossil-users] fossil help set no longer provides essen tial informati o n Subject: Re: [fossil-users] fossil help set no longer provides essen t i a l i n f o r m a t i o n Subject: Re: [fossil-users] fossil help set no longer provides essen tial information Is this a prank, or just a really bad autoresponder? Andy -- TAI64 timestamp: 40005a5144ad ___ 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] fossil help set no longer provides essential information
Thus said Richard Hipp on Fri, 05 Jan 2018 13:42:29 -0500: > Maybe I just need to improve the "fossil help setting" output to > provide some clue about how to get help on individual settings? That would be an improvement as just in responding to this email I had to figure out how to get the new settings help because it wasn't obvious to me that the domain of settings help has now entered the same domain as subcommand help, but it still means that, one has to run a minimum of 2 commands. With the current state of settings help: 1) fossil settings (inspect settings list and pick one interesting) 2) fossil help Before, it was easier just to run: fossil help settings Then scroll up through the output, or use a $PAGER. Maybe a --verbose option to fossil help settings would make it so one can get all the information in a single request? Matt, what would you think is an improvement? Andy -- TAI64 timestamp: 40005a4fdadd ___ 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] fossil-users Digest, Vol 120, Issue 2
Thus said Stephan Beal on Tue, 02 Jan 2018 04:33:56 +0100: > That's not what i'm seeing: > > [stephan@host:~]$ echo -e "1\n2\n3" > 1 > 2 > 3 > [stephan@host:~]$ echo $(echo -e "1\n2\n3") > 1 2 3 Hmm, that's interesting. Have a look at this... Here's a file that has newlines in it, and which I will commit as a comment to a ticket from command line arguments. Then I will inspect the artifact that was generated from the ticket: $ cat first.txt First from file. With multiple lines. $ fossil ticket add title "Test" comment "$(cat first.txt)" ticket add succeeded for 0e9c37eab5c7123d530097be4b298ba507a443af $ fossil artifact 07760c2485 D 2018-01-02T05:54:32.670 J comment First\sfrom\sfile.\n\nWith\smultiple\slines. J title Test K 0e9c37eab5c7123d530097be4b298ba507a443af U amb Z 360677764c30fd6bb5049d637b0c1c28 Notice that the J-card shows all the newlines except the last two (which were stripped I presume by the shell). Now let's append: $ cat second.txt Second from file. With multiple lines. $ fossil ticket change 0e9c37eab +comment "$(cat second.txt)" ticket set succeeded for 0e9c37eab5c7123d530097be4b298ba507a443af $ fossil artifact 34db266dcb0f117b D 2018-01-02T06:03:46.839 J +comment \nSecond\sfrom\sfile.\n\nWith\smultiple\slines. K 0e9c37eab5c7123d530097be4b298ba507a443af U amb Z da0a4b7d872315fd7c46c42cfa1259aa In this case, the newline at the beginning of the file was also preserved in the J-card. When it gets rendered, however, there is no tag in front of the second chunk of comment (I'm not sure why). But if I add a newline this way: $ cat third.txt Third comment from file. With multiple lines. $ fossil ticket change 0e9c37eab +comment " > $(cat third.txt)" ticket set succeeded for 0e9c37eab5c7123d530097be4b298ba507a443af $ fossil artifact db16ba984f4d543d D 2018-01-02T06:07:43.120 J +comment \nThird\scomment\sfrom\sfile.\n\nWith\smultiple\slines. K 0e9c37eab5c7123d530097be4b298ba507a443af U amb Z c6de4dba1e840597206da2c761f94053 But this seems to work differently, even with similar input: $ cat fourth.txt Fourth from file. With multiple lines. $ fossil artifact 902a2ec529584f13 D 2018-01-02T06:09:02.317 J +comment \nFourth\sfrom\sfile.\n\nWith\smultiple\slines.\n K 0e9c37eab5c7123d530097be4b298ba507a443af U amb Z f6470d3a73f9ee9e94020219a70c0195 The output in the UI now looks like the following: First from file. With multiple lines. Second from file. With multiple lines. Third comment from file. With multiple lines. Fourth from file. With multiple lines. So, if the shell is stripping all the newlines, how does Fossil know that there are newlines as evidenced by the J-card entries that show multiple embedded newlines? And even the shell seems to work as I would expect: $ echo "$(cat first.txt)" > /tmp/output.txt $ cat /tmp/output.txt First from file. With multiple lines. So I'm not sure why this wouldn't also work for the OP with Fossil. Thanks, Andy -- TAI64 timestamp: 40005a4b241f ___ 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] fossil-users Digest, Vol 120, Issue 2
Thus said Stephan Beal on Tue, 02 Jan 2018 03:07:20 +0100: > That will still strip any newlines from his input, though, because > that's how $(...) works. It actually only strips the trailing newline. Any newlines in the middle of the file are fine. So for example: $ cat third.txt Third from file. With multiple lines. $ fossil ticket change 64f086ad5be82495327100a66dcdee24432e2b79 +comment " $(cat third.txt)" ticket add succeeded for 64f086ad5be82495327100a66dcdee24432e2b79 Will work, as long as that embedded newline (maybe it's actually a carriage-return) is in there. > To get the comment text imported verbatim, i suspect that the ticket > command needs to support a -M FILENAME option to import a comment, > like checkin does. And this certainly would be a friendlier option. :-) Andy -- TAI64 timestamp: 40005a4af1ee ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to cleanup two leafs on private branch?
Thus said Olivier Mascia on Mon, 01 Jan 2018 22:33:19 +0100: > WARNING: multiple open leaf check-ins on private: > (1) 2018-01-01 17:21:25 [cf17bd1315] (current) > (2) 2017-12-31 12:49:25 [6e96981da8] > There is really nothing wrong. I just would like to 'close' those > leafs or the whole private branch and re-use it later for other > purposes. Given that you know the commit IDs, you could just do: fossil amend cf17bd1315 --close fossil amend 6e96981da8 --close Also, Fossil doesn't impose any uniqueness restrictions with branch names. You can reuse the same private branch name multiple times if you want. Andy -- TAI64 timestamp: 40005a4aefc1 ___ 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] ticket length limitation
Thus said Sergey Bronnikov on Mon, 01 Jan 2018 12:44:42 +: > $ echo "fossil ticket add title "title" comment \"$(cat content)\"" | wc -c > 469207 > > Is there any workaround? There is one workaround that I'm aware of. If you chop your comment up into chunks you could do something like: fossil ticket add title "title" comment "$firstchunk" fossil ticket change +comment "$secondchunk" fossil ticket change +comment "$thirdchunk" However, if you want an actual paragraph break between the first and second chunks (and not just concatenation) then you would have to embed a newline in there like: fossil ticket change +comment " $fourthchunk" Andy -- TAI64 timestamp: 40005a4aee1b ___ 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] id of a ticket added via command line
Thus said Sergey Bronnikov on Sun, 31 Dec 2017 11:40:48 +: > For import purpose I use 'fossil tickets' commands, like this: fossil > ticket title "title" comment "comment" and it creates new ticket in > Fossil SCM. After this I need to add other messages as comments. But > how to automatically understand id of added ticket? It would appear that Fossil incorrectly identifies each new ticket as an error condition and outputs nothing. I've committed a fix to trunk. Please verify that it works better for you: http://www.fossil-scm.org/index.html/info/d4c6f3c439e369e0 Before this fix, Fossil would never output anything on a successful ticket operation so you didn't ever get the Ticket ID. That would make it pretty difficult to deterministically obtain the Ticket ID. Andy -- TAI64 timestamp: 40005a498829 ___ 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] fossil server on a small private LAN
Thus said Warren Young on Thu, 28 Dec 2017 08:20:21 -0700: > I'm pretty sure I've never seen Fossil crash in the years I've been > running it. I've had it dump core a few times but those were generally due to bugs that were quickly fixed. Andy -- TAI64 timestamp: 40005a4540f3 ___ 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] Digital signatures on check-ins. Was: tangent vs. wyoung on recent commti
Thus said Richard Hipp on Thu, 21 Dec 2017 16:46:05 -0500: > Suppose Fossil were enhanced to show an icon beside each check-in that > indicated whether or not the check-in had been signed and whether the > signature had been verified. Regarding such an enhancement, would it involve configuring an external tool that is passed the content (perhaps on stdin) and then returns success/fail/whatever semantics Fossil defines? If so, I can see this being quite useful to integrate with any kind of content verification system, and not just PGP. One could write a wrapper around gpg, signify, openssl, or even submit it to a virus scanner if they wanted, and Fossil could report the the ``verification'' of it. Andy -- TAI64 timestamp: 40005a3c8ffe ___ 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] fossil --repolist showing no repositories
Thus said "dewey.hyl...@gmail.com" on Thu, 21 Dec 2017 13:40:36 -0500: > * fossil does serve both a repo file and a directory if these files > are copied to a different local directory. Unless things have changed, it is generally not recommended to run Fossil on a non-local filesystem. Andy -- TAI64 timestamp: 40005a3c8d71 ___ 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] fossil --repolist showing no repositories
Thus said Dewey Hylton on Wed, 20 Dec 2017 20:23:23 -0500: > All users have read/write permissions on those files, so this doesn't > make sense (to me) from a Unix permissions standpoint. As Warren asked, what are the permissions on the directory that contains the Fossils? Not only does Fossil need access to the files it is serving, but it needs write access to the directory as the user that it assumes after having chrooted and dropped root privileges because SQLITE will create additional files when the Fossil is used. Andy -- TAI64 timestamp: 40005a3b46fa ___ 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] fossil --repolist showing no repositories
Thus said Warren Young on Wed, 20 Dec 2017 21:02:01 -0700: > Linux containers aren't foolproof when it comes to permission > isolation. Better to not let Fossil have root privs even inside a > container. Fossil does chroot first and then drop root privileges which then changes to the user that owns the directory of fossils (or the fossil repository if serving only one). Andy -- TAI64 timestamp: 40005a3b45c6 ___ 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] Timeline comments ignore all newlines AGAIN...
Thus said sky5w...@gmail.com on Mon, 18 Dec 2017 11:17:49 -0500: > I just compiled fossil version 2.5 [a6c5a4620a] 2017-12-18 02:06:40 > UTC under Windows 10 and nothing(every view option + CSS + Timeline > option) I try shows my commit comment[CR][LF]'s. What CSS and Timeline option are you talking about? Are you talking about this Timeline setting in /setup_timeline? Plaintext comments on timelines In timeline displays, check-in comments are displayed literally, without any wiki or HTML interpretation. Use CSS to change display formatting features such as fonts and line-wrapping behavior. (Property: "timeline-plaintext") If so, what CSS are you using? Thanks, Andy -- TAI64 timestamp: 40005a37f512 ___ 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] Tag problems
Thus said David Mason on Sat, 16 Dec 2017 15:36:51 -0500: > I tried to add a tag to my fossil. After looking at the documentation > which said: The ``fossil tag'' command is for very low-level tag operations. You probably don't want to use it until you understand what it's doing. > 1) -n did not prevent it from running. That would seem to be a bug. If you do actually want to add tags to commits from the command-line you might want to look at ``fossil amend'' instead---it more closely mirrors what is available in the UI: http://www.fossil-scm.org/index.html/help?cmd=amend > 4) There is no mention of a "note" in the documentation. It does say > '?VALUE?' at the end of 'fs help tag' but no indication what it is... > and the word 'value' is used several times, but not referring to it. Again, this requires a deeper knowledge of tags in Fossil. They are much more generic and can be used for interesting things, but probably not what you expect, or want. For more information http://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki#ctrl In your case, you didn't specify any of the ``special'' tags that Fossil recognized, so it simply attached the tag as a ``note'' to the artifact that you specified: http://www.fossil-scm.org/index.html/artifact?ln=2362,2366&name=2668a7564265b469 Andy -- TAI64 timestamp: 40005a35c989 ___ 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] tangent vs. wyoung on recent commti
Thus said Warren Young on Thu, 14 Dec 2017 12:13:18 -0700: > Fossil arguably has a bug here, where if you check a change in as > local user name ``tangent'', as I do here, then *later* do a ``fossil > sync'' to a URL with a user name, some bit of the local on-disk state > remembers that you originally cloned the repo as tangent and makes > your changes under that name. I disagree that this is a bug. I consider it useful flexibility. > I classify this as a bug because it could be used for an impersonation > attack. Fossil records which user synchronized the content in the recvfrom table so the owner of the remote repository knows who did it if he cares. As stated in the past, Fossil is meant for a tighter group of developers---perhaps this perception has changed---one in which impersonation is unlikely. Andy -- TAI64 timestamp: 40005a3415b3 ___ 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] trouble cloning current fossil-scm.org repo with old fossil (2015)
Thus said Warren Young on Mon, 11 Dec 2017 14:53:37 -0700: > To clarify the clarification, ``SHA256'' and ``SHA3-256'' are not the > same thing, though they are sometimes confused. And that is precisely why I called it a major correction. We're not even in the same family of SHA algorithms now. Andy -- TAI64 timestamp: 40005a2f7625 ___ 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] trouble cloning current fossil-scm.org repo with old fossil (2015)
Thus said Richard Hipp on Sun, 10 Dec 2017 19:20:59 -0500: > Minor correction: the hash algorithm changes was from SHA1 to > SHA3-256. I would call that a major correction! I knew something didn't seem right about what I sent... Thanks, Andy -- TAI64 timestamp: 40005a2df05f ___ 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] trouble cloning current fossil-scm.org repo with old fossil (2015)
Thus said Michai Ramakers on Sun, 10 Dec 2017 16:21:02 +0100: > michai@work-lap:/tmp/f/f$ f ver > This is fossil version 1.33 [b00e60194e] 2015-08-22 12:42:15 UTC Since then Fossil has had much development. In this case, the change that is breaking you is that the artifact IDs have changed from MD5 hashes to SHA256 hashes and older versions of Fossil cannot handle them. You'll have to ``bootstrap'' your repo by downloading the source directly from Fossil (zip format) and installing from there: http://www.fossil-scm.org/index.html/zip Or you could get a precompiled: http://www.fossil-scm.org/index.html/uv/download.html Andy -- TAI64 timestamp: 40005a2d6798 ___ 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] Forget large set of changes
Thus said Paolo Bolzoni on Mon, 04 Dec 2017 12:43:19 +0100: > The customer did an update and sent me the new version. This was > unexpected, as I from the discussion we had I understood that I was > pretty much the only one working on that. Fortunately, there were no > conflicts; but once copied the new version the mess started as their > dump changed the order of many files even if the content were > semantically the same. At this point, after having realized that they have now sorted the contents of the files, and, before you committed the newly submitted changes, you could have done, ``fossil revert'' to get your working checkout back to what you're used to. Then, if you know that all the files are going to be sorted, you could run a controlled transform of your files and commit that. Then extract the customer provided new version and if you have matched the sorting algorithm that they are using in their files, then you should have a much smaller commit to deal with from them. It sounds like you already have things under control. Andy -- TAI64 timestamp: 40005a262b24 ___ 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] Forget large set of changes
Thus said Paolo Bolzoni on Fri, 01 Dec 2017 09:18:10 +0100: > What happened is that I got an update of these files and the new > version changed the order of most the keys, but it changed only few > values. However, this changes in the order made the fossil diffs > confusing and large. What do you mean by, ``I got an update of these files?'' Does that mean that someone else committed some changes to your repository and when you did ``fossil update'' you got all their changes? And you want to change them? Or does that mean you made some changes to the working checkout, and committed them? Or does it mean that you made some changes to your working checkout and decided you don't like the changes? > If I could go back, I would store all the files sorted, and here comes > the question. Can I make fossil forget all the changes in dir1? so I > put back them back properly sorted? Yes. You can make fossil ``forget'' those changes, but how that is accomplished depends largely on your answer to my question above. Andy -- TAI64 timestamp: 40005a24dd6f ___ 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] Forget large set of changes
Thus said Paolo Bolzoni on Thu, 30 Nov 2017 12:40:17 +0100: > It worked fairly well until I received an unexpected update of the > original files. I unpacked the new files in dir1 and fossil detected > hundreds of changes; looking better however this changes are mostly > just order changes. Can you give a more concrete example? I'm not sure what you mean by they are ``mostly just order changes.'' What order changed? > So, my problem is... what is the best way to proceed? I can start a > new fossil repository, but I would lose the history in dir2. I can > delete dir1 and recommit the two versions sorted, but it would add > lots of needless changes in the repo again. What exactly are you doing here? How can you lose history of dir2 if the history is committed to Fossil? Again, I think additional details would be helpful. Some fossil and shell commands that show how to reproduce your situation would be useful. Thanks, Andy -- TAI64 timestamp: 40005a2072ee ___ 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] A-B comparison of proposed timeline changes
Thus said Jungle Boogie on Tue, 28 Nov 2017 22:08:58 -0800: > In which mode? I think this is only an issue in the compact mode, > right? Yes, after further experimentation, the problem only exists with the Compact mode. Andy -- TAI64 timestamp: 40005a1fa5b8 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Tue, 28 Nov 2017 22:33:04 -0500: > Maybe "Verbose" should be modified to include the hash up front This was one of the factors that actually lead to my #1 ranking for Verbose. Andy -- TAI64 timestamp: 40005a1e5143 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Tue, 28 Nov 2017 22:08:38 -0500: > Please offer your opinions on: > > https://www.fossil-scm.org/b/timeline I see that you've corrected one of the problems I mentioned previously which was the melding of different comments in the same branch by introducing a small border when viewing in Comapct mode. This does make it more readable. The Columnar option is certainly interesting. I don't think I could learn to like it much, but I can see some usefulness to some. My rankings (1 being the highest rank): 1) Verbose 2) Normal (without rounded edges) 3) Columnar (without rounded edges) 4) Compact My problem with the rounded edges is that in some of the timeline displays they don't look right. Specifically /info pages and other similar timelines: http://www.fossil-scm.org/b/info/59980b6082f7ffe4 http://www.fossil-scm.org/b/timeline?c=2017-11-29+03:41:17 If I need to provide a screenshot, I can do so. Andy -- TAI64 timestamp: 40005a1e5058 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Mon, 27 Nov 2017 21:01:37 -0500: > As it was yesterday: >https://www.fossil-scm.org/fossil/timeline Hard to stomach (as previously mentioned). > Warren Young's new approach: >https://www2.fossil-scm.org/fossil/timeline Slightly better, but still has the annoying ``feature'' that makes highlighting text in a comment a terrible experience. The rounded corners don't seem to look right with the drop-shadow. > Steve Landers' modifications to Warren's approach: >https://www3.fossil-scm.org/site.cgi/timeline Of the three this on definitely looks best, but still has the annoying behavior when highlighting words in the commit message for copy/paste. Also, for a fair comparison, shouldn't there also be a timeline that has the original behaviors? Thanks, Andy -- TAI64 timestamp: 40005a1e4ba6 ___ 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] A-B comparison of proposed timeline changes
Thus said Offray Vladimir Luna C?rdenas on Mon, 27 Nov 2017 18:20:44 -0500: > I agree with Warren's design and improved readability by adding space. > Timeline now has more "air to breath" and is more pleasant to the eye. If you're talking about what is currently visible on http://www.fossil-scm.org/index.html/timeline then I respectfully disagree that it is more pleasant to the eye. I found the original timelines more pleasant precisely because they had more whitespace in them---natural whitespace inbetween comments from variable length comments. Now it all seems a blur. If you're talking about something else, maybe an example would be helpful? Thanks, Andy -- TAI64 timestamp: 40005a1e4998 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Mon, 27 Nov 2017 17:41:55 -0500: > The big down-side is that less information is visible on a single > screen now, so you have to scroll more. But that seems to be the trend > with websites these days There's another extremely annoying downside to this as well---I like to double-click or triple-click to highlight words in commit logs, and now that behavior is extremely unpleasant, if not outright hindered. Clicking anywhere in the commit message, including double-clicks to highlight words makes copy/paste not fun. More $0.02. Andy -- TAI64 timestamp: 40005a1e488b ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Mon, 27 Nov 2017 17:41:55 -0500: > I have installed the new look (temporarily at least) on > https://www.fossil-scm.org/fossil so that we can live with it for a > while to see how we like it. I tend to prefer having more information to less, but the biggest drawback to hiding everything is that now every commit message seems to blend together with all the adjacent commits in the same branch. Before, we at least had all the commit hashes at the beginning of each commit message which served as a natural divider between commits; also there were some links that were underlined (tags, branches, and users) providing some level of distinction between them, but now that this information is hidden, all the comments from a single branch blend together making it difficult to make sense of it all. Just my $0.02. Andy -- TAI64 timestamp: 40005a1e4794 ___ 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] A-B comparison of proposed timeline changes
Thus said Jacob MacDonald on Fri, 24 Nov 2017 18:52:41 +: > Seems like I'm in the minority, but I prefer the A version. I tend to > like compact UIs and having all the relevant information close > together and the commit hash prominently displayed is nice. The only reason why I said that the separate line was cleaner was because it made it easier to find the commit hash. When it is all on one line, I actually prefer the commit hash to be the very first piece of text on the line. This makes everything justified nicely and it's easy to predict where I should place my mouse if I want to copy/paste or click on the hash. If it's in some random place on the line because the ``details'' have been moved to the end of a variable length comment, then I would rather have the ``details'' on a line by itself which preserves the ability to navigate commit hashes easily in the timeline. Andy -- TAI64 timestamp: 40005a1a458d ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Fri, 24 Nov 2017 11:12:14 -0500: > Now fixed. Verified. > Other changes on https://www.fossil-scm.org/b/timeline since the > original comparison request: > > (1) The "details" section is shown on a separate line below the > check-in comment. I just looked and I don't see the ``details'' section on a separate line. Is that intentional? > (2) The "details" are in the same font-color as the comment-text but > have a slightly reduced font size. This seems to me to be an improvement. Andy -- TAI64 timestamp: 40005a1a4495 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Fri, 24 Nov 2017 10:13:22 -0500: > Alternative CSS that causes the "details" to appears on a separate > line from the comment: > > A: https://sqlite.org/src/timeline > B: https://sqlite.org/b/timeline I think it looks slightly cleaner with the ``details'' on a separate line, however, I still miss the Leaf, which I do find useful. Leaving out the node status information does make it read more like prose and look less like a tree structure, however, maybe some don't find it useful to know what kind of a node it is. Andy -- TAI64 timestamp: 40005a184102 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Fri, 24 Nov 2017 09:35:55 -0500: > The change here is to emphasis the check-in comment and de-emphasize > the links to the check-in details and other information. Hopefully this change is simply accomplished with some CSS. That way those who prefer their UI to make text blend in with surrounding colors can do so. :-) Andy -- TAI64 timestamp: 40005a183f98 ___ 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] A-B comparison of proposed timeline changes
Thus said Richard Hipp on Fri, 24 Nov 2017 09:35:55 -0500: > Which is better? > > A: https://www.fossil-scm.org/a/timeline > B: https://www.fossil-scm.org/b/timeline I prefer A. I don't like muted colors for text. I prefer seeing text than to have to look for text that begins to blend with surrounding colors. Andy -- TAI64 timestamp: 40005a183ed0 ___ 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 Report: Cloning with --private Fails
Thus said Martin Vahi on Wed, 01 Nov 2017 17:06:00 +0200: > Neither of the command lines prompted for the password of the user > martin_vahi, which is the admin username at the remote repository. You did not tell Fossil that there is a remote user associated with the repository. This information is in the clone URL. From ``fossil help clone'' you get the following information: Usage: ./fossil clone ?OPTIONS? URI FILENAME Make a clone of a repository specified by URI in the local file named FILENAME. URI may be one of the following form: ([...] mean optional) HTTP/HTTPS protocol: http[s]://[userid[:password]@]host[:port][/path] Notice here that the userid is part of the URL, however, when you cloned, you used: https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/ But you need to use: https://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/ The --admin-user option to clone defines a *local* admin user, not a remote user. Andy -- TAI64 timestamp: 400059fbcb10 ___ 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 Report: Cloning with --private Fails
Thus said Martin Vahi on Mon, 23 Oct 2017 11:27:03 +0300: > It doesn't even prompt for a password. You didn't give it a username for which it should prompt. Try: time nice -n18 fossil clone --unversioned --private --admin-user https://usern...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/ ./repository_storage.fossil Where username is your username that you want to clone with. Or, you need to give the nobody user the right to clone private content. Andy -- TAI64 timestamp: 400059ee9711 ___ 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] web UI for a working checkout?
Thus said Steve Schow on Fri, 29 Sep 2017 15:43:38 -0600: > Who is hosting that and what is the longevity compared to github and > others? Longevity on the Internet seems to be an often nebulous thing. How long was Google Code (code.google.com) around? How long did Source Forge last before people started ditching it? The nice thing about chiselapp.com is that it's really just Fossil. If chiselapp.com dies, you still have your source (assuming you clone and sync with chiselapp.com frequently) and it wouldn't take much to find a new host to put it on. Andy -- TAI64 timestamp: 400059cfe3d8 ___ 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] Amended check-in time
Thus said Richard Hipp on Mon, 25 Sep 2017 16:04:32 -0400: > It does work sometimes, at least: https://fossil-scm.org/fossil/info/1f378f9e3 I've seen it work before too, so I'm not sure why it would be different with the steps Andy Goth provided. Guess it will take some investigation... Andy -- TAI64 timestamp: 400059c9d935 ___ 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] Amended check-in time
Thus said Andy Goth on Mon, 25 Sep 2017 10:45:23 -0500: > Has anyone tried running these commands yet? I want to see if anyone > else can replicate my problem. I just tried and was able to reproduce the problem. It happens on rebuild whether one does it via the ``fossil amend'' command or using the ``fossil ui'' to edit the checkin. Andy -- TAI64 timestamp: 400059c95c75 ___ 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] Amended check-in time
Thus said Andy Goth on Mon, 25 Sep 2017 10:45:23 -0500: > Has anyone tried running these commands yet? I want to see if anyone > else can replicate my problem. Sorry, I misinterpreted your comment about having a bad timezone (except in Narnia) as a retraction of your original problem. And now you've issued a correction... Guess I'll have to try it now. Andy -- TAI64 timestamp: 400059c9590e ___ 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] Strange IP address on repository sync report.
Thus said Andy Bradford on Sat, 16 Sep 2017 11:09:18 -0600: > It might be useful here to also: > > print *p Of course, I meant *ip Andy -- TAI64 timestamp: 400059bd5b14 ___ 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] Strange IP address on repository sync report.
Thus said John Found on Sat, 16 Sep 2017 20:03:16 +0300: > Breakpoint 1, ssl_open (pUrlData=0x55a60c08 ) at > ./src/http_ssl.c:394 > 394 g.zIpAddr = mprintf("%d.%d.%d.%d", ip[0], ip[1], ip[2], ip[3]); > (gdb) p ip It might be useful here to also: print *p Andy -- TAI64 timestamp: 400059bd5ae3 ___ 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] Strange IP address on repository sync report.
Thus said John Found on Fri, 15 Sep 2017 22:16:12 +0300: > I recompiled fossil from the latest trunk version, but without change. Did you run ``make clean'' before rebuilding? Thanks, Andy -- TAI64 timestamp: 400059bd5902 ___ 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] Initial empty checkin?
Thus said Andy Goth on Wed, 16 Aug 2017 10:47:56 -0500: > What of this old thread? Are the issues it discusses still pertinent, > or have they been resolved? I believe all the relevant issues were actually resolved, however, I think it was still unfavorable given the time that was available for testing the changes before release. Personally, I would be in favor of retaining the old behavior by default, but allowing a command line option to ``fossil init'' that would initialize a new repository without it. Andy -- TAI64 timestamp: 400059952b4d ___ 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] Two easy questions
Thus said Steve Schow on Tue, 15 Aug 2017 15:50:39 -0600: > Thanks all for the helpful feedback, I will try to find a solution > outside of fossil. Whatever you end up doing, if possible please report back to the mailing list for the sake of the archive. That way if someone has the same need that you did, they might find your solution feasible for them. Thanks, Andy -- TAI64 timestamp: 40005993ad5a ___ 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] Using fossil across OSes
Thus said jerson on Thu, 27 Jul 2017 10:20:51 +0530: > I've not done anything special. The only commands I use are Can you show more detail about what you're doing? An exact transcript of the commands you're running followed by the errors you get would be much better. I tried your commands one after another and they all behaved as I would have expected. > I am wondering if the case sensitive(linux)/insensitive(Windows 8.3 > filename) could be the cause for this behaviour. That doesn't seem very likely, but without more explicit output, it's hard to say. > I'd really like to be able to update the old files with current > project information. You say you have old files? How old? What files are old? Are they Fossil repositorie? If so, what version of Fossil was used to create the old files? What version of Fossil are you using to update the old files? Thanks, Andy -- TAI64 timestamp: 4000597abf09 ___ 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] Fossil version 2.3 - 10th anniversary edition
Thus said Ross Berteig on Fri, 21 Jul 2017 11:13:47 -0700: > These are tests that failed, but were not expected to fail. They > should be investigated, especially as they did not fail in my builds. It looks like the output is different than what the test expects. For example, with symlinks-dir-6, if I run the command manually, I get: $ fossil extras subdirA/f1.txt subdirA/f2.txt symdirA But the test is expecting: subdirA/f1.txt subdirA/f2.txt symdirA/f2.txt At this point I'm not sure which output is correct. This will take further investigation later I suppose. Andy -- TAI64 timestamp: 4000597267f2 ___ 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] Fossil version 2.3 - 10th anniversary edition
Thus said Ross Berteig on Thu, 20 Jul 2017 11:35:39 -0700: > Well, I missed that target, but I did build and run the test suite > against the tip of trunk, [4872a58b] . > > The only failure was the test pre-commit-warnings-fossil-1. I tested against ae83b2137f and it looks alright I suppose. What are ``Considered failures?'' * Final results: 5 errors out of 34965 tests * Considered failures: symlinks-dir-6 symlinks-dir-11 symlinks-dir-12 symlinks-dir-13 symlinks-dir-16 * Ignored results: 5 ignored errors out of 34965 tests * Ignored failures: merge5-sqlite3-issue stash-1-diff stash-WY-1-CODE stash-3-2 stash-3-2-show-1 Andy -- TAI64 timestamp: 4000597171bd ___ 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] Test message after IP address change
Thus said Richard Hipp on Wed, 12 Jul 2017 06:25:56 -0400: > There are reports that messages are not getting throught to this list > now. The current message is an attempt to reproduce the problem. This is a reply to verify. Andy -- TAI64 timestamp: 400059699f27 ___ 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] warning about unsaved changes with `fossil checkout --keep`
Thus said Natacha Port? on Fri, 07 Jul 2017 09:43:56 -: > (3) "fossil checkout --keep", which is advertised as changing the > "current commit" pointer without touching the working directory, but > bails out of there are unsaved changes. > (4) "fossil checkout --keep --froce", which changes the "current commit" > pointer whithout touching the working directory and accepts to do so > when there are unsaved changes. One must keep in mind that both (3) and (4) will not attempt to merge any changes that you have made to managed files. This means that if you have made significant changes to files that are not the same between the current checkout and the new desired target checkout, then you will end up with a huge diff to figure out. In any event, nothing has been lost. If you discover that you don't like the state of affairs, you can return to where you were by doing fossil checkout --keep --force Again, Fossil will not alter any files at all, but it will show you that there are differences between the version that you are at if there have been edits made to files. > Since "fossil checkout --keep" is not supposed to change the working > checkout, is it rightfully considered dangerous as "fossil checkout" > without flag? Or should the code be updated to have "fossil checkout > --keep" not fail out when there are unsaved changes? Are you suggesting that --keep should imply --force because --keep is non-destructive? Whereas, on the other hand, ``fossil checkout --force'' can be destructive? > So I keep my commit as small as possible while still being a > semantically self-contained unit, so a typical feature spans several > commits. So when developing a feature, I often end up with a working > directory containing changes that are actually a composition of > several future commits. I think keeping your commits as small as possible is fine, however, are those potential future commits a mixed bag of features? If so, why are you also not developing those features in different branches? Perhaps even utilizing multiple checkouts spread over different directories? While Git makes you clone multiple times if you want multiple working checkout directories, Fossil does not, and it makes for a nice workflow if you start taking advantage of multiple open checkouts. > Please consider the following very-simplified situation: > ... > $ fossil commit -m "Helper for the feature" > $ cd ../work2 > $ fossil whatever is needed to make a commit that replaces B with BC > > What is the whatever here? So you've made changes to data.txt in one commit in a different checkout and now in the work2 checkout you have additional, uncommitted, changes that potentially conflict? As you can see: $ fossil commit -m whatever would fork. "update" first or use --allow-fork. So, Fossil knows there are additional changes that haven't yet been merged into your work2 checkout. What you do at this point is your choice. (1) one choice is to commit the change (as I suggested in a different email) using --allow-fork and defer the decision of resolving a merge until later. (2) another choice would be to commit the change to a branch using ``fossil commit --branch newwork'' and again defer the merge until later. (3) you can run ``fossil update'' which might result in a clean merge, or it might result in conflicts to be resolved. If you don't like the conflicts you can bail out using ``fossil undo'' as Richard suggested. Here's 3: $ fossil up MERGE data.txt * 1 merge conflicts in data.txt --- updated-to: 2857ae3ebc14c271613d2e43207f3145daaaf3c8 2017-07-08 03:52:00 UTC tags: trunk comment: Helper for the feature (user: amb) changes: 1 file modified. WARNING: 1 merge conflicts "fossil undo" is available to undo changes to the working checkout. Yep, there's a conflict. Now what? Well, undo if you don't like it, or begin fixing the conflicts. Open data.txt and you'll see this: <<< BEGIN MERGE CONFLICT: local copy shown first <<< BC === COMMON ANCESTOR content follows 9 === MERGED IN content follows == B >>> END MERGE CONFLICT > You said you wanted BC, so remove all lines except the line that says BC. Then commit that change and you have resolved the conflict. But, if you don't like that approach, and instead decide to undo, then you can try to use ``fossil checkout'' as you suggested, but then find that Fossil wants either --keep or --force because there are local changes. You want to preserve them, so you use --keep: $ fossil checkout --keep 2857ae3ebc there are unsaved changes in the current checkout You decide to use --keep and --force together, to switch to the checkout where you added the Helper
Re: [fossil-users] warning about unsaved changes with `fossil checkout --keep`
Thus said Natacha Port? on Thu, 06 Jul 2017 19:30:29 -: > Now imagine you leave things as they are after (3) to do some non-dev > stuff (or some dev on other repositories), and you receive a serious > windows-specific bug report. You drop everything to work on it, > forgetting the "fossil up". You eventually make a fix in some code path > that is never reached on Linux, or for another reason you decide to > commit straight away. First, will you provide a minimal working transcript of the problem you're encountering? Did you first create a new clean working checkout for your serious windows-specific bug? Something like: mkdir /path/to/newbugcheckout cd /path/to/newbugcheckout fossil open /path/to/repository.fossil Make all your changes there so you don't taint your current working checkout. If you didn't do this, I highly recommend this practice. > So I really missed a way of asking fossil to just commit the files as > they were but with another parent than what was currently recorded as > the current commit. How? Is it not possible to just commit them against the checkout against which such precious data was generated; that presumably was good before you started generating new and uncommitted precious data, no? Or did you start on a given commit (say 1), generate some new and precious data without committing, and then decide to jump into other work, perhaps less precious, commit just those things (perhaps repeatedly), and then now you're at commit 10 and you decide you want to commit your precious data? In that case, cannot you just do ``fossil update 1'' and then commit the precious data? You'll have a fork, but you can work out the details later if the goal is to get the precious data committed. I'm not sure why this would ever result in conflicts, or the inability to merge and commit the data. Thanks, Andy -- TAI64 timestamp: 4000595ea731 ___ 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] Tech-note timeline commits
Thus said jungle boogie on Tue, 04 Jul 2017 15:03:01 -0700: > Now I greatly prefer the former, because when copying the hash with > the mouse, I can skip the closing (]) bracket, since I usually start > right-to-left. Not to derail your comments, but... Personally, I think that this is a flaw in web browsers and that they need to be improved to allow you to copy text from anywhere within an anchor tag instead of only allowing you to click it (or some other link-type action). There are many times when I would like to highlight text that is part of a hyperlink but have to finagle it in some fashion. Andy -- TAI64 timestamp: 4000595c6902 ___ 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] test-comment-format utf8
Thus said Stephan Beal on Thu, 15 Jun 2017 09:55:11 +0200: > Sidebar: i had no idea bash can do ranges like that! I usually use jot: $ echo $(jot -w '%c' 26 a) a b c d e f g h i j k l m n o p q r s t u v w x y z $ echo $(jot -w '%c' 26 a | sort -r) z y x w v u t s r q p o n m l k j i h g f e d c b a $ echo $(jot -w '%c' 26 A) A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Andy -- TAI64 timestamp: 400059449a86 ___ 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] Improvements to the /reports page
Thus said Roy Keene on Wed, 07 Jun 2017 10:45:27 -0500: > I would benefit from some improvements to the /reports page, such as > the ability to restrict the dates upon which are being reported and > the ability to restrict the report to certain tags. That sounds like it would be useful to others. Currently, the only report that allows restricting the date is the By Week report. It looks like this particular change would also restrict all results by those boundaries. It looks like if I give it an endpoint (a or b) that doesn't resolve to something it defaults to returning the entire range of data. Intended? I don't see why improvements would not be merged, though you might find more interest in such changes on the fossil-users mailing list. Andy -- TAI64 timestamp: 4000593a0e76 ___ 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] Is it possible to merge repository's?
Thus said The Tick on Mon, 29 May 2017 22:35:31 -0500: > From this I gather that there would be no way to connect the imported > repository onto the main trunk. That was not what I was hoping for. You're correct, you would have 2 trunks. Andy -- TAI64 timestamp: 4000592dd034 ___ 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] Is it possible to merge repository's?
Thus said Stephan Beal on Tue, 30 May 2017 02:57:38 +0200: > However, there is _hypothetically_ a way to completely merge 2 repos > into one while keeping all commits, but i'm not at all certain if this > would work... I think it actually will work for some definition of ``work''. I've done it before. But... it depends on what one expects out of it. There will be 2 separate and independent timelines once reconstructed and there will not be a relationship between artifacts except for the fact that they all live in the same Fossil file. Andy -- TAI64 timestamp: 4000592ce763 ___ 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] [8c22e1bbcd8ec048] Regression: "fossil amend" no longer works unless operating from within an open checkout
Thus said fos...@rkeene.org on Thu, 25 May 2017 23:42:22 -0500: > Why is the check-out directory considered at all ? My guess is that it was an expedient fix to prevent a segfault. I agree with you that Fossil shouldn't care about whether or not the repository is open and just choose a suitable location for the file. If the repository is open, use the working check-out directory for the temporary file, otherwise use an appropriate TMP location. Andy -- TAI64 timestamp: 40005927b840 ___ 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] [8c22e1bbcd8ec048] Regression: "fossil amend" no longer works unless operating from within an open checkout
Thus said Roy Keene on Thu, 25 May 2017 21:17:15 -0500: > Given that this worked, why was it broken ? And can the error message > be converted to something that is actually coherent ? And can it be > unbroken ? Apparently it was broken intentionally because there was a segfault that happened when using ``fossil amend -R repo.fossil -e'' outside an open checkout: http://marc.info/?t=14897952902&r=1&w=2 Is there a reason why one shouldn't be able to use amend outside an open check-out? One alternative would be to simply disallow interactive edits outside an open checkout: http://www.fossil-scm.org/index.html/info/afef5fb5fc49fdd9 However, perhaps this could be improved by detecting whether there is an open check-out here: http://www.fossil-scm.org/index.html/artifact?ln=1209-1210&name=237694d101bab9bc And if there is no open check-out use unixTempFileDir to locate a suitable location and put the file there? Or maybe file_relative_name should actually try to handle a NULL file path and simply treat that as ``current working directory'' and make it relative to . rather than fail? Thoughts? Andy -- TAI64 timestamp: 40005927a824 ___ 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] [8c22e1bbcd8ec048] Regression: "fossil amend" no longer works unless operating from within an open checkout
Thus said Roy Keene on Thu, 25 May 2017 21:26:50 -0500: > The fossil checkin I linked to ([8c22e1bbcd8ec048]) has the change in > src/info.c that enforces this for all cases. Yeah, I think you already said that and somehow I missed it. I wonder why this was introduced... Andy -- TAI64 timestamp: 4000592794b9 ___ 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] [8c22e1bbcd8ec048] Regression: "fossil amend" no longer works unless operating from within an open checkout
Thus said Roy Keene on Thu, 25 May 2017 21:17:15 -0500: > Attempts to add tags to a repository using "-R" now returns an engrish > error message: The engrish error message has been addressed, however, it does look like somewhere the behavior has changed. I gave it a valid UUID and it still gives me the error. Andy -- TAI64 timestamp: 400059279380 ___ 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] [8c22e1bbcd8ec048] Regression: "fossil amend" no longer works unless operating from within an open checkout
Thus said Roy Keene on Thu, 25 May 2017 21:17:15 -0500: > $ fossil amend -R ~autobuild/aurae.fossil --tag build-pass --tag > tests-fail > the "amend" command only work from within an open check-out What particular checkin are you trying to amend here? Seems like the error really should be a usage statement. Try: fossil amend -R ~autobuild/aurae.fossil UUID --tag build-pass --tag tests-fail Where UUID is the checkin that you want to amend. Andy -- TAI64 timestamp: 4000592791c4 ___ 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] Apparently a bug in ticketing
Thus said Doug Franklin on Wed, 24 May 2017 17:09:52 -0400: > Sorry, Andy, that was me not being clear. I should've put "user > comment" in quotation marks because I was talking about the field on > the form labeled "User Comment". It was three tickets created by one > user (there's only one actual user, me), one right after the other. > I'll rephrase to be more clear: Or I was not reading clearly. :-) I'm not sure how this could happen. Did you have multiple tabs open to the same ticket interface?k Also, with regards to sharing the repo... it would help if we actually thought the problem was in the repository itself. At this point it's hard to say. I think looking at the repo would simply confirm your observations (that the comments are somehow not in the place that you expected them) and that there isn't a ticket where you expected there to be one. If you can reproduce it, perhaps a video showing all your commands or interactions with the UI would also reveal something? Andy -- TAI64 timestamp: 40005926331d ___ 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] Apparently a bug in ticketing
Thus said Doug Franklin on Mon, 22 May 2017 18:32:00 -0400: > 11. Oops. I don't have three tickets. I have two tickets. The first > ticket is fine. The original second ticket seems to be gone (it's not > in the "All tickets" list), and the current second ticket has all of > the values of the third ticket, but it has the user comment from the > original second ticket as its first user comment, and the comment > entered for the third ticket as its second user comment. Also, regarding the differing users. How is this possible? Are you logging into Fossil UI using more than one user? What are you doing to create tickets using multiple users? These facts were not mentioned in steps 4--10. Andy -- TAI64 timestamp: 40005924e040 ___ 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] Apparently a bug in ticketing
Thus said Doug Franklin on Mon, 22 May 2017 18:32:00 -0400: > 11. Oops. I don't have three tickets. I have two tickets. The first > ticket is fine. The original second ticket seems to be gone (it's not > in the "All tickets" list), and the current second ticket has all of > the values of the third ticket, but it has the user comment from the > original second ticket as its first user comment, and the comment > entered for the third ticket as its second user comment. I haven't been able to reproduce it following your steps (though, I did not add 89 timeline entries). Andy -- TAI64 timestamp: 40005924dfb5 ___ 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 Report or a Feature Request: Cope with Hosting Providers' Watchdogs
Thus said Martin Vahi on Tue, 16 May 2017 22:43:07 +0300: > Are there any "heart-beat" options available, wher a cron job might > call something like No, however, there are options to control how much Fossil will sync in a single round-trip. Fossil does synchronize individual artifacts in batches and all artifacts that are sent/received in a single round-trip are committed (in the RDBMS sense of the word) to the repository, so if your connection drops, or your hosting provider limits process time, you don't have to resynchronize those parts that were already successfully synchronized. Some of the settings that control how much data is sent in a round-trip (or how much time is permitted) are: max-download (server) max-download-time (server) max-upload (client) You can get to the server settings using the /setup_access page on your server. You can get to the client settings from the command line (or using fossil ui on your workstation). Of course, if the size of your artifacts is greater than these settings it may not help as much. From the output that you sent, it looks like maybe your artifacts are quite large so you won't be able to take advantage of these settings: > mishoidla/sandbox_of_the_Fossil_repository$ fossil push --private > Push to https://martin_v...@www.softf1.com/cgi-bin/tree1/ > technology/flaws/silktorrent.bash/ > Round-trips: 1 Artifacts sent: 0 received: 0 > server did not reply > Push done, sent: 651648435 received: 12838 ip: 185.7.252.74 Andy -- TAI64 timestamp: 4000591b78f8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to transfer/move/upload local repository to chiselapp.com
Thus said The Tick on Sun, 14 May 2017 17:19:21 -0500: > What is the status of chiselapp.com and is it a viable place to put an > open source repository as of 2017? As far as I know it is still viable. Andy -- TAI64 timestamp: 400059193379 ___ 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] Problem with: fossil revert -r xxx
Thus said Ross Berteig on Wed, 10 May 2017 21:35:12 -0700: > But in my experience, fossil revert is a rarely used command. I use revert quite frequently to abandon changes I don't want anymore. I don't often use it with -r though. Andy -- TAI64 timestamp: 400059146dec ___ 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] Limiting cruft in my repos
Thus said David Mason on Wed, 10 May 2017 01:07:22 -0400: > If the students were very disciplined, they would assiduously edit > ignore-glob to prevent this. But if there is one thing that students > (en-mass) are not, it's disciplined! Do students generate their own Fossil, or is the Fossil generated for them? If it is generated for them, why not just commit an ignore-glob that covers the kinds of large files they are likely to generate to the .fossil-settings directory? Andy -- TAI64 timestamp: 400059131ac8 ___ 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] Couple of beginner questions
Thus said The Tick on Thu, 30 Mar 2017 14:35:22 -0500: > Goodness! All I wanted was to have a comment contain a copyright > character. Did you see my response? You could have continued on the way you were doing things. No need to change anything except tell your browser that the content is not Unicode, but is instead ``Western'' or ISO-8895-1 or something else. Andy -- TAI64 timestamp: 400058deb146 ___ 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] Couple of beginner questions
Thus said The Tick on Wed, 29 Mar 2017 15:47:32 -0500: > If I edit the file, of course the utf-8 copyright symbol is garbled. > Furthermore, there is no way I can insert a utf-8 character. My editor (nvi) allows me to insert UTF-8 characters by typing the ASCII character, then by pressing ctrl-x followed the 2-digit value 00 (for a null byte). > You can copy and paste the "Peggle®" and paste it into notepad. When you > save the file, you will see that the "registered" character is a single > character with the hex value \xAE. The problem here is not one of ``which character is this?'' but rather one of ``which encoding should be used to render the character visible?'' \xAE is not ASCII. ASCII ranges from \x00 to \x7f, but only \x20 to \x7e are ``printable'' characters. That being said, if you want to make your browser show you the character correctly, you need to tell your browser that the data it is viewing is not UTF-8 (the likely default). I added a file to a test repostory that had a single \xAE character in it. Then I ran fossil server and looked at the file in my browser. It showed up as a circle with ? inside because it didn't know what to do with it. So I then clicked on View->Text Encoding->Western and magically, and instantaneously, that broken character now shows up as it should. Andy -- TAI64 timestamp: 400058dc768b ___ 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] Couple of beginner questions
Thus said Warren Young on Wed, 29 Mar 2017 14:25:34 -0600: > Any text editor or compiler that can't cope with UTF-8 in 2017 is > broken or can be ignored. I rarely use any editor but nvi. It doesn't support UTF-8. Here is what utf16le.txt (from Fossil test directory) looks like to me: \xff\xfeT^@h^@i^@s^@ ^@f^@i^@l^@e^@ ^@c^@o^@n^@t^@a^@i^@n^@s^@ ^@u^@t^@f^@-^@1^@ 6^@l^@e^@ ^@t^@e^@x^@t^@.^@ Usually when I see a file like this, I just do: tr -d \\000 < utf16le.txt > newutf16le.txt Then I remove any BOM that might exist because who needs it? Now I see: This file contains utf-16le text. Do I need UTF-8? Not really. I don't even have a keyboard that can produce any UTF-8 characters; except those which overlap with ASCII, and even then, they are only 1 byte characters anyway. You can claim that nvi is broken or can be ignored, but I still use it, and don't see a good reason to stop using it (UTF-8 support is not high on my list of reasons to change to a new editor). I cannot stand vim. Maybe one day nvi will have UTF-8 support, but I'm not counting on it any time soon. :-) Andy -- TAI64 timestamp: 400058dc738a ___ 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] [PROPOSED FEATURE] Fossil commands output sent through a pager
Thus said Warren Young on Mon, 27 Mar 2017 10:21:42 -0600: > Explain to me how someone deciding between Fossil and Git gets down to > automatic pagination as the key differentiator, the one that seals > their decision. While it may not be used as a determining factor in deciding between Git and Fossil, it most certainly is a confusing factor for people who have never used a pager before. I cannot recall how many times I have had to tell people that to exit the pager they can press q. Or how many times I have had to tell them that they cannot use the mouse to scroll through the output because the pager doesn't work that way. Or how to search through the output because ctrl-f doesn't work, etc. Andy -- TAI64 timestamp: 400058d9c0c2 ___ 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] [PROPOSED FEATURE] Fossil commands output sent through a pager
Thus said Roy Keene on Thu, 23 Mar 2017 17:36:37 -0500: > I vote that the pagination be off by default to preserve the existing > behaviour -- terminals have been able to scroll for decades now so I > don't know why systemd/git like to do this by default but it is REALLY > annoying having to pipe EVERYTHING through "cat" to defeat it. I'll add my voice to this as well and it's not just to preserve existing behavior. I think git's default (is it even configurable with git?) to automatically page everything is one of its most annoying features. If I want a pager, I'll pipe it to a pager. Otherwise, just dump it to my terminal, thank you. Andy -- TAI64 timestamp: 400058d74d80 ___ 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] Crash with this AMEND command
Thus said "Tony Papadimitriou" on Sat, 18 Mar 2017 01:59:21 +0200: > The following command crashes fossil (older and up to current > version). It doesn't crash for me. Can you be more specific as to which version? Also, which OS? Thanks, Andy -- TAI64 timestamp: 400058ce1e81 ___ 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] The SHA3 transition as firewall
Thus said Warren Young on Thu, 09 Mar 2017 13:37:35 -0700: > On Mar 9, 2017, at 1:03 PM, Richard Hipp wrote: > > > > If a new artifact Y' which has the same SHA1 hash as Y comes along, > > it will be discarded, since an artifact with that same hash is > > already in the repository. > > That can be gotten around with a MITM attack, as I've already brought > up several times on the list. Many Fossil instances won't have TLS > protection against MITM attacks, and those that do have it may be > weakened by some well-intentioned TLS-busting middlebox or antimalware > package. How? If the server to which the attacker tries to synchronize content already has Y, there is no way for the attacker to push Y' to the repository. Or are you suggesting that the attacker is not trying to push content into the repository, but is instead, trying to trick the client into pulling Y' when he wanted Y? Andy -- TAI64 timestamp: 400058c1bebc ___ 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] spam after posting to the list
Thus said Richard Hipp on Sun, 05 Mar 2017 11:33:57 -0500: > I got rid of the spam from Eboni by blocking the following IP addresses: > > 144.217.94.196 > 144.217.165.151 > 2607:5300:201:3000::/64 Thanks. I checked my block list and apparently those are not on it. But I don't routinely get spam when I send emails to this ML so I wonder why... This email is primarily a test to see if I get any spam before I add those IPs to my list. No response needed. Thanks, Andy -- TAI64 timestamp: 400058bf0f46 ___ 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] Longest gap between check-ins
Thus said Rolf Ade on Wed, 22 Feb 2017 00:16:40 +0100: > SELECT count(*) FROM event > WHERE type = 'ci'; > > returns 10324. But after a > > fossil ui > > http://localhost:8080/timeline?n=11000&y=ci > > shows only 10285 check-ins. Try: http://localhost:8080/timeline?n=11000&y=ci&unhide And also: http://localhost:8080/stat Andy -- TAI64 timestamp: 400058ad0657 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users