[fossil-users] Cloning repo

2014-10-03 Thread Jacek Cała 
Hi all,

I've noticed an unexecpected behaviour in fossil when doing a clone. The
issue appears when you try clone with a wrong user name and as the result
an empty repo is created. I'd rather expect an error on the console and
nothing else.

The thing is fully reproducible with the latest windows binaries (see
below, when asked just type any random password). Even more unexpectedly
you can try doing this on http://myfakeu...@www.fossil-scm.org/

I'm not sure why failing to login to fossil-scm still clones the repo or
why failing to my repo creates an empty repo. Is this by design?

  Best,
  Jacek

> fossil clone http://myfakeu...@egenome-fossil.cloudapp.net/e-Genome
repo.fossil
password for MyFakeUser: **
remember password (Y/n)? n
Round-trips: 2   Artifacts sent: 0  received: 0
Error: login failed
password for MyFakeUser: *
remember password (Y/n)? n
Round-trips: 3   Artifacts sent: 0  received: 0
Error: login failed
Round-trips: 3   Artifacts sent: 0  received: 0
Clone finished with 907 bytes sent, 865 bytes received
Rebuilding repository meta-data...
  100.0% complete...
project-id: 0f5ea9d3c8bb48d8de1f1075b62026a6c7538d1e
admin-user: MyFakeUser (password is "6af0d9")
> dir
04/10/2014  06:3958,368 repo.fossil
___
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] Pessimism about CommonMark in fossil

2014-10-03 Thread Ron W 
On Fri, Oct 3, 2014 at 2:01 PM, Stephan Beal  wrote:

> Note that wiki links are generated in many places, most notably the
> timeline, and if those links also have to work or the solution is only a
> partial one.
>
I think an example of what I mean would be helpful.

If I go to the  New Wiki Page page or Edit Wiki Page page, then put the
following as the content:

 
 BEGIN_ASCIIDOC
 *this* is a sample of *asciidoc*
 END_ASCIIDOC
 

Then when I click any Fossil generated link to that wiki page, Fossil will
serve up:

 BEGIN_ASCIIDOC
 *this* is a sample of *asciidoc*
 END_ASCIIDOC

Then if I have suitable JS code, it can look for BEGIN_ASCIIDOC and
END_ASCIIDOC, then feed everything between those 2 line to asciidoc.js

While that works, from a user point of view, it is very kludgy.

A step better would be if Fossil could accept something like:

 
 *this* is a sample of *asciidoc*
 

Then serve up something like:

 
 *this* is a sample of *asciidoc*
 

This would be less kludgy and maybe even have better/simpler JS code to
find the content and feed it to the renderer.

I don't know whether this would require a new change to Fossil or if Joe's
custom page feature could handle this. And, hopefully, there will be at
least 1 way to make this even less kludgy.
___
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] Quiet mode for update and sync

2014-10-03 Thread Andy Bradford 
Thus said David Mason on Fri, 03 Oct 2014 12:49:17 -0400:

>  3) It seems like a lot more overhead, compared to a local run of fossil

I'm not  sure why  you need  to parse anything.  Here is  a low-overhead
script that detects updates to a remote repository:

#!/bin/sh
OLD=$HOME/old.rss
NEW=$HOME/new.rss
touch $OLD
curl -s 'http://www.fossil-scm.org/index.html/timeline.rss?y=ci&tag=trunk' | 
sed -e '/pubDate/d' > /tmp/new.rss
diff $OLD $NEW >/dev/null || {
  cp -f $NEW $OLD
  echo new check-ins on trunk
  exit 0
}
echo no new check-ins on trunk
exit 1

But, this raises the question... if you're just trying to determine when
to  update, why  not  just  run ``fossil  update''  on  a schedule?  You
mentioned that fossil knows when it has  ``work to do'' but I'm not sure
I understand exactly what you mean by it. Fossil certainly knows when it
should transfer content from the remote  side to the local side and vice
versa.  It also  knows  when it  should merge  files  into your  working
checkout (because fossil update causes this to happen).

Here was the original example:

fossil update -q && fossil update 2>&1 | mail -s 'Fossil update' m...@he.re

Are you simply looking for a way to be notified via email when there are
changes that  have been  updated into  your working  checkout? If  so, I
think the above script could be substituted for ``fossil update -q'':

shouldiupdate.sh && fossil update 2>&1 | mail -s 'Fossil update' m...@he.re

Andy
--
TAI64 timestamp: 4000542ee560
___
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] Pessimism about CommonMark in fossil

2014-10-03 Thread Stephan Beal 
Note that wiki links are generated in many places, most notably the
timeline, and if those links also have to work or the solution is only a
partial one.

(sent from a mobile device - please excuse brevity, typos, and top-posting)
- stephan beal
http://wanderinghorse.net
On Oct 3, 2014 6:02 PM, "Ron W"  wrote:

