Re: [fossil-users] clone a repository over ssh where the path includes whitespace characters

[Andy Bradford]

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=203=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] Fossil update

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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'

[Andy Bradford]

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'

[Andy Bradford]

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=225-227=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'

[Andy Bradford]

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'

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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.

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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?

[Andy Bradford]

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.

[Andy Bradford]

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

[Andy Bradford]

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?

[Andy Bradford]

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?

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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?

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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)

[Andy Bradford]

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)

[Andy Bradford]

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)

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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?

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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.

[Andy Bradford]

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.

[Andy Bradford]

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.

[Andy Bradford]

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?

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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`

[Andy Bradford]

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`

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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?

[Andy Bradford]

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?

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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

[Andy Bradford]

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=ci
> 
> shows only 10285 check-ins.

Try:

http://localhost:8080/timeline?n=11000=ci

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

Re: [fossil-users] Longest gap between check-ins

[Andy Bradford]

Thus said Richard Hipp on Mon, 20 Feb 2017 10:39:09 -0500:

> Now remind me again, how would you do this in Git? ;-)

To get these kinds of reports  I import my Git repositories into Fossil.
:-)

Andy
-- 
TAI64 timestamp: 400058ab1b40


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