> On Fri, Oct 3, 2014 at 11:18 AM, Stephan Beal 
> wrote:
>
>> On Fri, Oct 3, 2014 at 4:56 PM, Gour  wrote:
>>
>>> OK, no problem. I, somehow, thought that teaching Fossil to just render
>>> using JS in the browser should not be so hard...
>>>
>>
>> It can do so already, but...
>> ...
>> c) there isn't currently a mechanism which would allow wiki-generated and
>> such to integrate with that, so it requires a completely custom front-end.
>> The core only knows about one type of wiki like, and would send all
>> generated links to the built-in wiki rendering mechanism.
>>
>
> It could be as simple as a  tag that Fossil treats the same as
>  with the addition of wrapping the raw wiki content with a  class="rawWiki"> or similar.
>
> Maybe Joe's new feature can help with this. Did not have a chance to look
> at it as my field trip got extended.
>
> While some JS would be needed, I think the foundation could be fairly
> simple: Find the div then feed its content to the user's chosen renderer.
>
> The main potential complication being that the contained wiki mark-up
> might confuse the browser's HTML parser. But, I would think that a mark-up
> that has a browser-based renderer (JS, Java or other) would already address
> this issue.
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Tab stop width

2014-10-03 Thread Martijn Coppoolse 

Stephan Beal schreef op 1-10-2014 19:48:

More info, for those interested:

http://www.w3schools.com/cssref/css3_pr_tab-size.asp

apparently MSIE doesn't support it, but that table might simply be out
of date.


http://caniuse.com/#feat=css3-tabsize

(CanIUse.com is usually better up to date than w3schools).
--
Martijn Coppoolse
___
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] Quiet mode for update and sync

2014-10-03 Thread David Mason 
On 3 October 2014 12:25, Andy Bradford
 wrote:
> Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400:
>
>> I want  a script to run  every 5 minutes  and if there is  any update,
>> email me the update  log. But I don't want email  every 5 minutes that
>> just  says everything  is up  to  date. I  can figure  out using  file
>> timestamps etc. if an update is necessary, but that's pretty ugly.
>
> Why  not use  Fossil's RSS  feed feature  to detect  changes?

I looked at it.  3 reasons present themselves to me:

1) I may not be running a server (I'm not right now... this may change).

2) I'd have to parse the XML, at least minimally.  It looks like I can
parse the "fossil stat" to find the current  checkout and then look
for that in the output of:
http://localhost:8080/XXX/timeline.rss?y=ci&n=1&tag=trunk
but that seems kind of kludgey

 3) It seems like a lot more overhead, compared to a local run of fossil

That said, if the powers that be (PTB) don't like the idea, rss does
provide a fallback, thanks.

../Dave
___
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] Quiet mode for update and sync

2014-10-03 Thread Andy Bradford 
Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400:

> I want  a script to run  every 5 minutes  and if there is  any update,
> email me the update  log. But I don't want email  every 5 minutes that
> just  says everything  is up  to  date. I  can figure  out using  file
> timestamps etc. if an update is necessary, but that's pretty ugly.

Why  not use  Fossil's RSS  feed feature  to detect  changes?

Andy
--
TAI64 timestamp: 4000542ece22
___
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] Pessimism about CommonMark in fossil

2014-10-03 Thread Ron W 
On Fri, Oct 3, 2014 at 11:18 AM, Stephan Beal  wrote:

> On Fri, Oct 3, 2014 at 4:56 PM, Gour  wrote:
>
>> OK, no problem. I, somehow, thought that teaching Fossil to just render
>> using JS in the browser should not be so hard...
>>
>
> It can do so already, but...
> ...
> c) there isn't currently a mechanism which would allow wiki-generated and
> such to integrate with that, so it requires a completely custom front-end.
> The core only knows about one type of wiki like, and would send all
> generated links to the built-in wiki rendering mechanism.
>

It could be as simple as a  tag that Fossil treats the same as
 with the addition of wrapping the raw wiki content with a  or similar.

Maybe Joe's new feature can help with this. Did not have a chance to look
at it as my field trip got extended.

While some JS would be needed, I think the foundation could be fairly
simple: Find the div then feed its content to the user's chosen renderer.

The main potential complication being that the contained wiki mark-up might
confuse the browser's HTML parser. But, I would think that a mark-up that
has a browser-based renderer (JS, Java or other) would already address this
issue.
___
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] Pessimism about CommonMark in fossil

2014-10-03 Thread Stephan Beal 
On Fri, Oct 3, 2014 at 4:56 PM, Gour  wrote:

> > That was unfortunately a bit optimistic of me (i tend towards
> > pessimism in most estimates ;), for which i apologize. Wiki topics in
> > general are way, way, way down on my list of eventual todos.
>
> OK, no problem. I, somehow, thought that teaching Fossil to just render
> using JS in the browser should not be so hard...
>

It can do so already, but...

a) it requires the JSON API (which is not on be default) because core
fossil will try to parse the wiki pages for you, whereas the JSON API
provides an option to serve raw (unparsed) wiki pages.

b) the client needs to provide his own JS, set it up in his repo header,
etc.

c) there isn't currently a mechanism which would allow wiki-generated and
such to integrate with that, so it requires a completely custom front-end.
The core only knows about one type of wiki like, and would send all
generated links to the built-in wiki rendering mechanism.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Pessimism about CommonMark in fossil

2014-10-03 Thread Gour 
On Thu, 2 Oct 2014 16:07:56 +0200
Stephan Beal  wrote:

> That was unfortunately a bit optimistic of me (i tend towards
> pessimism in most estimates ;), for which i apologize. Wiki topics in
> general are way, way, way down on my list of eventual todos.

OK, no problem. I, somehow, thought that teaching Fossil to just render
using JS in the browser should not be so hard...


Sincerely,
Gour

-- 
Not by merely abstaining from work can one achieve freedom 
from reaction, nor by renunciation alone can one attain perfection.


___
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] Quiet mode for update and sync

2014-10-03 Thread David Mason 
Ah, yes; I forgot about autosync (I'm new to actually using fossil),
but I don't think it's a flaw (see below).

On 3 October 2014 01:21, Stephan Beal  wrote:
> On Thu, Oct 2, 2014 at 3:35 PM, David Mason  wrote:
>> fossil update -q && fossil update 2>&1 | mail -s 'Fossil update'  
>> m...@he.re
>
> i've been mulling over this, and there's one fundamental flaw here: if
> auto-sync is on (which it is by default), then fossil does not know if
> there's work to be done until after it has done the network sync. In the
> above operation, it would sync twice, _potentially_ with different results
> for each (classical race condition). Having the hypothetical -q option
> disable/bypass autosync doesn't seem like a solution because then its
> result could very well differ from that of the second update (which
> would sync, if enabled).
>
> When autosync is off, that wouldn't be a problem, but it is on by default
> and is highly recommended to avoid unintended forks (the reason it's
> turned on by default, IIRC, was unintended forks in fossil itself early on
> in Fossil's history).
>
> Suggestions for an alternative approach, or concrete semantics, are
> welcomed.

If autosync is on and remote-url is on, then update -q should do the
sync, and then check if there is work to do.  Of course, if there are
changes, but not on the branch the update refers to, then it returns
false (this allows for e.g. an "in-production" branch).

4 points:

1) in my use case, this is the "master" repository, so has remote-url
off so this isn't an issue.

2) this update will run every ?5? minutes,so if the update -q misses a
change that the second update would get, it's no biggy... 5 minutes
later will do fine (my alternative solution of checking timestamps
wouldn't do any better)

3) if the second update finds more to do because of the second
auto-sync, so much the better... and if not, the second autosync is a
bit of extra network traffic, but again, no biggy

4) autosync on update actually obviates the need for the -q switch on
sync (and as I think it through, sync doesn't need it anyway as either
it found nothing to do in which case the update would have found
nothing to do, or it changed things in which case the update would see
the change (or not if the changes were to another branch))

Hope that is clear.

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

[fossil-users] friendly reminder: submitting tickets to Fossil

2014-10-03 Thread Stephan Beal 
Hi, all,

A friendly reminder, prompted by this morning's round of ticket
moderation...

The following is copy/pasted from the top of the ticket submission page (
http://www.fossil-scm.org/index.html/tktnew):


*Discuss your issue on the fossil-users mailing list

first. Tickets
for issues that have not previously been discussed on the mailing list are
very likely to be deleted without comment and without consideration.*


So please don't be surprised if one or more of your submissions has been
mysteriously deleted.

Now the justification, for those who like that kind of thing...

In the scope of the Fossil project, the majority of tickets tend to fall
into one of the following major categories:

a) misunderstands or user error which are easily resolved via a mail
thread. Such cases are sometimes caused by lack of (or sub-par)
documentation, and posting it to the list ensures that more developers will
see it, increasing the chances that it will get resolved and increasing the
number of eyes on it (which tends to lead to better solution).

b) New feature ideas and RFEs (Requests For Enhancements). Many times
simply suggesting a new feature is enough to get it integrated, sometimes
even on the same day. (We don't think of all features by ourselves, and
quite rely on newcomers to suggest things which have so far been
overlooked!) Larger feature ideas should be filtered through the list
first, as many suggestions are either not feasible (or are unduly
difficult) for architectural or project-level philosophical reasons, or are
simply deemed out of scope for the project. Sometimes a new feature idea
justifies a ticket, but in practice we tend to use the mailing lists to
post/follow development of major new features.

c) "True bugs," i.e. broken behaviour. Posting to the mailing list will
ensure a much quicker response than a ticket will, as all of us subscribe
to the mailing list, but we do not all go and check the ticket list very
often. (Other than via the ticket moderation queue, i very rarely go
through the ticket list.)

To be clear: we're NOT saying "don't report problems and feature requests,"
we're just asking that you do so on the mailing list(s) first, and
following up with a ticket only if requested to by one of the developers
(you'll know they're a developer if they ask you to submit a ticket ;). In
practice (for this particular project), this works out better for both the
reporter and the developers.

One final hint: after submitting a ticket, it's a good idea to post a link
to it back to the mailing list thread it originated from. This assists,
among other things, users searching through the mail archives (or their own
mail clients).

Disclaimer: the above applies only to the Fossil project, and is not
intended to imply any rules/guidelines/best practices for other projects.


Thanks once again for your continued input and support, and Happy Fossiling!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users