Re: [fossil-users] Using fossil with Golang (go get)

[Mark Janssen (fossil)]

On 2018-06-18 23:42, Zack Scholl wrote:

Hi Mark,

The meta tag

 

will not work for importing Go code. The first term needs to match the
import path, e.g. "X" in the `go get X` command. And "http(s)://" is
not allowed in the import path for `go get`.

Is there a fossil variable similar to "$baseurl" for the base URL
without the http(s):// ? That could be used instead to replace the
first $baseurl in that meta tag and serve as a valid import path.



I could have sworn this worked when I tested it :) . I don't think the 
variable you want exists, but you can use the following instead:





Mark
___
fossil-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 with Golang (go get)

[Mark Janssen (fossil)]

On 2018-06-17 14:57, Zack Scholl wrote:


All you need to do is update your "Header" skin (Admin -> Skins) to
include a special meta tag that `go get` will fetch to interpret your
fossil as a Go library/program. For example, if you have a fossil
hosted at https://yourdomain.com/hello-world then you need to add the
meta tag in between the  tags:

https://yourdomain.com/hello-world;>



Works very well, thank you.
To add, easier and repo independent is: content="$baseurl fossil $baseurl">

IMO this would be a nice candidate for inclusion in the standard skins.

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

Re: [fossil-users] Replacing subversion revision number... by what?

[Mark Janssen]

All of this will fail in the case of private branches (or other DAG
differences) between different repositories, unless you special case
private branches.
And how will you handle diverging repos so that my version 12 is not
your version 12, because I didn't sync after commit 10?
I wouldn't be surprised if it's mathematically provable that to create
a unique id for a distributed DAG, the only way is to make one
repository special (e.g. the centralized SVN scenario)

Which begs the question, why all this effort to create something which
already is there?

Is stating version 1245 really that much easier than stating version aed2 ?

On Fri, Dec 29, 2017 at 11:12 AM, Olivier Mascia  wrote:
>> Le 28 déc. 2017 à 23:58, Joerg Sonnenberger  a écrit :
>>
> I'm considering replacing the subversion revision ID, for the purpose of 
> defining the file version ID (as above) at release-external build time, 
> by the count of check-ins in the root repository.  That is the count 
> returned by 'fossil info' in one of the multiple lines of output (for 
> instance 'check-ins: 8801').
>>>
>>> My 'count of check-ins' is your 'length of the commit chain to the root', 
>>> or are we talking of something else here?
>>
>> If you have a commit graph like:
>>
>> A
>> |
>> B
>> | \
>> C D
>> | |
>> E F
>>
>> Both E and F have a LoCC of 4, but the count f check-ins would depend on
>> the order of commits?
>
> That I don't know yet for sure.
>
> I just want an integer, always increasing, even though not by one, from a 
> specific branch, from a specific repository (the branch/repository from which 
> I compile released code). And that value seems to fit that need perfectly.  
> It does not need to allow me backward lookups (finding a check-in from that 
> number). That sequential number could even be managed outside by my build 
> system. But it is interesting that it be linked with the count of check-ins, 
> because somehow it gives an empiric sense "of the distance" of code between 
> to release builds. Which we had before through the subversion revision ID.
>
> Upon build I will derive the trailing version number of my executables from 
> that integer. And my build system will auto add a tag with the full 
> constructed version number to the top check-in of that same branch. I can 
> also store that top check-in ID (hash) somewhere else (than in the version 
> number) so it could be displayed on request. And there, thanks to the 
> auto-added full version number tag upon successful release build, I get an 
> easy way to locate the exact source code that was part of that build. It's 
> easier for users to tell support people their version number than a hash 
> code, even shortened.  And setup/distribution is easier thanks to an ever 
> increasing full version number, even between patch builds of a same release.
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia
>
>
> ___
> 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] tangent vs. wyoung on recent commti

[Mark Janssen]

Then what is the point of recvfrom? It will then just reduce to the repo
where the artifact was created. This might be useful, but it is not what
recvfrom means.

Op zo 17 dec. 2017 18:11 schreef Ron W <ronw.m...@gmail.com>:

> On Sun, Dec 17, 2017 at 7:00 AM, <
> fossil-users-requ...@lists.fossil-scm.org> wrote:
>>
>> Date: Sun, 17 Dec 2017 09:56:57 +
>> From: Mark Janssen <mpc.jans...@gmail.com>
>> Subject: Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28
>> Message-ID:
>> 

Re: [fossil-users] fossil-users Digest, Vol 119, Issue 28

[Mark Janssen]

Unless I am misunderstanding what you mean by permanent record, I don't
think this is possible in a DVCS. In a DVCS the remote can be different and
even change between pull/syncs

Op za 16 dec. 2017 21:42 schreef Ron W :

> On Sat, Dec 16, 2017 at 7:00 AM, <
> fossil-users-requ...@lists.fossil-scm.org> wrote:
>
>> Date: Fri, 15 Dec 2017 13:52:55 -0500
>> From: Richard Hipp 
>> Subject: Re: [fossil-users] tangent vs. wyoung on recent commti
>>
>> On 12/15/17, Andy Bradford  wrote:
>> > 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.
>> >
>>
>> I was very aware of all of these factors when I designed Fossil, 10
>> years ago.  Impersonation was a concern.  But in a DVCS, there really
>> is no way around it.
>>
>> Defenses include:
>>
>> (1) The rcvfrom table that shows clearly where all artifacts
>> originated, thus allowing the originator of a deception to be tracked
>> down and dealt with administratively.
>>
>
> Maybe there should be a way to store this rcvfrom table in artifacts so
> the data is part of the permanent Fossil record.
>
> Maybe as control artifacts to auto-tag each each commit received via
> sync/pull/push?
>
> ___
> 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] binary-glob not honored

[Mark Janssen]

>From the manual: "Where a setting is a list of values, such as ignore-glob,
you can use a newline as a separator as well as a comma."

https://www.fossil-scm.org/xfer/doc/trunk/www/settings.wiki

On Mon, 11 Dec 2017, 18:48 Gour, <g...@atmarama.com> wrote:

> On Mon, 11 Dec 2017 12:00:22 +
> Mark Janssen <mpc.jans...@gmail.com>
> wrote:
>
> > .fossil-settings should be a subfolder of your repository checkout,
> > not your home folder.
>
> Ahh, my misunderstanding...now I wonder how to enter *several* patterns
> via cmd
> line and set them to (global), since it seems that whenever I add some
> pattern
> it does replace the old one?
>
>
> Sincerely,
> Gour
>
> --
> As a strong wind sweeps away a boat on the water,
> even one of the roaming senses on which the mind
> focuses can carry away a man's intelligence.
>
>
> ___
> 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] binary-glob not honored

[Mark Janssen]

.fossil-settings should be a subfolder of your repository checkout, not
your home folder.

On Mon, 11 Dec 2017, 16:03 Gour,  wrote:

> Hello,
>
> I'm working on a web site and wanted to perform initial import, but Fossil
> (version 2.5 [561fa8a3b7]) complains:
>
> ./pages/01.blog/14th-anniversary/gaura-nitai_2011_installation.jpg contains
> binary data. Use --no-warnings or the "binary-glob" setting to disable this
> warning.
>
> I'm a bit puzzled since I have ~/.fossil-settings/binary-glob file with the
> following content:
>
> *.pdf
> *.jpg
> *.jpeg
> *.png
> *.kwd
> *.doc
> *.gz
>
> The 'settings' command gives the following output:
>
> access-log
> admin-log
> allow-symlinks
> auto-captcha
> auto-hyperlink
> auto-shun
> autosync
> autosync-tries
> binary-glob
> case-sensitive
> clean-glob
> clearsign(global) on
> crlf-glob
> crnl-glob
> default-perms
> [...]
>
> so I wonder what is wrong, iow. why Fossil does not honour my 'binary-glob'
> setting?
>
>
> Sincerely,
> Gour
>
> --
>
>
> ___
> 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] Forget large set of changes

[Mark Janssen]

Fossil cannot remove existing history. So removing only one dir and
the associated history is not possible.

Why don't you just update the files to be sorted and after that always
keep adding them sorted?

The diffs up until now will still be noisy, but from now on they will
be more readable and you will keep the previous history.

On Mon, Dec 4, 2017 at 6:29 AM, Andy Bradford  wrote:
> 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
___
fossil-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 with Apache Proxy

[Mark Janssen]

On 28 Sep 2017 13:37, "David Mason"  wrote:



I have all the logic I need I just want fossil to behave like it would
at a terminal prompt, rather than acting like a CGI... the complication is
that I am calling it from a CGI!  But removing all the environment variable
mostly solves the problem.


To get the commandline behavior of fossil in a CGI context use the --nocgi
flag.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with ignore-glob

[Mark Janssen]

That's not a security hole at all. Once a file was added, ignoring it
will not remove past version from the repository. History in fossil is
immutable. If you inadvertently added a file which shouldn't be there
you should shun it instead.

On Tue, Apr 11, 2017 at 1:27 AM, Thomas  wrote:
> On 2017-04-11 00:01, Thomas wrote:
>>
>> The --ignore argument as well as the .fossil-settings\ignore-glob file
>> don't work for files or file masks that have been committed at some
>> point after the repository has been created. Your work-around worked.
>> After deleting some of these files, committing, changing, and committing
>> again, they were ignored/not checked in afterwards.
>>
>> I'd say this is either a big design flaw or a bug.
>> It's not mentioned anywhere in the documentation and is anything but
>> logical and reasonable.
>
>
> That's also a big security hole.
>
> Someone checks in a file
> password.this_is_so_confidential_you_should_never_disclose_it_to_anyone.txt.
>
> Bang.
>
>
> ___
> 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] Support for commonmark markdown in fossil

[Mark Janssen]

Or in patch form:

@@ -460,15 +460,16 @@

   while( i=size ) return 0;
-if( data[i]==c ) return i;

 /* not counting escaped chars */
 if( i && data[i-1]=='\\' ){
   i++;
   continue;
 }
+
+if( data[i]==c ) return i;

 /* skipping a code span */
 if( data[i]=='`' ){
   size_t span_nb = 0, bt;

On Tue, Mar 14, 2017 at 4:23 PM, Natacha Porté <nata...@instinctive.eu> wrote:
> Hello,
>
> on Tuesday 14 March 2017 at 15:44, Mark Janssen wrote:
>> I did notice a (IMO) bug during the conversion:
>>
>> $ cat markdown-test2.md
>> _test\_embedded_
>> *test\*embedded*
>> $ fossil test-markdown-render markdown-test2.md
>> 
>>
>> testembedded_
>> testembedded*
>>
>> 
>>
>> The escaped delimiters (\_ and \*) terminate the  but they shouldn't.
>
> I completely agree that this is a bug, and I'm very ashamed by it.
>
> In case somebody with more commit fluency than me wants to commit the
> fix, it's in markdown.c, almost at the beginning of the function
> `find_emph_char`, the line `if( data[i]==c ) return i;` should be moved
> blow the block `if( i && data[i-1]=='\\' ){`.
>
> As of this writing (head of trunk is 6f52316955), that's line 464 to
> move after the closing brace of line 470.
>
> If nobody beats me to it, and if I still have some commit rights, and if
> I figure whether it should go directly to trunk or into a to-be-reviewed
> branch (I'm very confident in the fix, but I might not be trusted enough
> to muddle directly with trunk yet), I will commit the fix myself.
>
>
> Thanks a lot for the report and sorry for the inconvenience,
> Natacha
> ___
> 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] Support for commonmark markdown in fossil

[Mark Janssen]

On Sat, Mar 11, 2017 at 6:18 PM, Natacha Porté  wrote:
>
>
> I should really clarify that it was about *fenced* code blocks, since
> traditional markdown code blocks are correctly supported (unless there
> is a serious bug in there).
>
> I do understand the use of code blocks, and use them myself frequently.
> But only the indented version, because the fenced one feels to me like
> trading a lot of ease of reading for a little bit of ease of writing (or
> rather cut-and-pasting, I don't think it changes much for real writing).
> And that's without taking into account that on top of that most of my
> documents (even in markdown) are read much more often than written.
>

I must admit that after converting all the documents, I don't really
see the lack of fenced code blocks as an issue and I agree that the
readability is better when the blocks are indented (and yes I do use a
proper editor :))

I did notice a (IMO) bug during the conversion:

$ cat markdown-test2.md
_test\_embedded_
*test\*embedded*
$ fossil test-markdown-render markdown-test2.md


testembedded_
testembedded*



The escaped delimiters (\_ and \*) terminate the  but they shouldn't.

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

Re: [fossil-users] Support for commonmark markdown in fossil

[Mark Janssen]

I wasn't aware that the author of the current implementation was a fossil
user as well :)

On Sat, 11 Mar 2017, 16:22 Natacha Porté,  wrote:

>
> I never understood the appeal for code blocks, but if it's only that
> it's very easy to add to the existing implementation.
>

Code blocks are very convenient for displaying TIP examples or other pieces
of example code.

>
> However I would be very interested to know what other features it lacks,
> or how a single feature missing makes it "fairly limited".
>

Limited was maybe a bit harsh, personally I am just missing code blocks.
The rest was based on the score on the commonmark test suite.


> Don't get me wrong, I fully recognize the value of CommonMark, just not
> in features but rather in disambiguation and standardization.
>
>
> 
>
> And a fair warning, if anyone really wants standard-compliant
> CommonMark, and not just a few extra features, don't bother with the
> existing implementation, it's architectually at odds with the choices
> made in CommonMark.
>

Fair warning. I did consider adapting the current implementation, but
re-using the Commonmark reference implementation was less work :)

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

Re: [fossil-users] Support for commonmark markdown in fossil

[Mark Janssen]

Good questions. Currently it replaces the existing markdown parser which
can break existing files. This is why I suggested the repo wide setting.
There are other possible solutions (switch on extension being one as well)
but having different markdown flavours in one repo just feels wrong to me.

On Sat, 11 Mar 2017, 15:38 Scott Robison, <sc...@casaderobison.com> wrote:

> On Sat, Mar 11, 2017 at 7:07 AM, Mark Janssen <mpc.jans...@gmail.com>
> wrote:
>
> My question to you all is, would there be any interest in adding
> commonmark support?
>
>
> I like the idea of a more fully featured markdown implementation. Would
> this replace the existing markdown support or be in addition to it? If
> replace, would it "break" existing repos that are using markdown? If people
> have .md files with the existing markdown support, might this need a
> different extension?
>
> --
> Scott Robison
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Support for commonmark markdown in fossil

[Mark Janssen]

Recently I have been looking to use fossil as a backend for managing the
Tcl tip collection.
An obvious format for the new tip format would be markdown, but currently
the fossil markdown support is fairly limited (for example there are no
code blocks)

I have made a version of fossil which supports the commonmark markdown
format [http://spec.commonmark.org/0.27/]
This looks like it will be a good basis for tip.tcl.tk.

The required changes can be reviewed at
https://fossil.mpcjanssen.nl/commonmark/timeline?r=commonmark-markdown.

Pending issues are:

- Handling of first header in the .md file as the page title
- (Maybe) add a repo wide markdown flavour setting
- Push changes to fossil-scm.org (my user mjanssen has no write access)

My question to you all is, would there be any interest in adding commonmark
support?

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

Re: [fossil-users] Excluding [brackets] from a.../a links

[Mark Janssen]

On Thu, May 15, 2014 at 1:08 AM, Matt Welland estifo...@gmail.com wrote:

 I have the same annoyance with scrape 'n paste. Would adding a space
 between the [ or ] and the hex string alleviate the annoyance but still
 provide the visual delineation?


How about taking a different approach and have fossil accept [..] as a
synonym to . ? Or in other words let fossil strip any brackets when
interpreting an SHA id.

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

Re: [fossil-users] TH1: support for octal and hexadecimal numbers in expressions

[Mark Janssen]

On Fri, Apr 4, 2014 at 10:28 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:



 An additional issue is that binary/octal/hex numbers cannot contain
 dots, so they must be handled separately anyway. Done here:
  http://fossil-scm.org/index.html/info/a306f771d8



Why can't n-ary numbers have dots? 0b1.11 is a perfectly valid
representation of 1.75.

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

Re: [fossil-users] Painful team interaction with fossil, how to improve?

[Mark Janssen]

I have used the ticket hooks and they do work. However they will not allow
automatic updates to be sent to whoever logged the ticket.
As a result I have moved the bug tracker to redmine.
On 13 Feb 2014 16:25, Baptiste Daroussin baptiste.darous...@gmail.com
wrote:

 Hi,

 I'm using fossil for a while now, and I'm quite happy with it, for the scm
 part and the web part.

 The problem is when going with the ticket part of fossil.

 I do not need something sophisticated, the the way the ticket works is ok
 with me, however the more the project I'm working on is growing the more
 painful it becomes to track ticket activity.

 In particular to interact with the submitter. I have found no way to:
 1/ send a mail when new ticket is created (yes we can follow via rss feed,
 but a mail is way nicer)
 2/ send a mail each time to ticket is modified to reporters and followers

 (No rss2email is not a solution: not flexible enough)

 The 2 above are really painful, and for the first time I really thinking
 about migrating from fossil to $something else for the project I do have
 the becomes popular :(

 The lacks of flexible hooks on server side is also a big problem to me, I
 can live with it, but the more I get people involve in the project I'm
 working on the more I'm missing it.

 What I do need on the hook side is:
 1/ send a mail after each push of code with a diff:
 prior-push-tip/post-push-tip for each branch impacted to a given mailing
 list
 2/ be able to get access to the diff and run random code on it and reject
 the push if not validated

 I would like to be able to do the above on top of fossil, how should I do?

 regards,
 Bapt

 ___
 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] Painful team interaction with fossil, how to improve?

[Mark Janssen]

On 13 Feb 2014 19:44, Ron Wilson ronw.m...@gmail.com wrote:

 On Thu, Feb 13, 2014 at 1:13 PM, Mark Janssen mpc.jans...@gmail.com
wrote:

 I have used the ticket hooks and they do work. However they will not
allow automatic updates to be sent to whoever logged the ticket.
 As a result I have moved the bug tracker to redmine.

 My impression, from reading comments on this email list, is that the hook
sends the ticket UUID in an HTTP request, then the recipient fetches the
details and forwards some of the details by whatever means.

 Assuming that the recipient of the ticket-hook notification is allowed
access to the private_contact field, it could forward the notification to
the ticket originator. Likewise, access to any assigned-to and/or
subscribers fields would also be needed.




True with effort all of this could be retrieved from the underlying sqlite
db. The reason I didn't do that is that you need opt out and email
verification to prevent sending spam. I could add your email on every
ticket and you would not be able to stop the notifications without admin
interaction. Eventually you are really just rebuilding something like
redmine. I really wanted to make it work, but in the end it just lacks too
many features at the moment.
___
 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] Painful team interaction with fossil, how to improve?

[Mark Janssen]

On Thu, Feb 13, 2014 at 9:33 PM, Ron Wilson ronw.m...@gmail.com wrote:

 On Thu, Feb 13, 2014 at 2:46 PM, Mark Janssen mpc.jans...@gmail.comwrote:

 True with effort all of this could be retrieved from the underlying
 sqlite db. The reason I didn't do that is that you need opt out and email
 verification to prevent sending spam. I could add your email on every
 ticket and you would not be able to stop the notifications without admin
 interaction.

 I had not considered that because, at work, everyone using Fossil is an
 employee of the company. For my personal projects,  I don't have to worry
 about this. For the OSS projects I contribute to, I either send patch files
 or use github. (Mostly I send patch files.)


Indeed for personal projects and in company projects, what fossil already
offers should suffice.


  Eventually you are really just rebuilding something like redmine. I
 really wanted to make it work, but in the end it just lacks too many
 features at the moment.

  I am curious what features are missing.



Some things that come to mind:

* Ticket notification for admin, logger and followers (this is the big one).
* Email verification to prevent spam.
* Ability to edit your own comments.

The one thing that fossil gets absolutely right (and most other trackers
don't) is the ability to log issues anonymously without becoming a spam
trap.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Windows installer?

[Mark Janssen]

On Sat, Feb 1, 2014 at 5:14 PM, Matt Welland estifo...@gmail.com wrote:

 The last time I installed fossil on Windows it was a minor hassle as there
 was no installer.

 I'm considering putting together an installable version of fossil using
 Inno Setup (http://www.jrsoftware.org/isinfo.php).


There is already an NSI file for fossil in the root dir. Is there anything
Inno Setup offers which NSIS (
http://en.wikipedia.org/wiki/Nullsoft_Scriptable_Install_System) doesn't?

Mark
___
fossil-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 ui/serv

[Mark Janssen]

On Tue, Jan 28, 2014 at 12:46 AM, James Turner ja...@calminferno.netwrote:



 I dunno either. Everything is fine on my main development machine. I'll
 chalk it up to a messed up virtual machine I guess. Sorry for the
 noise.


I have seen something similar in the past, could it be a permissions issue
on the repo or the containing directory?

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

Re: [fossil-users] Version 1.28 release?

[Mark Janssen]

On Tue, Jan 14, 2014 at 9:36 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2014/1/13 Mark Janssen mpc.jans...@gmail.com:
  I am not sure if this is an issue with my MinGW install, but latest trunk
  fails to build on MinGW. I think it's useful if the official release can
  also be built on MinGW.

 http://fossil-scm.org/index.html/info/354288db9c

 Thanks!

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


With that commit, build still fails on sqlite.c:

src/sqlite3.c:34515: warning: implicit declaration of function
'winShmMutexHeld'

This function is only defined with -DSQLITE_DEBUG but used without ifdef in
winShmPurge. There are many other issues with building without
-DSQLITE_DEBUG. I am not sure if the proper fix is to define this in the
Makefile or to build without DEBUG.

Defining -DSQLITE_DEBUG gives a warning about %lld:

src/sqlite3.c:5: warning: unknown conversion type character 'l' in
format
src/sqlite3.c:5: warning: too many arguments for format
src/sqlite3.c:7: warning: unknown conversion type character 'l' in
format
src/sqlite3.c:7: warning: too many arguments for format


Mark

BTW you are referring to old MinGW in your commit message. I have installed
mingw using the installer. How do you get a newer version?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Version 1.28 release?

[Mark Janssen]

On Thu, Jan 9, 2014 at 2:20 PM, Richard Hipp d...@sqlite.org wrote:

 It has been a few months since the last official release of Fossil.  I
 wonder if we should consider publishing trunk as the official version 1.28?

 --
 D. Richard Hipp
 d...@sqlite.org

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


I am not sure if this is an issue with my MinGW install, but latest trunk
fails to build on MinGW. I think it's useful if the official release can
also be built on MinGW.

Error is (using make -f win/Makefile.mingw):

src/winfile.c: In function 'win32_access':
src/winfile.c:117: error: 'LABEL_SECURITY_INFORMATION' undeclared (first
use in
this function)
src/winfile.c:117: error: (Each undeclared identifier is reported only once
src/winfile.c:117: error: for each function it appears in.)
make: *** [wbld/winfile.o] Error 1
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Small issue with ticket hook script

[Mark Janssen]

On 11 Jan 2014 20:09, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014/1/9 Mark Janssen mpc.jans...@gmail.com:
  When  I use the following script as a ticket hook:
 
  set project simpletask
  tclInvoke package require http
  query {SELECT title, status
  FROM ticket
  WHERE tkt_uuid=$uuid} {
 set title [tclInvoke http::formatQuery  $title]
 http -asynchronous --
 
http://127.0.0.1/cgi-bin/tkt-hook?uuid=$uuidtitle=$titlestatus=$statusproject=$project
  }

 Looking at this again, fossil could benefit from a
 TH1 encodeURIComponent() function, which does
 the same as the Javascript function with the same
 name. Doing this through Tcl's http::formatQuery
 command is a lot more expensive.

 Anyone interested in writing a TH1
 encodeURIComponent() function? I guess
 more parts in fossil could benefit from that.


Of course it would be easier if th1 had a command like this, but
considering the TCL bridge is there and the fact that tickets are not in
high volume, for me the current solution is good  enough.

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

Re: [fossil-users] Small issue with ticket hook script

[Mark Janssen]

On Thu, Jan 9, 2014 at 7:49 PM, Mark Janssen mpc.jans...@gmail.com wrote:




 On Thu, Jan 9, 2014 at 5:58 PM, Mark Janssen mpc.jans...@gmail.comwrote:




 On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
  I have a different fix
  in mind, I'll come back on that later.

 http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook

 Does this work for you?

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



 No with this a ticket change from the web UI will not trigger the xfer
 script.



 With change below it works again is rc what you think it is at that part
 in the code?



Sorry to keep replying to myself, but with latest version of
delay-ticket-hook
[e4af590ff9]http://www.fossil-scm.org/index.html/info/e4af590ff9 it
still doesn't work.
The cause is that in tkt.c the result logic is off. Below change fixes it:

--- src/tkt.c
+++ src/tkt.c
@@ -537,11 +537,11 @@
 db_multi_exec(INSERT OR IGNORE INTO unclustered VALUES(%d);, rid);
   }
   manifest_crosslink_begin();
   result = (manifest_crosslink(rid, pTicket, 0)==0);
   assert( blob_is_reset(pTicket) );
-  if( result ){
+  if( !result ){
 result = manifest_crosslink_end(MC_PERMIT_HOOKS);
   }else{
 manifest_crosslink_end(0);
   }
   return result;


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

Re: [fossil-users] Small issue with ticket hook script

[Mark Janssen]

On Fri, Jan 10, 2014 at 11:46 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2014/1/10 Mark Janssen mpc.jans...@gmail.com:
  Sorry to keep replying to myself, but with latest version of
  delay-ticket-hook [e4af590ff9] it still doesn't work.
  The cause is that in tkt.c the result logic is off. Below change fixes
 it:

 Yes, that's it! I saw Joe's fixes, but I still wasn't sure if that was
 enough to fix everything. The return value of manifest_crossling(),
 which is 0 for errors, always confuse me

 I'm not 100% sure that error-reporting is handled correctly
 everywhere, but it's getting close! A review by anyone else
 familiar wouldn't hurt either. Anyway, It will miss the 1.28
 release, but it should be merge-able to trunk not too long
 after that.

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


The 0 for error return of manifest_crosslink() tripped me up too. It took
me way to long to spot why it wasn't working. Anyway with this change the
ticket hooking works for my purposes.

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

[fossil-users] Using Markdown for tickets and in TH1

[Mark Janssen]

All,

Attached a patch which will do several things:

1) Add a [markdown ] TH1 command to allow access to the included
markdown parser from TH1
2) Slightly tweaked the markdown parser to not produce a p/p pair for
strings with at most one newline
3) Changed the default ticket page templates to provide Markdown input
using the already defined text/x-markdown mimetype

Only thing left to be done is to extend the markdown parser so that [uuid]
will refer to the fossil artifact as in the fossil wiki parser.

Regards,
Mark


markdown-tickets.patch
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Small issue with ticket hook script

[Mark Janssen]

When  I use the following script as a ticket hook:

set project simpletask
tclInvoke package require http
query {SELECT title, status
FROM ticket
WHERE tkt_uuid=$uuid} {
   set title [tclInvoke http::formatQuery  $title]
   http -asynchronous --
http://127.0.0.1/cgi-bin/tkt-hook?uuid=$uuidtitle=$titlestatus=$statusproject=$project
}

The reflected information in the query is the info from before the ticket
update.
I suspect the ticket hook is fired before the actual ticket change
transaction is commited. Would it be possible to reverse this so that the
hook script will be executed after the ticket change has been commited?

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

Re: [fossil-users] Small issue with ticket hook script

[Mark Janssen]

On Thu, Jan 9, 2014 at 2:20 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014/1/9 Mark Janssen mpc.jans...@gmail.com:
  The reflected information in the query is the info from before the ticket
  update.
  I suspect the ticket hook is fired before the actual ticket change
  transaction is commited. Would it be possible to reverse this so that the
  hook script will be executed after the ticket change has been commited?

 I'll have a look at that. In your test, how did the ticket change come in?
 Either with an xfer from another repository, or simply edited in the
 web-interface. This difference is important: The code path leading
 to the hook firing is different in those two situations.

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


I tested it with ticket changes from the web interface. Patch below fixes
the behavior for the webinterface, Not sure about tickets that are
transfered in.

Mark

Index: src/manifest.c
==
--- src/manifest.c
+++ src/manifest.c
@@ -1882,19 +1882,20 @@
   );
 }
   }
   if( p-type==CFTYPE_TICKET ){
 char *zTag;
-
+manifest_crosslink_begin();
 zScript = xfer_ticket_code();
 zUuid = p-zTicketUuid;
 assert( manifest_crosslink_busy==1 );
 zTag = mprintf(tkt-%s, p-zTicketUuid);
 tag_insert(zTag, 1, 0, rid, p-rDate, rid);
 free(zTag);
 db_multi_exec(INSERT OR IGNORE INTO pending_tkt VALUES(%Q),
   p-zTicketUuid);
+manifest_crosslink_end();
   }
   if( p-type==CFTYPE_ATTACHMENT ){
 db_multi_exec(
INSERT INTO attachment(attachid, mtime, src, target,
 filename, comment, user)

Index: src/tkt.c
==
--- src/tkt.c
+++ src/tkt.c
@@ -534,14 +534,12 @@
 );
   }else{
 db_multi_exec(INSERT OR IGNORE INTO unsent VALUES(%d);, rid);
 db_multi_exec(INSERT OR IGNORE INTO unclustered VALUES(%d);, rid);
   }
-  manifest_crosslink_begin();
   result = (manifest_crosslink(rid, pTicket, MC_PERMIT_HOOKS)==0);
   assert( blob_is_reset(pTicket) );
-  manifest_crosslink_end();
   return result;
 }

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

Re: [fossil-users] Confirm commit

[Mark Janssen]

On Thu, Jan 9, 2014 at 3:54 PM, Arseniy Terekhin sen...@gmail.com wrote:

 Hello,

 When developing, I often execute last command blindly and sometimes it
 happens to be `fossil ci -m text`. And sometimes I commit,
 forgetting that I'm on a wrong branch. So I purpose to add commit
 confirmation that contains number of changes and a branch name. One
 might say, just be careful. I say — less distraction.

 --
 Best regards,
 Arseniy Terekhin
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



Don't use -m and the editor popup for the commit message will be your
reminder.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Small issue with ticket hook script

[Mark Janssen]

On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
  I have a different fix
  in mind, I'll come back on that later.

 http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook

 Does this work for you?

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



No with this a ticket change from the web UI will not trigger the xfer
script.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Small issue with ticket hook script

[Mark Janssen]

On Thu, Jan 9, 2014 at 5:58 PM, Mark Janssen mpc.jans...@gmail.com wrote:




 On Thu, Jan 9, 2014 at 5:31 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2014/1/9 Jan Nijtmans jan.nijtm...@gmail.com:
  I have a different fix
  in mind, I'll come back on that later.

 http://fossil-scm.org/index.html/timeline?r=delay-ticket-hook

 Does this work for you?

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



 No with this a ticket change from the web UI will not trigger the xfer
 script.



With change below it works again is rc what you think it is at that part in
the code? I would think that a single ticket hook script failure should not
terminate all of them.

--- src/manifest.c
+++ src/manifest.c
@@ -1506,13 +1506,11 @@
   }
   db_prepare(q, SELECT uuid FROM pending_tkt);
   while( db_step(q)==SQLITE_ROW ){
 const char *zUuid = db_column_text(q, 0);
 ticket_rebuild_entry(zUuid);
-if( rc==TH_OK ){
-  rc = xfer_run_script(xfer_ticket_code(), zUuid);
-}
+rc = xfer_run_script(xfer_ticket_code(), zUuid);
   }
   db_finalize(q);
   db_multi_exec(DROP TABLE pending_tkt);

   /* If multiple check-ins happen close together in time, adjust their
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question on repo size after repeated binary file commits?

[Mark Janssen]

On Sun, Dec 22, 2013 at 7:37 PM, sky5w...@gmail.com wrote:

 I am curious what is stored in the repo for each new commit that includes
 a tiny change to a binary file.
 Whether a dll or an image file, is fossil storing each binary file
 compressed, uncompressed or some sort of delta?
 Over time(6mo's to 1yr), I would like to reduce my repo size by purging
 really old binary files.

 Thanks for fossil!


Fossil does have delta encoding but I am not sure whether this is  used for
binary files. However part of the design philosophy of Fossil is that no
history is ever lost. So reducing the repository size is generally not
possible.

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

[fossil-users] State of tkt-hook-change branch

[Mark Janssen]

What is the state of the tkt-hool-change branch? I tried using it for my
own local repo and I can't get the http ticket hook to trigger.

th1-uri-regexp: .*
hook command is: http -asynchronous --
http://mpcjanssen.nl/cgi-bin/tkt-hook?uuid=$uuid

After adding some debugging statements the hook command seems to fail with:

Executing th1 common script

Executing 1 th1 specific script http -asynchronous --
http://mpcjanssen.nl/cgi-bin/tkt-hook?uuid=$uuid

parsing URL 
http://mpcjanssen.nl/cgi-bin/tkt-hook?uuid=7f4a275ec1d71597006fa063a57c166033937ca8
url must be http:// or https://

Anyone has any idea what's up?

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

Re: [fossil-users] State of tkt-hook-change branch

[Mark Janssen]

On Fri, Dec 13, 2013 at 12:29 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2013/12/13 Mark Janssen mpc.jans...@gmail.com:
  What is the state of the tkt-hool-change branch? I tried using it for my
 own
  local repo and I can't get the http ticket hook to trigger.

 Looks like an uninitialized variable. Should be fixed now.

 I think it's ready to be merged to trunk.

 Thanks!


With the updated version [85528ef507] I still get the same error.
xfer_run_script still fails with error:

url must be http:// or https://

At xfer.c line 869

Maybe there is something else I am doing wrong?

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

Re: [fossil-users] State of tkt-hook-change branch

[Mark Janssen]

On Fri, Dec 13, 2013 at 2:15 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2013/12/13 Mark Janssen mpc.jans...@gmail.com:
  With the updated version [85528ef507] I still get the same error.
  xfer_run_script still fails with error:
 
  url must be http:// or https://
 
  At xfer.c line 869
 
  Maybe there is something else I am doing wrong?

 More likely that I did something wrong, like
 an incomplete commit. Please try again ;-)

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



Hi Jan,

Two remarks:

1) I am fairly sure that:
memset(urlData, '0', sizeof(urlData));
  Should be
memset(urlData, 0, sizeof(urlData));

2) I think url_parse_local should be fixed to properly fill all the urlData
fields instead of having to memset the structure before.

Mark

BTW with memset 0 it works :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] State of tkt-hook-change branch

[Mark Janssen]

On Fri, Dec 13, 2013 at 3:19 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:


 Thanks for your feedback!



One final piece of feedback, concerning the next step in the trigger
process. Fossil seems to encode the trigger request as Content-Type:
text/plain even in the case of a GET.
Unfortunately this will lead to an error when trying to parse the request
using tcllib's ncgi. ncgi only supports:

 -
text/xml* -
application/x-www-form-urlencoded* -
application/x-www-urlencoded*

And reading the specs it seems that a GET request should not specify a
content-type at all.

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

Re: [fossil-users] State of tkt-hook-change branch

[Mark Janssen]

On Fri, Dec 13, 2013 at 4:18 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2013/12/13 Mark Janssen mpc.jans...@gmail.com:
  One final piece of feedback, concerning the next step in the trigger
  process. Fossil seems to encode the trigger request as Content-Type:
  text/plain even in the case of a GET.
  Unfortunately this will lead to an error when trying to parse the request
  using tcllib's ncgi. ncgi only supports:
 
   -
  text/xml* -
  application/x-www-form-urlencoded* -
  application/x-www-urlencoded*
 
  And reading the specs it seems that a GET request should not specify a
  content-type at all.

 Neither content-length ;-(

 http://fossil-scm.org/index.html/info/a60d2976ff

 Again, Thanks!

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


Thanks for the quick fixes :) Everything works great now.

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

Re: [fossil-users] Gentoo: SQLITE_WARNING... best approach for Portage

[Mark Janssen]

On 20 Nov 2013 16:40, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Nov 20, 2013 at 4:10 PM, Andy Bradford amb-fos...@bradfords.org
wrote:

 Thus said Stephan Beal on Wed, 20 Nov 2013 10:24:02 +0100:

  If the  patch is relatively  small, please just  paste it to  the list
  (don't attach  it - attachments get  stripped). i don't see  the prior
  mail explaining the problem - maybe it already contains the patch?

 The patch is already in Fossil:

 http://www.fossil-scm.org/index.html/info/e65162b4ad


 Ah, i've missed so much traffic/context recently :(.

 IIRC, Richard tweaked that fix at some point:


http://www.fossil-scm.org/index.html/vdiff?from=e65162b4ad664ae37to=aef638b61003fcf2sbs=1

 search that for main.c and you'll see that line 1185 from e65162 was
removed later on.

 i.e. the patch for Gentoo should probably look a little bit different
now. As for how best to feed that into their build process... no idea :/.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 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


Considering fossil releases are relatively rare and fossil trunk is
generally in a good state, I would suggest picking the current trunk head
and update the version on a regular basis if fixes that are of interest for
Gentoo users are merged with trunk.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] missing branch tag (?)

[Mark Janssen]

Branches are controlled by propagating raw tags. Start with fossil tag list
--raw checkin. Then I think you should be able to cancel the offending raw
tag.
On 9 Oct 2013 23:07, B Harder brad.har...@gmail.com wrote:

 ...and now I see the edit where the trunk tag was cancelled --
 question remains --- can I undo/reverse the effect?

 On 10/9/13, B Harder brad.har...@gmail.com wrote:
  It appears that somehow the branch tag was deleted on my [trunk].
 
  Now, when I try to merge from trunk - feature_branch, I get something
  like:
 
 
  $ fossil merge trunk
  WARNING - no common ancestor: filea.c
  WARNING - no common ancestor: fileb.c
  WARNING - no common ancestor: filec.c
  ...
  ADDED src/otherfile_a.c
  ADDED src/otherfile_b.c
  ADDED src/otherfile_c.c
 
  How can I restore the trunkness of trunk through its complete
  timeline? I tried adding trunk tags, but I didn't suspect they'd
  work, and I was correct.
 
  --
  Brad Harder
  Method Logic Digital Consulting
  http://www.methodlogic.net/
  http://twitter.com/bcharder
 


 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder
 ___
 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] cgi on Mac problem

[Mark Janssen]

On Sun, Sep 29, 2013 at 4:59 PM, j. van den hoff
veedeeh...@googlemail.comwrote:

 hi list,

 snip


 what I see:

-- access to `http:{mymachine}/cgi-bin/**first.cgi' works just fine (I
 do get the `hello world' page)

-- access to `http:{mymachine}/cgi-bin/**repo.cgi' gives the `internal
 server error' in the browser and the message Premature end of script
 headers: repo.cgi in the apache error log

 which, I understand, can have many reasons (e.g. wrong permissions) but
 boils down to the html headers not being generated as expected.


 any help in these matters would be appreciated.



Trying `fossil cgi /Library/WebServer/CGI-**Executables/repo.cgi` should
give a more descriptive error.

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

Re: [fossil-users] cgi on Mac problem

[Mark Janssen]

On Sun, Sep 29, 2013 at 5:22 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Sun, Sep 29, 2013 at 5:19 PM, Stephan Beal sgb...@googlemail.comwrote:

 http://www.jmarshall.com/easy/http/#responseline


 Another tip, taken from that page:

 try sending the request with telnet and see what comes back:

 telnet localhost PORT_NUMBER

 GET /timeline HTTP/1.0

 Assuming Mac even has telnet (it's rarely used much nowadays... normally
 as a debugging tool for network connections of other types).




You could also use something like:

echo GET /home\n\n | sudo su - www-data -c fossil http
/path/to/repository

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

Re: [fossil-users] looking for GUI app developer for libfossil

[Mark Janssen]

I wouldn't call myself a UI designer by any means, but it would be
interesting to try to put something together with libfossil on Android (I
do have quite some experience in Android developement). Time permitting, I
will have a look at building libfossil on Android (which should be easy as
fossil itself also can be built for Android) and build some rudimentary UI
on top of it.
This is not without some self interest of course. I would love a fossil
powered back end for my todo list app Simpletask.


On Tue, Sep 17, 2013 at 9:13 PM, Stephan Beal sgb...@googlemail.com wrote:

 Hi, all,

 It's been years since i've done any GUI programming (and then only in Qt
 and a small bit of WinCE) and i'm looking for an adventurous GUI hacker to
 create some form of prototype Fossil GUI app (i've got a couple of ideas if
 there's a volunteer), primarily as a demonstration of libfossil. It could,
 in principal, be done in any programming language, provided it allows for
 binding to C code. There are no platform portability limitations, so you
 could even use WinCE if we can get libfossil compiling there. There are a
 couple apps which would be pretty easy to implement on top of the current
 APIs (e.g. the equivalent of the /dir page), and i don't expect that they
 would require much effort for someone well-versed with GUI programming.

 If anyone's interested, feel free to get in touch on- or off-list!

 Happy Hacking!

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] looking for GUI app developer for libfossil

[Mark Janssen]

The way I get fossil to build for Android is using the NDK which is also
used if you mix C code with an Android app so I see no problems there. Will
take any other issues up with you off list.
On 18 Sep 2013 17:48, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Sep 18, 2013 at 12:18 PM, Mark Janssen mpc.jans...@gmail.comwrote:

 I wouldn't call myself a UI designer by any means, but it would be
 interesting to try to put something together with libfossil on Android (I
 do have quite some experience in Android developement). Time permitting, I
 will have a look at building libfossil on Android (which should be easy as
 fossil itself also can be built for Android) and build some rudimentary UI
 on top of it.


 i would be tickled pink to see any sort of android port, especially if
 there were JNI bindings :) (about which i know nothing, btw) for Java apps
 (i've done one Android app so far and would like to do more).


 This is not without some self interest of course. I would love a fossil
 powered back end for my todo list app Simpletask.


 If i can be of any assistance in helping you get oriented, or portability
 fixes for android, or similar, just let me know. i don't foresee any
 problems with android, assuming it supports int64 and double. The lib can
 be built with customized int types (so it could use 32-bit ints for IDs and
 sizes) but it would not work properly (i assume) with massive repos (e.g.
 tcl). i have a tablet here i could hack on, but i've never been able to
 successfully compile a working binary on android, and eventually gave up
 trying. i got some stuff compiling/linking (using tips provided by you,
 IIRC) but it would always segfault at startup.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] Can one display ISO 8601 date-time instead of SHA-1 prefixes in the web UI?

[Mark Janssen]

On Sun, Aug 25, 2013 at 4:56 PM, Yannick yannick_duch...@yahoo.fr wrote:

 **
 Hi people,

 Just discovered Fossil two days ago, and I like the concept, especially
 it's simplicity (even if I believe this could be made even a bit clearer)
 and it's low weight.

 I was wondered if there is a known way to display (and optionally use in
 fossil command lines), a date-time (something like ISO 8601 format) instead
 of SHA-1 prefix in all the time line views within the fossil web UI. That's
 just that date-time is more human readable, makes more sense to human, and
 I'm favouring ISO 8601 date-time as versions identification for my tiny
 stuffs, as I don't enjoy version numbers neither (cheese).


You can use timestamps with the CLI (check
http://www.fossil-scm.org/fossil/doc/trunk/www/checkin_names.wiki).

The timestamp of the commit +1s should work for identifying that commit
instead of the UUID.

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

Re: [fossil-users] Command-line wildcards

[Mark Janssen]

It's a problem with the way MinGW parses and passes the command line. When
main is called in fossil, the arguments are already expanded. As for the
fix, I am not sure yet.



On Wed, Aug 21, 2013 at 2:36 PM, Stephan Beal sgb...@googlemail.com wrote:


 On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net wrote:

 @
 Stephan Beal: So fossil is refusing to eat it's own dog food - or
 rather one of its more unique assets: The integrated wiki and ticket
 system? :-)



 This problem is Windows-specific. In every Unix shell *.css, '*.css
 will be equivalent (they arrive in the app _without_ the quotes). Using
 *.css MIGHT be equivalent: most shells will not expand the wildcard unless
 there is a match, and if there is no match then they leave it intact (bash
 has a configuration option to change this and replace a non-matching
 wildcard with an empty string).

 The main difference is that in Unix the shell does a surprising amount of
 pre-processing of the CLI args before passing them on the app, meaning that
 all apps get a consistent view of CLI args. Windows, OTOH leaves the
 developer to do it all himself.

 The dogfood here is without a doubt the Windows shell.


  But since I must accept the culture of the place I'm visiting, perhaps
 you can help out a novice mailman list fellow: Is there any way to only
 receive emails from threads I am participating in?


 i haven't used Windows (outside of customer sites and an occasional game
 of Empire at War) since last millennium - i can't suggest much of anything
 in that regard except maybe to find something more... well, more.

 :)


 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] Command-line wildcards

[Mark Janssen]

Following change fixes it for met with MinGW 32 bit on windows 7.

$ fossil diff src/main.c
argc in wmain 3
--- src/main.c
+++ src/main.c
@@ -522,11 +522,13 @@
 */
 #if defined(_WIN32)  !defined(BROKEN_MINGW_CMDLINE)
 int _dowildcard = -1; /* This turns on command-line globbing in MinGW-w64
*/
 int wmain(int argc, wchar_t **argv)
 #else
+int_CRT_glob = 0;
 int main(int argc, char **argv)
+
 #endif
 {
   const char *zCmdName = unknown;
   int idx;
   int rc;

I did not test this with the 64bit version of MinGW. Using an unquoted * in
this case still works as expected.

Mark


On Wed, Aug 21, 2013 at 2:42 PM, Mark Janssen mpc.jans...@gmail.com wrote:

 It's a problem with the way MinGW parses and passes the command line. When
 main is called in fossil, the arguments are already expanded. As for the
 fix, I am not sure yet.



 On Wed, Aug 21, 2013 at 2:36 PM, Stephan Beal sgb...@googlemail.comwrote:


 On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net wrote:

 @
 Stephan Beal: So fossil is refusing to eat it's own dog food - or
 rather one of its more unique assets: The integrated wiki and ticket
 system? :-)



 This problem is Windows-specific. In every Unix shell *.css, '*.css
 will be equivalent (they arrive in the app _without_ the quotes). Using
 *.css MIGHT be equivalent: most shells will not expand the wildcard unless
 there is a match, and if there is no match then they leave it intact (bash
 has a configuration option to change this and replace a non-matching
 wildcard with an empty string).

 The main difference is that in Unix the shell does a surprising amount of
 pre-processing of the CLI args before passing them on the app, meaning that
 all apps get a consistent view of CLI args. Windows, OTOH leaves the
 developer to do it all himself.

 The dogfood here is without a doubt the Windows shell.


  But since I must accept the culture of the place I'm visiting, perhaps
 you can help out a novice mailman list fellow: Is there any way to only
 receive emails from threads I am participating in?


 i haven't used Windows (outside of customer sites and an occasional game
 of Empire at War) since last millennium - i can't suggest much of anything
 in that regard except maybe to find something more... well, more.

 :)


 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] Command-line wildcards

[Mark Janssen]

Yes, for example fossil add * will still do the right thing.


On Wed, Aug 21, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.comwrote:

 I did not test this with the 64bit version of MinGW. Using an unquoted *
 in this case still works as expected.


 as expected means, i assume: resolves to a list of all files matching
 * in the current directory? (That's the expected Unix behaviour, anyway.)

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] Command-line wildcards

[Mark Janssen]

Sorry for spamming, but with the change it works within msys, but it fails
on the windows command line. Seems like a bit of a Catch 22 caused by the
different idea windows and unix have about how to pass arguments.




On Wed, Aug 21, 2013 at 2:52 PM, Mark Janssen mpc.jans...@gmail.com wrote:

 Yes, for example fossil add * will still do the right thing.


 On Wed, Aug 21, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.comwrote:

 On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.comwrote:

 I did not test this with the 64bit version of MinGW. Using an unquoted *
 in this case still works as expected.


 as expected means, i assume: resolves to a list of all files matching
 * in the current directory? (That's the expected Unix behaviour, anyway.)

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] strange `fossil diff ' behaviour

[Mark Janssen]

On Wed, Aug 21, 2013 at 5:09 PM, Richard Hipp d...@sqlite.org wrote:

 On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:

 On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
 wrote:
  DVCSs cannot, by their very nature, portably support sequential numbers.
  This topic has been beaten to death by brains much larger than mine.

 Joerg's original proposal (in a previous thread) was to support
 _local_ sequential revision numbers as per Mercurial. That is, while
 my revision 5 needn't match yours (e.g., autosync is off and we've
 both committed), we can each still perform local operations using
 these numbers (e.g., diff -r 3:5).


 Please note that the internal record IDs are increasing, but not
 sequential.  In the self-hosting Fossil repository at www.fossil-scm.org,
 the first check-in is 65, the second is 72, the third is 74, and fourth is
 85, and so forth.  So even if the record IDs were exposed, they would not
 give you sequential numbers as you get with mercurial.

 I fully support Stephan's insistence on not exposing record IDs
 unnecessarily.

 It is, in theory, possible to support repository-specific sequential
 version numbers, such as one finds in mercurial.  This would require a new
 database table to maps the sequential numbers into record IDs and some code
 additions in various places to populate and use that new table.  If you
 think that having repository-specific sequential version numbers is a good
 thing (I do not) then you are welcomed to argue your case for that
 enhancement.  But, unfortunately, exposing record IDs is not quite the same
 thing.



One reason which would make my life easier is when dealing with tickets, it
is much easier to discuss bug 12 (in blessed repo X) instead of ticket uuid
[some 8+ digit number]. When I work with tickets on github I know the bug
ids of tickets I am working on. When working with fossil I always have to
look up the uuid.
___
fossil-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 `fossil diff ' behaviour

[Mark Janssen]

For most of the use cases discussed here I think we don't need repository
local unique numbers a la mercurial. As far as I can see a more flexible
VERSION [1] format (although the git way is probably overkill) seems to be
enough. It would be useful for example to be able to say:

fossil diff -r -2
# diff between current and 2 commits ago on this branch

fossil info trunk~2
# info of second commit tagged trunk (if this makes sense with how fossil
uses tags)

meaning diff over last two checkins on this branch.

etc.

[1] http://fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki
___
fossil-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 `fossil diff ' behaviour

[Mark Janssen]

To make this less of an academic discussion and to just be able to play
around with it,

http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1 has
an implementation of having repository local rev numbers for commits only.
After updating fossil you'll need to do a fossil rebuild on the repo to
fill the new table.
Currently the revision numbers are reflecting the fossil rebuild algorithm
so they count down from leaves which is a bit odd, but that can probably be
improved.
As you can see in the URL above the web UI also understands the new
r:revnum syntax.

This is not very well tested yet so use at your own risk.

Mark
___
fossil-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 `fossil diff ' behaviour

[Mark Janssen]

On Wed, Aug 21, 2013 at 7:36 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen mpc.jans...@gmail.comwrote:

 Currently the revision numbers are reflecting the fossil rebuild
 algorithm so they count down from leaves which is a bit odd, but that can
 probably be improved.


 Coincidentally, this block _might_ affect you in a negative way:


 http://mpcjanssen.nl/fossil/fossil/artifact/01cd0cd7b2baee0ec438968994da3dfeead6c8a0?ln=347-356

 it drops all non-core tables during rebuild, and revlist isn't in there.


That's on purpose, revlist is rebuilt when doing a fossil rebuild. This
does mean that after a rebuild the short ids are probably different, but at
the moment that's not really an 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] Bikeshedding opportunity: back to the topic of libfossil's name

[Mark Janssen]

On Wed, Aug 21, 2013 at 7:38 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Aug 21, 2013 at 7:30 PM, Themba Fletcher 
 themba.fletc...@gmail.com wrote:

 What about libfree as a portmanteau of lib, fossil, and three? I guess
 that crosses the line into humor a bit.


 And sounds very GNU :/.


 More seriously though, fossil(3) is my favorite, but it does make it
 sound like it's an official part of the fossil project and actually
 implies, at least to me, that fossil(1) is built on top of it. Whether or
 not that implication is common and / or appropriate I'll leave to you to
 negotiate with Richard.


 It also has the drawback of basically prohibiting the name (eventually)
 fossil v3. i also can't write -lfossil(3) (thought it would be funny).
 So, yeah, fossil(3) is nice but too impractical. :(

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

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


+1 for libfossil. I hate it when libraries have smart names requiring me to
google for the package name to install.
___
fossil-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 `fossil diff ' behaviour

[Mark Janssen]

On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:

 On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
 wrote:

  To make this less of an academic discussion and to just be able to play


 very good point (despite being myself in academia ...) and thanks a lot
 for sharing this.


  around with it,

 http://mpcjanssen.nl/fossil/**fossil/vdiff?from=root:**
 revlistto=r:5746sbs=1http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1has
 an implementation of having repository local rev numbers for commits


 I my view revnums for checkins only is absolutely sufficient/just right.


  only.
 After updating fossil you'll need to do a fossil rebuild on the repo to
 fill the new table.
 Currently the revision numbers are reflecting the fossil rebuild algorithm
 so they count down from leaves which is a bit odd, but that can probably
 be
 improved.


 this is already quite nice. but ultimately I think the best solution would
 be to have the map revnum - sha1 as drh indicated where the revnums are
 just the chronological/auto-incremented index of the commits.



The fossil rebuild logic uses a two pass algorithm. I am not quite sure why
this is necessary, it could have something to do with delta manifests. At
http://mpcjanssen.nl/fossil/fossil/timeline?r=revlist I have changed this
to a single pass. This results in relatively monotomic ids which should be
stable across consecutive rebuilds. One caveat, this could break horribly
when delta manifests are present so use at your own risk.
___
fossil-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 `fossil diff ' behaviour

[Mark Janssen]

On 21 Aug 2013 23:22, j. van den hoff veedeeh...@googlemail.com wrote:

 On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:

 On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
 veedeeh...@googlemail.comwrote:

 On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
 wrote:

  To make this less of an academic discussion and to just be able to play



 very good point (despite being myself in academia ...) and thanks a lot
 for sharing this.


  around with it,


 http://mpcjanssen.nl/fossil/**fossil/vdiff?from=root:**
 revlistto=r:5746sbs=1
http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1
has

 an implementation of having repository local rev numbers for commits


 I my view revnums for checkins only is absolutely sufficient/just right.


  only.

 After updating fossil you'll need to do a fossil rebuild on the repo to
 fill the new table.
 Currently the revision numbers are reflecting the fossil rebuild
algorithm
 so they count down from leaves which is a bit odd, but that can
probably
 be
 improved.


 this is already quite nice. but ultimately I think the best solution
would
 be to have the map revnum - sha1 as drh indicated where the revnums are
 just the chronological/auto-incremented index of the commits.



 The fossil rebuild logic uses a two pass algorithm. I am not quite sure
why
 this is necessary, it could have something to do with delta manifests. At
 http://mpcjanssen.nl/fossil/fossil/timeline?r=revlist I have changed this
 to a single pass. This results in relatively monotomic ids which should
be
 stable across consecutive rebuilds. One caveat, this could break horribly
 when delta manifests are present so use at your own risk.


 understood. what I do not get is (apart from that's it probably not part
of the current machinery) why it
 would be complicated (for the people in the know) to just log the
checkins and count them while they arrive in the db (be it locally or by a
pull) or, rather, to assign a revnum in chronological order (i.e. the order
in which `fossil timeline' displays the checkins). and then put that
 info in some table for the user to assess (and hopefully for the the
fossil commands to accept instead of the hashes for identifying revisions).
 is there a principal technical difficulty in doing that?

 j.


 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/

Note that chronological and the order in which they get into the db are
generally not equivalent in a DVCS. I think stability of the revs for a
certain clone (with Stephan's caveats) is a good thing.

There is no real reason why you can't initially generate them
chronologically except that it would require more code in the rebuild
command. Also if you pull older changes and rebuild revs will change.

You should at least have enough now to try it out and see if it helps.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] failure to push/sync

[Mark Janssen]

I am curious how auto sync screws with your workflow. I was of the same
mind in the beginning, always turning of auto sync on my repos. However
these days I always leave it on, I like the extra automatic backup.
On Aug 14, 2013 10:42 PM, Chad Perrin c...@apotheon.net wrote:

 I'm seeing some kind of authentication failure when trying to sync local
 with remote over SSH.

 Given a user account foo:

 $ fossil clone http://foo@127.0.0.1:/test test.fsl
 password for foo:
 remember password (Y/n)? n
 Round-trips: 1   Artifacts sent: 0  received: 0
 *** time skew *** server is fast by 20.4 seconds
 Round-trips: 2   Artifacts sent: 0  received: 1
 *** time skew *** server is fast by 20.3 seconds
 Round-trips: 2   Artifacts sent: 0  received: 3
 Clone finished with 540 bytes sent, 1162 bytes received
 Rebuilding repository meta-data...
   100.0% complete...
 project-id: 4f2339b57d865b43d48c3c6dccd0f989f0544860
 admin-user: foo (password is eba680)
 foo@glaze:/usr/home/foo/tmp/shared $ cd ../src/test/
 foo@glaze:/usr/home/foo/tmp/src/test $ fossil open
 ../../shared/test.fsl
 foo@glaze:/usr/home/foo/tmp/src/test $ echo '# DO NOT READ ME' 
 README
 foo@glaze:/usr/home/foo/tmp/src/test $ fossil add README
 ADDED  README
 foo@glaze:/usr/home/foo/tmp/src/test $ fossil commit -m 'added README'
 Autosync:  http://foo@127.0.0.1:/test
 Round-trips: 1   Artifacts sent: 0  received: 0
 missing or incorrect password for user foo
 foo@glaze:/usr/home/foo/tmp/src/test $ fossil setting autosync off
 foo@glaze:/usr/home/foo/tmp/src/test $ fossil commit -m 'added README'
 New_Version: 2360769f27be6e03e22dcec699200ca10383adb5
 foo@glaze:/usr/home/foo/tmp/src/test $ fossil push
 password for foo:
 remember password (Y/n)? n
 Push to http://foo@127.0.0.1:/test
 Round-trips: 1   Artifacts sent: 2  received: 0
 Error: not authorized to write
 Round-trips: 1   Artifacts sent: 2  received: 0
 Push finished with 548 bytes sent, 277 bytes received

 So . . . I'm guessing the autosync fail is due to it assuming the local
 Fossil admin user's password being randomly set at the time the
 repository is cloned, easily solved by turning off autosync (which I
 don't want on for this anyway -- it would really screw with workflow).

 It still fails after that, though, with an authorization error:

 Error: not authorized to write

 Is there some way to give the account write authorization from the
 command line on the server?  I don't see anything in the output of
 fossil user help, and what I've found about this error in web searches
 doesn't seem to apply to my case (involving mismatched Fossil versions,
 for instance).

 --
 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
 ___
 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] failure to push/sync

[Mark Janssen]

On Aug 15, 2013 12:00 AM, Chad Perrin c...@apotheon.net wrote:

 On Wed, Aug 14, 2013 at 11:53:41PM +0200, Mark Janssen wrote:
 
  I am curious how auto sync screws with your workflow. I was of the same
  mind in the beginning, always turning of auto sync on my repos. However
  these days I always leave it on, I like the extra automatic backup.

 With a small team, I like being able to make commits locally in fairly
 small increments of change, which might leave the project in a broken
 state, so I have relatively fine-grained ability to undo changes.  When
 I get everything to a working state that's ready to share with other
 developers, then I push it to the main repository.  With autosync turned
 on, though, it'll push to the main repo every time I commit something.


I like to do the same. But even on personal projects I try to keep these
kind of experiments in a different branch. Trunk should always build. In a
different branch it also easier to back out of mistakes.

 --
 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
 ___
 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] Notification on new tickets

[Mark Janssen]

On Tue, Aug 6, 2013 at 12:32 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2013/8/5 Mark Janssen mpc.jans...@gmail.com:
  Until commit hooks are added (if ever, I do understand the issues behind
  it), I have found a nice workaround which I would like to share.

 There is an experimental branch tkt-change-hook which implements
 exactly that. Feel free to try it and report your findings.


Hi Jan,

I have built the leaf of that branch, but I can't find any change with the
trunk UI.  Any 5 minute getting started doc?

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

Re: [fossil-users] Notification on new tickets

[Mark Janssen]

On Tue, Aug 6, 2013 at 11:29 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2013/8/6 Mark Janssen mpc.jans...@gmail.com:
  I have built the leaf of that branch, but I can't find any change with
 the
  trunk UI.  Any 5 minute getting started doc?
 
  Mark

 In the UI go to Admin - Transfers  (Hooks would be a better
 name, but this is how it's named currently)
 Normally there are only Common and Push hooks there, but
 now there are two more.

 In the  Commit or Ticket hook you could put for example:
 http -async http://myhost/hook.cgi?uuid=$uuid 
 The empty  argument gives empty POST data, leaving out
 this argument gives a GET (just like in Tcl). But you could
 put any TH1 script you like here. The http TH1 command
 only works in those two hooks, no-where else in fossil.

 There is also a new setting http-allow-regexp, which
 restricts http requests. Set it to .* to get rid of all
 restrictions. This is done for security reasons.


Thanks that should be enough to get me started. If I read the source
correctly, the only additional variable that's defined in the ticket scope
is the uuid of the ticket. I think it would be useful to export more
details of the ticket and document the defined vars in the
Admin-Transfer-Ticket page.
Right now in order to have any useful content from the hook, I will need to
query the fossil repo for the info, correct?

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

[fossil-users] Notification on new tickets

[Mark Janssen]

One of the things that sites like github do much better than fossil at the
moment is to keep you informed of new tickets or ticket changes. When you
have a reasonable sized userbase this saves a lot of time in needlessly
checking the timeline for ticket changes.
Until commit hooks are added (if ever, I do understand the issues behind
it), I have found a nice workaround which I would like to share.

Fossil has built in RSS feeds with the granularity to only show ticket
changes. You can combine this with IFTTT to implement email notifications
when a new ticket is added to your main repo.

You can achieve this by combining the If feed matches trigger with the
email action. You can adapt the recipe at https://ifttt.com/recipes/109526 for
your needs.

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

Re: [fossil-users] Notification on new tickets

[Mark Janssen]

On Aug 5, 2013 8:01 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Mon, Aug 5, 2013 at 4:10 PM, Mark Janssen mpc.jans...@gmail.com
wrote:

 Fossil has built in RSS feeds with the granularity to only show ticket
changes.


 Historical anecdote: that feature was originally proposed/implemented
only recently (February) by David Given. When he first suggested it, it was
a facepalm moment for me - i couldn't believe nobody had suggested it
before.

 http://fossil-scm.org/index.html/timeline?r=timeline-rss-ticket



 You can achieve this by combining the If feed matches trigger with the
email action. You can adapt the recipe at https://ifttt.com/recipes/109526 for
your needs.


 Very nice :). Would it be possible to get a copy somewhere which doesn't
require a login? How about a Fossil doc/wiki page about how to do it?

 --

As far as I know, IFTTT requires a login to see recipes (unfortunately).
Without the linking of the RSS trigger to the email action that it does,
there is not much to describe on the wiki besides; check rss and send mail
when New ticket is in the timeline.

Mark

 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] Scripting in Fossil v2

[Mark Janssen]

I would just like to add that fossil already has a defined API in the
sense that what a fossil repo and server are is described in
http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and
http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say that
any truly useful fossil library should be built on those concepts.


On Wed, Jul 24, 2013 at 3:42 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Jul 24, 2013 at 1:55 AM, Aaron W.Hsu arcf...@sacrideo.us wrote:

 against a fossil(3) library. This functionality can therefore be provided
 by the fossil(1) executable program as well as from a separate shared
 object against which the fossil(1) program links.


 Right - that's just a question of how the modules/extensions are linked.
 That bit only affects how they are loaded/initialized, but not how they
 operate.

  Once we recognize that these are all technically orthogonal, we can then
 try to understand how they synergize together. For instance, it makes sense
 that the fossil API that is accessible through shared objects loaded by
 fossil(1) at runtime and the API provided by fossil(3) be the same.


 i hadn't ever thought explicitly about them being available via fossil(1),
 probably because the matter of where the APIs are linked to/from doesn't
 change the fundamental design (which is where the work/energy is going at
 the moment).


  On the other hand, it doesn’t make much sense for the extension API to
 be a part of fossil(3).


 Not necessarily. Where exactly those bits will/should/could live isn't a
 problem i've considered much yet. i'm at the point where i can instantiate
 and destroy a fossil instance and create formatted output to a few
 different output channels, but not yet at a point where anything really
 interesting is happening, e.g. opening an existing repo DB will be the next
 step.


1. Should fossil(3) exist at all?


 That is a fair question. Despite my overall enthusiasm and hype regarding
 fossil(3), i do have concerns about whether it is truly going to work.
 Richard has also expressed skepticism - you're not alone! i do, however,
 think that it's an interesting enough problem to be worth trying out. If it
 turns out that it's not reasonable or doesn't fit, it'll get tossed aside.
 At this point there is _no_ commitment that fossil(3) will/should/must
 happen.



1. What is the extension API?


 (Sorry, gmail is renumbering your entries when i split them.)

 i'm not yet that far along, but i expect to have some interesting
 discussions on that topic later.



1.
2. What is the fossil API?


 Notice that I’ve explicitly created a difference between the extension
 API and the fossil API. I think this is not only important, but at the crux
 of our particular current line of discourse. In particular, you’ve
 mentioned a number of times that having a fossil API, such as what
 fossil(3) might provide, sort of automatically entails extensibility and
 scriptability. I disagree with the usage of those terms here. I think one
 should distinguish clearly between the extension API and the fossil API.
 There is no extension API in fossil(3).


 i hadn't thought about those being separate until your post. i'll have to
 ponder why that separation is significant. i haven't yet gotten to the
 level of detail where i can just point to the function and say, that does
 or does not fit.



  Namely, you cannot change the way that fossil operations work. Instead,
 you are expected to have access to these operations as primitives for
 writing other programs, but by and large you are not altering the behavior
 of fossil itself.


 Correct.


  An extension API is not for providing fossil operations to the rest of
 the programming space, but is instead for the sole purpose of allowing one
 to alter the behavior of the fossil operations themselves.


 Yes, and building off of them to provide bigger or more special-purpose
 features. e.g. specialized timeline reports or exports to spreadsheets.



   Based on your prior messages, I think it is clear that you are talking
 about the fossil API, and consider that to be the really sticky issue.


 Right.


  I have no doubt that the fossil API itself is a very important and
 tricky issue. However, I want to elevate the extension API question to the
 fore here. What’s interesting and relevant here is not the fossil API, but
 the extension API. And here I want to emphasize that the fossil API and the
 extension API can both reasonably and technically exist *without* ever
 having to create a shared fossil(3) library. Whether one should do that or
 not is a different question, and important, but not the question I want to
 focus on.


 That's an interesting direction. i would at this point argue that until we
 know what the core fossil lib really should look like, that we can't say
 what will be possible with the extension API. That said, we do need to know
 what the extension API _should_ be able to do in order to design 

Re: [fossil-users] admin pages are empty and have bad titles

[Mark Janssen]

What happens if you set base_url without trailing slash? e.g. 
https://foobar.com:10443;


On Wed, Jul 24, 2013 at 4:55 PM, Eric Rubin-Smith eas@gmail.com wrote:

 I think the point here is that with a baseurl of 
 https://foobar.com:10443/;, certain links exposed by the fossil HTML
 generators wind up pointing my browser to e.g. 
 https://foobar.com:10443//page_name;, with two slashes after the port
 number.  And fossil's name resolution system does not squash the two
 slashes -- there's a paged named page_name but none named /page_name.

 Am I doing something wrong with my configs, or is a code change warranted?


 On Tue, Jul 23, 2013 at 10:30 PM, Eric Rubin-Smith eas@gmail.comwrote:

 Yes, that works for the test case.  But I think I'll need --baseurl for
 when I put fossil behind an SSL-terminating reverse proxy and want to
 access it using the company FQDN.


 On Tue, Jul 23, 2013 at 10:22 PM, Andy Bradford 
 amb-sendok-1377224557.emjjjkijcgiknbipb...@bradfords.org wrote:

 Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400:

  /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P
 10080
  --baseurl http://localhost:10080/

 Try removing the --baseurl option.

 It works for me when I do:

 fossil server /tmp/test.fossil

 ssh -L 10080:localhost:10080 remote

 Andy
 --
 TAI64 timestamp: 400051ef3a90





 ___
 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] Random thoughts on Fossil v2

[Mark Janssen]

Bit late to the party, but my 2 cents

1) Fossil as a library or API with the fossil executable as a single file
built on top of it. One could even consider a SCGI/FCGI type of interface
where the fossil binary serves JSON+BSON requests.
2) Ticket notifications by email (notification when merged into my main
repo would be fine). Using the ticketing system for any app with a decent
userbase is a pain right now.

Mark


On Tue, Jul 23, 2013 at 10:35 PM, Matt Welland estifo...@gmail.com wrote:

 Here are a couple features that would make fossil a reasonable replacement
 for zim wiki and might be worth considering for fossil2.0.

 1. Ability to Edit/save/commit files from the UI.
 2. In wiki files square brackets at beginning of line parse into check box
 list (as is done in zim wiki).




 On Sun, Jul 21, 2013 at 3:54 AM, Stephan Beal sgb...@googlemail.comwrote:

 Hi, all,

 This topic has been tossed around before, but the amount of effort
 involved in its undertaking has always kept us from actually doing it...

 To help bootstrap the process of figuring out what Fossil v2 might look
 like i have started writing down ideas in a public Google Doc:


 https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view

 Any of you who have write access to the JSON API docs also have write
 access to that one, so feel free to expand/comment/etc. It's just a big
 scratchpad, not a formal doc, nor does it provide any indication of what
 Fossil's future has in store - it's just ideas regarding what v2 might
 look like if i were to start working on it today (which, in a way, i am ;).

 If you don't have access to that doc, either send me your gmail address
 and i'll gladly add you, or post your ideas here and i'll integrate them
 into the doc.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

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




 --
 Matt
 -=-
 90% of the nations wealth is held by 2% of the people. Bummer to be in the
 majority...

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


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

[fossil-users] Latest SQLite3 broken on Android?

[Mark Janssen]

Just a quick heads up for
http://fossil-scm.org/index.html/tktview?name=752aa31a6d since I don't have
access to the sqlite3 mailing list/repo.

It seems that the latest version of SQLite3 fails to build for Android (the
Android Bionic libc doesn't have posix_fallocate).
Considering the widespread use of sqlite on Android this seems like it
could be an issue.
Fix is at
http://mpcjanssen.nl/cgi-bin/fossil/vpatch?from=ea018d154657ddd9to=f0df1fe2d8f001e3

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

Re: [fossil-users] Integrating build scripts for Android

[Mark Janssen]

For everyone still trying this out. I have some scripts for Terminal IDE
which will transform your Android device in a fossil hosting server. You
can find them at http://repos.mpcjanssen.nl/terminal-ide (hosted on my Asus
TF101)

@drh did you receive my CLA?


On Tue, Jun 11, 2013 at 9:32 PM, Mark Janssen mpc.jans...@gmail.com wrote:


 On Jun 11, 2013 8:07 PM, Matt Welland estifo...@gmail.com wrote:
 
  If some kind soul posted a binary for android somewhere accessible I'd
 be very grateful. Having the build stuff integrated is the next best thing.
 I use the shell and sshdroid and having fossil on my phone would be great.
 BTW, mounting your phone filesystem via sshfs is quite handy.
 

 Prebuilt binary at http://mpcjanssen.nl/files/fossil .

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

[fossil-users] Integrating build scripts for Android

[Mark Janssen]

I am still maintaining 2 build scripts for building fossil for Android. It
would be nice if this is included in the main fossil tree.
I think the amount of code is so small it doesn't warrant a contributors
agreement, if it does, is it possible to send a scanned copy by email?

The changes are at:
http://mpcjanssen.nl/cgi-bin/fossil/vdiff?from=55debfb1bdf794a4to=14b1e90f21ed0895detail=1sbs=0

I have put the scripts in a separate directory because the Android NDK
expects a certain directory structure.

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

Re: [fossil-users] Integrating build scripts for Android

[Mark Janssen]

On Tue, Jun 11, 2013 at 12:51 PM, Richard Hipp d...@sqlite.org wrote:

 Please do email a scan of the signed CLA.  Thanks.


CLA is on its way.



 On Tue, Jun 11, 2013 at 5:06 AM, Mark Janssen mpc.jans...@gmail.comwrote:

 I am still maintaining 2 build scripts for building fossil for Android.
 It would be nice if this is included in the main fossil tree.
 I think the amount of code is so small it doesn't warrant a contributors
 agreement, if it does, is it possible to send a scanned copy by email?

 The changes are at:
 http://mpcjanssen.nl/cgi-bin/fossil/vdiff?from=55debfb1bdf794a4to=14b1e90f21ed0895detail=1sbs=0

 I have put the scripts in a separate directory because the Android NDK
 expects a certain directory structure.


 How do you actually use Fossil on an Android device, since it is a shell
 application?  Is there a shell I can use on Android?  I mean something
 other than adb shell -  some way to use Fossil directly on the device
 without hooking it up to a workstation?


I use Terminal IDE [1] from the Playstore. It has a complete unix like
environment without the need for root. Everything I tried with fossil in
that environment works (after setting $HOME) including hosting repos from
my tablet. Best of all, you do not need root privileges for this.

[1]
https://play.google.com/store/apps/details?id=com.spartacusrex.spartacusidehl=en


 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 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] Integrating build scripts for Android

[Mark Janssen]

On Tue, Jun 11, 2013 at 3:32 PM, David Given d...@cowlark.com wrote:

 Richard Hipp wrote:
 [...]
  How do you actually use Fossil on an Android device, since it is a shell
  application?  Is there a shell I can use on Android?  I mean something
  other than adb shell -  some way to use Fossil directly on the device
  without hooking it up to a workstation?

 There's a version I've seen here:


 https://play.google.com/store/apps/details?id=es.dadbiz.fossilfeature=search_result#?t=W251bGwsMSwxLDEsImVzLmRhZGJpei5mb3NzaWwiXQ
 ..

 It seems to be the CLI version wrapped in a Java GUI to let you start it
 as an Android app. I've never tried it myself, though.


That version will not allow you to checkout files from the repos or commit
changes. It's only intended to host repositories. Because I develop on my
tablet using AIDE I need this ability. I can develop my Android app on my
tablet only using a combination of fossil, Terminal IDE and AIDE. It works
surprisingly well.

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

Re: [fossil-users] Integrating build scripts for Android

[Mark Janssen]

On Tue, Jun 11, 2013 at 4:04 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jun 11, 2013 at 4:03 PM, Stephan Beal sgb...@googlemail.comwrote:

 i tried getting fossil running under AIDE last summer but had no luck.
 Would you mind posting a short HOWTO? (i would gladly add it to the fossil
 docs collection!).


 s/AIDE/Terminal IDE/


 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

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


The trick of getting it to run in Terminal IDE is to install it at the
proper location. What I did was to download the cross-compiled to /sdcard.

Then:

1) Install Terminal IDE from Playstore
2) Start Terminal IDE, Install System if needed and open a new Terminal
3) cp /sdcard/fossil ~/local/bin
4) chmod a+x ~/local/bin/fossil
5) Restart the terminal IDE sessions

That should be all.

Note that when you remove Terminal IDE and reinstall it, you will need to
redo this. If you upgrade, fossil should be preserved.

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

Re: [fossil-users] Integrating build scripts for Android

[Mark Janssen]

On Jun 11, 2013 8:07 PM, Matt Welland estifo...@gmail.com wrote:

 If some kind soul posted a binary for android somewhere accessible I'd be
very grateful. Having the build stuff integrated is the next best thing. I
use the shell and sshdroid and having fossil on my phone would be great.
BTW, mounting your phone filesystem via sshfs is quite handy.


Prebuilt binary at http://mpcjanssen.nl/files/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] Did you know that Fossil could do...

[Mark Janssen]

On Tue, May 28, 2013 at 3:08 PM, Richard Hipp d...@sqlite.org wrote:

 Survey:  How many people know that in the web-based timeline for Fossil,
 you can click on any two nodes in the graph and get a diff between those
 two nodes?

 I think this is a very useful feature.  But I'm guessing that not many
 people know it exists.  Please confirm or refute my guess.

 And assuming I'm guessing correctly, do you have any suggestions on how I
 can get the word out about this and other useful but obscure features of
 Fossil?
 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


I did not know this, but find it very useful.
___
fossil-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 not recognizing changes to binary files?

[Mark Janssen]

I have never seen this myself personally. How can you tell that the
executables on Linux are gzipped? I seem to recall that Tclkits use some
gzip compressed parts (which might have the file utility report it as a
gzipped archive incorrectly). What happens if you don't manually gunzip the
files?

Mark


On Tue, May 7, 2013 at 5:22 PM, Randy Melton seade...@gmail.com wrote:

 I'm even more convinced that this is a bug.

 If I edit one of the binary files as follows:
 echotclkit-8.5.2-win64.exe.exe

 fossil will see the binary as modified.

 Is it possible that fossil compresses binaries, and that it doesn't see
 the difference between a compressed binary, and an uncompressed copy if you
 were to uncompress it in place?

 thanks,
 randy


 On Mon, May 6, 2013 at 6:33 PM, Randy Melton seade...@gmail.com wrote:

 (I apologize if this comes across twice.  I sent it the first time before
 I had approved the mailinglist menbership.  Since I didn't see it in the
 archives I'll try this one last time)

 This seems like a bug, but I assumed I was just doing something wrong...
 (I googled but couldn't find anything relevant)

 -(ticket info b391405a01a6e2fa5a15b8c9dc74c69721d9e99f)
 I started a repository on a win7 box, and added/committed 5 executable
 files.
 I got the ... contains binary data... message and I answered commit
 anyhow? a for all.

 I cloned the repository on a linux box only to find that the binary
 executables were gzipped (without the extension).  I unzipped them and can
 see that they are bigger, but when i try to commit in fossil I get fossil:
 nothing has changed.

 I see that they are bigger, but I can't convince fossil to commit the
 files?
 ---

 --- (update)
 I decided to ignore the binary files, and started working in another
 directory.  I added the new (text) files and got this error when i tried to
 commit it:
 Autosync:  https://seade...@chiselapp.com/user/seadevil/repository/frusta
 Bytes  Cards  Artifacts Deltas
 Sent: 130  1  0  0
 Received: 400  8  0  0
 Total network traffic: 349 bytes sent, 0 bytes received
 New_Version: dc5f5d61a3aa327d790e7e078782858f7a73d30f
 ERROR: [kits/tclkit-8.5.1-darwin-univ-aqua] is 3828076 bytes on disk but
 2482275 in the repository
 ERROR: [kits/tclkit-8.5.1-linux-x86] is 2180434 bytes on disk but 1472785
 in the repository
 ERROR: [kits/tclkit-8.5.2-linux-arm] is 2177577 bytes on disk but 1470298
 in the repository
 fossil: working checkout does not match what would have ended up in the
 repository:  f27a586a65392d98b48b00721ec8894c versus
 c028939fcae635a6cb1e55fbe1a22ac4
 ---

 Any help is appreciated
  randy melton



 ___
 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] Patch for building fossil for Android using NDK

[Mark Janssen]

On Fri, Mar 15, 2013 at 2:53 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:

 2013/3/15 Mark Janssen mpc.jans...@gmail.com:
  I have attached the patch for those who are interested. Currently you
 need
  to build on Linux because of the source translation step. It would be
 nice
  if this could somehow be included in fossil proper.

 The change to src/user.c looks good to me, except for the line:
   #ifdef __MINGW32__
 which should be:
   #if defined(_WIN32)


I did not touch that line, it was already there, but if that is better, I
could change it at the same time.


 Did you sign a Contributor Agreement?:
https://www.fossil-scm.org/index.html/doc/trunk/www/contribute.wiki


Not yet, I have no problems signing one, I just need to see how to get it
to drh. Would a scanned copy suffice?


 For the other changes, I don't think they should go in their
 own android directory, but I have no idea what the
 correct place should be.


Me neither. Thing is the android ndk-build script expects a jni
subdirectory so I am not sure how easy it is to change the directory
structure. When including this in fossil proper, this should be looked into.



 Bedankt!


Graag gedaan!


Jan Nijtmans
 ___
 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] proxy setting and ssh:// url

[Mark Janssen]

This probably fixes issue 137cf42ad9 as well. Can't check at the moment but
will check when at work.


On Fri, Mar 15, 2013 at 3:37 PM, Stephan Beal sgb...@googlemail.com wrote:


 On Fri, Mar 15, 2013 at 2:42 PM, Martin Gagnon eme...@gmail.com wrote:

 Here's a patch that should ignore proxy settings with file:// and ssh://
 protocol..


 To work around the (presumably missing?) contributor agreement i rewrote
 the patch (all 15 or 20 bytes of it). It's now checked in:

 http://fossil-scm.org/index.html/info/0d55a0ad0f

 i don't have any repos which use file:// or ssh:// protocols, nor am i
 behind a proxy, so i'd ask someone who has such a setup to double-check
 that this commit works.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal

 ___
 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] problems........

[Mark Janssen]

Looks like you still  have a stray _FOSSIL_ file in your C:\.

 

 

From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of android
devkit
Sent: maandag 16 januari 2012 16:43
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] problems

 

Dear all
I didn't like to start this email in a negative manner but unfortunately I
will. I have spent 2 days trying to make fossil run in my windows xp
machine.

To start with someone must place a note that in windows paths must be
treated differently (WITHOUT BEEN A 100% SURE)
c:/P/prg1.fossil and not c:\P\prg1.fossil

I have stack on the followings
C:\P\prg1fossil open c:\P\prg1.fossil
C:\WINDOWS\system32\fossil.exe: SQLITE_ERROR: no such table: vvar
C:\WINDOWS\system32\fossil.exe: no such table: vvar
REPLACE INTO vvar(name,value) VALUES('repository','c:/P/prg1.fossil'
)
Even if I removed the files _FOSSIL_ and prg1.fossil when I open the fossil
file I get the error.
To create a new one is ok (fossil init or new )


In the first attempt I had it looks like that I have places the P folter in
my document folder. Ever since nothing worked. (there is an open bug that
fossil does not work if it linked from this folder. I have removed the
folders and files changed names, move to c:\ but no luck)


---
If you have recently updated your fossil executable, you might
need to run fossil all rebuild to bring the repository
schemas up to date.
Updating does not do anything.

I also get this error, from the 
C:\WINDOWS\system32\fossil.exe: already within an open tree rooted at C:/
Even when is the first time trying to open a file



I had the best intentions to use fossil 
Why all the wired things happens to me, if the windows version was not
stable it would had been noted. 

___
fossil-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 crashes on Windows

[Mark Janssen]

Unless this is not the whole story, this is not a crash, Fossil gives an
error. Did you try the solution suggested in the error message?

Try a fossil rebuild from the checkout.

Mark

-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of François
Vogel
Sent: dinsdag 10 januari 2012 22:06
To: fossil-users@lists.fossil-scm.org
Subject: [fossil-users] Fossil crashes on Windows

Hi all,

On Windows Vista, I get repeatable crashes of fossil (application stops
working and brutally crashes).

This happens when running fossil revert (whatever the rest of the command
is), for instance:

C:\Users\francois\Documents\Development\tcltk-fossil\tk-fossil\testsfossi
l
changes
EDITED ../generic/tkTextMark.c
EDITED textMark.test
C:\Users\francois\Documents\Development\tcltk-fossil\tk-fossil\testsfossi
l
revert textMark.test
C:\Users\francois\Documents\Development\tcltk-fossil\fossil.exe:
SQLITE_BUSY: statement aborts at 2: [ROLLBACK] cannot rollback transaction
- SQL statements in progress
C:\Users\francois\Documents\Development\tcltk-fossil\fossil.exe:
cannot rollback transaction - SQL statements in progress ROLLBACK

If you have recently updated your fossil executable, you might need to run
fossil all rebuild to bring the repository schemas up to date.

C:\Users\francois\Documents\Development\tcltk-fossil\tk-fossil\testsfossi
l
version
This is fossil version 1.21 [002580c50d] 2011-12-13 13:53:56 UTC


Even when providing no argument to fossil revert, I get the same crash of
fossil.

This happens also when fossil diff FILE, but not when fossil diff with no
additional argument.

I have looked at the fossil tickets tracker, but did not find anything
obviously related.

Thanks for any hint,
Francois

___
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] Error: wrong project

[Mark Janssen]

There is a mismatch in the project-codes. Fortunately chiselapp
provides functionality to fix this. When creating the repository on
chiselapp override the project code with the project-code you get when
doing fossil info -R repository.

On Tue, Dec 20, 2011 at 11:05 AM,  bobef...@free.fr wrote:
 Hello,

 I have a fossil repository that I would like to put on chiselapp.com.

 I cannot upload it because it is larger than 8M. Chiselapp website suggests 
 to create a new project then push to it:

 Limit 8M in size. If your repository is larger than this, create a new empty 
 project and push to it instead.

 When I try to push from my current local repository to new on chiselapp, I 
 get this error:

 Error: wrong project

 Is there a way to push/pull/sync between unrelated repositories?


 Thanks.


 ___
 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] Mailing list archives for fossil-users not available?

[Mark Janssen]

 http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/ works
for me (from the fossil home page)

On Tue, Dec 6, 2011 at 2:07 AM, Steve Bennett ste...@workware.net.au wrote:
 My email has been broken for a few days, so I went to check
 the archives.

 Any of the links at:
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/private/fossil-users

 says No such list ...

 fossil-dev seems ok.

 Cheers,
 Steve

 --
 µWeb: Embedded Web Framework - http://uweb.workware.net.au/
 WorkWare Systems Pty Ltd
 W: www.workware.net.au      P: +61 434 921 300
 E: ste...@workware.net.au   F: +61 7 3391 6002





 ___
 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] Getting a binary artifact

[Mark Janssen]

2011/11/2 Lluís Batlle i Rossell virik...@gmail.com:
 On Wed, Nov 02, 2011 at 01:00:50PM +0100, Eduardo Morras wrote:
 Sorry to contact you directly Lluis, i can receive mail form list
 but can't post (my isp blacklisted this list)

 Weird. How could that happen?

 At 12:19 02/11/2011, Lluís Batlle i Rossell wrote:
 I've just tried:
 
 fossil artifact c06ece1cc56e4713435c0bd1f1b70627248b4b6b  file.png
 
 And this outputs only 8 bytes of the png file. Maybe the artifact command
 assumes a text output?

 Do a cat file.png

 The filename 'file.png' has 8 bytes, perhaps you are getting only the 
 filename.

 No no, the file has more bytes:

 $ wc -l file.png
 12583 file.png
 $ sha1sum file.png
 449e8639f9889bbff781ed916a49cb8394110f77  file.png
 $ fossil artifact 449e8639f9889bbff781ed916a49cb8394110f77 | wc -l
 8

 What do you think?
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


The artifact command uses fossil_puts to display the contents. Fossil
puts uses strlen to determine the number of chars to be written. So
for binary files with embedded nulls this will fail.
Using fossil_puts in this case is arguably a mistake as it also does
encoding conversion.
You can work around it by providing a filename with the artifact command.

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

Re: [fossil-users] Getting a binary artifact

[Mark Janssen]

On Wed, Nov 2, 2011 at 2:35 PM, Mark Janssen mpc.jans...@gmail.com wrote:
 2011/11/2 Lluís Batlle i Rossell virik...@gmail.com:
 On Wed, Nov 02, 2011 at 01:00:50PM +0100, Eduardo Morras wrote:
 Sorry to contact you directly Lluis, i can receive mail form list
 but can't post (my isp blacklisted this list)

 Weird. How could that happen?

 At 12:19 02/11/2011, Lluís Batlle i Rossell wrote:
 I've just tried:
 
 fossil artifact c06ece1cc56e4713435c0bd1f1b70627248b4b6b  file.png
 
 And this outputs only 8 bytes of the png file. Maybe the artifact command
 assumes a text output?

 Do a cat file.png

 The filename 'file.png' has 8 bytes, perhaps you are getting only the 
 filename.

 No no, the file has more bytes:

 $ wc -l file.png
 12583 file.png
 $ sha1sum file.png
 449e8639f9889bbff781ed916a49cb8394110f77  file.png
 $ fossil artifact 449e8639f9889bbff781ed916a49cb8394110f77 | wc -l
 8

 What do you think?
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


 The artifact command uses fossil_puts to display the contents. Fossil
 puts uses strlen to determine the number of chars to be written. So
 for binary files with embedded nulls this will fail.
 Using fossil_puts in this case is arguably a mistake as it also does
 encoding conversion.
 You can work around it by providing a filename with the artifact command.

 Mark


Following patch fixes the issue.


Index: src/blob.c
==
--- src/blob.c
+++ src/blob.c
@@ -766,12 +766,11 @@
 int blob_write_to_file(Blob *pBlob, const char *zFilename){
   FILE *out;
   int wrote;

   if( zFilename[0]==0 || (zFilename[0]=='-'  zFilename[1]==0) ){
-fossil_puts(blob_str(pBlob), 0);
-return blob_size(pBlob);
+return write(1, blob_str(pBlob) , blob_size(pBlob));
   }else{
 int i, nName;
 char *zName, zBuf[1000];

 nName = strlen(zFilename);
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Getting a binary artifact

[Mark Janssen]

On Wed, Nov 2, 2011 at 3:02 PM, Richard Hipp d...@sqlite.org wrote:
 On Wed, Nov 2, 2011 at 9:41 AM, Mark Janssen mpc.jans...@gmail.com wrote:

 Following patch fixes the issue.


 This fixes viriketo's specific complaint, but it also creates a bunch of new
 problems for people running windows with non-UTF character sets.



 Index: src/blob.c
 ==
 --- src/blob.c
 +++ src/blob.c
 @@ -766,12 +766,11 @@
  int blob_write_to_file(Blob *pBlob, const char *zFilename){
   FILE *out;
   int wrote;

   if( zFilename[0]==0 || (zFilename[0]=='-'  zFilename[1]==0) ){
 -    fossil_puts(blob_str(pBlob), 0);
 -    return blob_size(pBlob);
 +    return write(1, blob_str(pBlob) , blob_size(pBlob));
   }else{
     int i, nName;
     char *zName, zBuf[1000];

     nName = strlen(zFilename);
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



 --
 D. Richard Hipp
 d...@sqlite.org

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



Without wanting to open a huge can of worms, IMHO a DVCS should return
artifacts unmodified (e.g. treat everything as a binary file). In my
experience any automatic conversions are fragile and promote
sloppiness and it quickly leads to the mess of guessing if an artifact
is binary or text. If the encoding of a source file matters for
non-UTF windows users they should store the file in the encoding that
works for them or use ASCII only options to store non-ASCII chars
(\u... for example).

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

Re: [fossil-users] Getting a binary artifact

[Mark Janssen]

On Wed, Nov 2, 2011 at 3:38 PM, Richard Hipp d...@sqlite.org wrote:
 On Wed, Nov 2, 2011 at 10:13 AM, Mark Janssen mpc.jans...@gmail.com wrote:

 Without wanting to open a huge can of worms, IMHO a DVCS should return
 artifacts unmodified (e.g. treat everything as a binary file).

 And Fossil does exactly that.  It preserves all files exactly.

 But in many parts of the world, when you are running windows, you have to
 convert characters for display on the console.  So, the generic routine for
 displaying text on the console - the routine that you modified - needs to
 convert to whatever character codes are used by the locale setting.  Note
 that Fossil assumes that standard output is going to a console, not to a
 file.  Conversions are appropriate on standard output.


I agree that console output for windows users for example of commit
messages should be readable regardless of system encoding. I still
think conversions are not appropriate for output of fossil artifact
(you are asking for the artifact verbatim) This is also why I made the
change in  blob_write_to_file and not in fossil_puts. As I windows
user myself,  I expected fossil artifact uuid  file to work. I would
not be surprised if fossil wrappers use this on windows to display
specific artifacts.

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

Re: [fossil-users] Getting a binary artifact

[Mark Janssen]

On Wed, Nov 2, 2011 at 7:32 PM, Richard Hipp d...@sqlite.org wrote:


 On Wed, Nov 2, 2011 at 2:27 PM, Mark Janssen mpc.jans...@gmail.com wrote:

 On Wed, Nov 2, 2011 at 3:38 PM, Richard Hipp d...@sqlite.org wrote:
  On Wed, Nov 2, 2011 at 10:13 AM, Mark Janssen mpc.jans...@gmail.com
  wrote:
 
  Without wanting to open a huge can of worms, IMHO a DVCS should return
  artifacts unmodified (e.g. treat everything as a binary file).
 
  And Fossil does exactly that.  It preserves all files exactly.
 
  But in many parts of the world, when you are running windows, you have
  to
  convert characters for display on the console.  So, the generic routine
  for
  displaying text on the console - the routine that you modified - needs
  to
  convert to whatever character codes are used by the locale setting.
  Note
  that Fossil assumes that standard output is going to a console, not to a
  file.  Conversions are appropriate on standard output.
 

 I agree that console output for windows users for example of commit
 messages should be readable regardless of system encoding. I still
 think conversions are not appropriate for output of fossil artifact
 (you are asking for the artifact verbatim) This is also why I made the
 change in  blob_write_to_file and not in fossil_puts. As I windows
 user myself,  I expected fossil artifact uuid  file to work. I would
 not be surprised if fossil wrappers use this on windows to display
 specific artifacts.

 But, if you requested the output of a text artifact, you would probably also
 expect to be able to read the artifact if it appeared on standard output, I
 suspect.

Nope, I would expect the artifact without changes, if I want a
readable interpretation I would look for something like fossil cat
or fossil artifact-as-readable-in-my-encoding.


 With the patch I put in, you can now have both.  On windows, it uses
 _isatty() to determine if the content is going to the console or to a file,
 and only converts if it is going to the console.


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



 --
 D. Richard Hipp
 d...@sqlite.org

 ___
 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] build error, missing manifest.uuid

[Mark Janssen]

On Wed, Mar 30, 2011 at 6:39 PM, Zed A. Shaw zeds...@zedshaw.com wrote:
 Uh, this may sound stupid but latest trunk fails with:

 make: *** No rule to make target `src/../manifest.uuid', needed by
 `bld/VERSION.h'.  Stop.

 Because, for some reason, my checkout on this one machine does not have
 a manifest.uuid.

 Any idea why this might be happening?

 --
 Zed A. Shaw
 http://zedshaw.com/
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Make sure the manifest repo setting is enabled. (fossil settings manifest on)

Mark
___
fossil-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 305143bd876f693f446f78d12dbef143c46eec58

[Mark Janssen]

On Mon, Mar 21, 2011 at 3:21 PM, Richard Hipp d...@sqlite.org wrote:



 On Mon, Mar 21, 2011 at 10:01 AM, Michael Richter ttmrich...@gmail.comwrote:

 OK, perhaps I'm being as thick as a whale omlette here, but I cannot get
 this to work at all.

 First attempt: relay-to was set to www.fossil-scm.org:80, listen was
 set to 8180.  I access http://localhost:8180 and I get ... the SQLite
 home page, not Fossil's.  Tinkering around with various values for
 relay-to always gets me either SQLite's home page or error messages.

 What, precisely, should I be setting up in there?


 Bummer.

 www.sqlite.org and www.fossil-scm.org use the same IP address.  The web
 server distinguishes between them by looking at the HOST: parameter in the
 HTTP header.  But with the setup above, the HOST: parameter is being set to
 localhost:8180 which the web server then defaults to SQLite.

 I'm not sure how to work around that.  Anybody else have any ideas on how
 to eavesdrop on the TCP/IP connection between the web browser and the Fossil
 web server?





 On 21 March 2011 21:49, Michael Richter ttmrich...@gmail.com wrote:

 Oops.  I didn't see this, Richard.  Sorry.  I'll get this set up now and
 send you the results.

 Once I figure out how to get Tcl working.  :)


 On 17 March 2011 01:21, Richard Hipp d...@sqlite.org wrote:

 On Wed, Mar 16, 2011 at 11:30 AM, Michael Richter ttmrich...@gmail.com
  wrote:


 OK, this is the sequence I've tried on my main workstation (Ubuntu
 10.04):

 1.  Delete all fossil-scm.org cookies.
 2.  Close my browser (Chrome 10.0.648.134).
 3.  Re-open my browser.
 4.  Go to fossil-scm.org.
 5.  Log in.
 6.  Click on Timeline.

 Result: you are not logged in.

 If I repeat this experiment on my backup machine (Windows XP,
 Chrome 10.0.648.133) I do not have this problem.  Curious about that, I
 tried other browsers (Opera, Firefox) on my main machine again.  Again I
 don't have this problem.

 The issue seems specific to Chrome under Linux in my case.  I have no
 idea how to proceed from here on however because I can't figure out what
 could be going wrong that affects only Fossil and nothing else, especially
 since I killed all cookies related to the fossil-scm.org domain.

 Any suggestions or ideas on what's next to investigate?


 The attachment is a Tcl/Tk script that sets up a TCP/IP proxy.  Please
 make it point to http://www.fossil-scm.org/ and then point your Chrome
 browser at the proxy.  Record your traffic.  Send me what you see.


 --
 D. Richard Hipp
 d...@sqlite.org




 --
 Perhaps people don't believe this, but throughout all of the discussions
 of entering China our focus has really been what's best for the Chinese
 people. It's not been about our revenue or profit or whatnot.
 --Sergey Brin, demonstrating the emptiness of the don't be evil mantra.




 --
 Perhaps people don't believe this, but throughout all of the discussions
 of entering China our focus has really been what's best for the Chinese
 people. It's not been about our revenue or profit or whatnot.
 --Sergey Brin, demonstrating the emptiness of the don't be evil mantra.




 --
 D. Richard Hipp
 d...@sqlite.org

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

 Use a packet level sniffer like WireShark (http://www.*wireshark*.org)

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

Re: [fossil-users] Building fossil on Windows with MinGW - dependency on libz

[Mark Janssen]

On Fri, Mar 18, 2011 at 11:09 AM, Arjen Markus arjen.mar...@deltares.nlwrote:

 Hello,

 I have built fossil on Windows (XP) using MinGW and the gcc compiler.
 That works fine, except that the resulting executable depends on
 the libz-1.dll that is located in the MinGW bin directory.

 This means such an executable will not work if that DLL is not in
 the path (or one of the other locations for DLLs).

 Would it not be better to link against the static/archive version
 of libz?

 Regards,

 Arjen

The current makefile only links statically if FOSSIL_ENABLE_SSL is defined.
It is a fairly easy change to the Makefile to include -static for all cases.
Looking at the stand-alone design philosophy, it could be argued that this
should be the default.

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

Re: [fossil-users] Howto construct a download url for the latest file in a repository?

[Mark Janssen]

To get the trunk version of file webui.wiki, you can use (in bash):

$ fossil artifact `fossil artifact $(fossil info trunk | grep uuid | tr -s 
 | cut -d  -f2) | grep webui.wiki | cut -d  -f3`

What it does is:
Get uuid of the last trunk commit. Then get the manifest for that commit.
Then check the uuid of the file we are interested in. Then get that file.
Note that this might break in case of delta manifests. That will require
more work, but the principle will stay the same.

Mark

On Sun, Mar 13, 2011 at 1:24 PM, David Bovill da...@architex.tv wrote:

 The zip file is for the entire checkout - any way to download the latest
 version of a single file without referring to a particular version with a
 sha1?

 If not how can I deduce the sha1 of the latest commit of a given file based
 on parsing the output of fossil shell commands?


 On 12 March 2011 22:57, Richard Hipp d...@sqlite.org wrote:

 Hi Richard - the above style url, or  
 http://.../raw/libOPN_IRC.livecode?name=tip
 leads to an http download of the manifest file, not that actual file the
 manifest refers to. Any other thoughts?



 http://.../zip/checkout.zip?name=trunk


 ___
 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] git equivalent commands

[Mark Janssen]

2011/3/11 Lluís Batlle i Rossell virik...@gmail.com

 On Fri, Mar 11, 2011 at 06:58:59PM -, Eric wrote:
 
  On Fri, March 11, 2011 7:27 am, Federico Ramallo wrote:
   Hi,
  
   I was wondering how to do git reset --hard on a fossil repository.
 Because
   fossil clean only clear extra files, but what about changed files?

 'fossil revert' may be something close?


See fossil checkout and the -f option.


 ___
 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] Check-in [36e3ab4c42] breaks SSL on mingw

[Mark Janssen]

On Thu, Mar 3, 2011 at 4:55 PM, Petr Man p...@madnetwork.org wrote:
 Hello,
 Check-in [36e3ab4c42] seems to break SSL on mingw, removing -static
 from TCC fixes it.
 Petr
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


The reason the -static is there is so that you can use the resulting
fossil standalone on a machine where no mingw is installed.
For building it, you need the static SSL libraries which can be a bit
of a pain to find.

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

[fossil-users] [PATCH] Patches for MinGW makefile

[Mark Janssen]

Please find attached a patch that contains the following changes to
the windows Makefile.mingw

* Build the fossil.exe with the icon file in /win
* Add a setup target to the Makefile to create a windows installer
(requires NSIS)
* Change the Makefile so that SSL enabled builds can be created by
defining FOSSIL_ENABLE_SSL

I can split the patch in separate patches if need.

Regards,
Mark


mingw-build.patch
Description: Binary data


icon.rc
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] 3-way merge likely to happen anytime soon?

[Mark Janssen]

On Mon, Feb 21, 2011 at 6:58 PM, Petr Man p...@madnetwork.org wrote:
 On Mon, Feb 21, 2011 at 11:35:03AM -0500, Richard Hipp wrote:
 Please let me know if http://www.fossil-scm.org/fossil/info/9b7a6f80b2 works
 for you.

 I guess this closes ticket [427938e2f6].

 --
 My GnuPG key is at http://petr.madnetwork.org/home/contact/pubkey.asc
 Key fingerprint = 0F04 503F EF79 2B8D B63C  00B4 AD2F 0594 FAA5 0053

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



Unless I am missing something in how to use the 3-way merge, there are
a couple of problems with the current implementation on the trunk.

1) There seems to be an off by n error in the string_subst logic in
merge3.c leading to a garbled merge command.
2) When the file is successfully merged by the external tool, I still
get a merge conflict message.
3) After completing the merge with the tool, temporary files are not cleaned up.
4) It seems the for loop checking the substitutions can access memory
beyond the end of zInput (for example if the gmerge-command ends with
%a)

Can anyone confirm these findings? I have tested with the following setting:
fossil settings gmerge-command c:\Docs\Bin\KDiff3\kdiff3.exe
\%original\ \%baseline\ -o \%output\

The patch below addresses all 4 problems mentioned above.

Regards,
Mark

@@ -349,12 +349,12 @@
 if( i0 ){
   blob_append(x, zInput, i);
   zInput += i;
 }
-if( zInput[i]==0 ) break;
+if( zInput[0]==0) break;
 for(j=0; jnSubst; j+=2){
   int n = strlen(azSubst[j]);
-  if( memcmp(zInput, azSubst[j], n)==0 ){
+  if( n=strlen(zInput)  memcmp(zInput, azSubst[j], n)==0 ){
 blob_append(x, azSubst[j+1], -1);
 zInput += n;
 break;
   }
@@ -421,9 +421,16 @@
   azSubst[6] = %output;azSubst[7] = zOut;
   zCmd = string_subst(zGMerge, 8, azSubst);
   printf(%s\n, zCmd); fflush(stdout);
   fossil_system(zCmd);
-  if( file_size(zOut)=0 ) blob_read_from_file(pOut, zOut);
+  if( file_size(zOut)=0 ) {
+blob_read_from_file(pOut, zOut);
+/* Merge was succesful, Return success result and cleanup
temporary files. */
+unlink(zPivot);
+unlink(zOrig);
+unlink(zOther);
+rc = 0 ;
+  }
   unlink(zOut);
   fossil_free(zCmd);
   fossil_free(zOut);
 }
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Segfaults on Solaris when serving a directory

[Mark Janssen]

On Mon, Feb 21, 2011 at 11:21 AM, Petr Man p...@madnetwork.org wrote:
 Hello,
 I have been successfully using Fossil on SunOS 5.10/sparc for over six
 months. I wanted to set up a permanent cgi server this morning, but I
 am getting core dumps when I try to serve a directory with fossil
 files. With a separate cgi script for each repo, everything works
 flawlessly. I would like to debug the problem, but unfortunately I
 don't have a debugger on the machine. Is anyone able to help?
 Petr
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Do the fossil repos have the extension .fossil? If not then you will
get a segfault.

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

Re: [fossil-users] branch vs tags when importing from git

[Mark Janssen]

On Tue, Feb 15, 2011 at 1:41 PM, Richard Hipp d...@sqlite.org wrote:


 On Sun, Feb 13, 2011 at 4:15 PM, Richard Hipp d...@sqlite.org wrote:


 On Sun, Feb 13, 2011 at 4:09 PM, Martin Gagnon eme...@gmail.com wrote:

 I've convert a git repository to fossil and I'm a bit confuse with my
 tags I had in git, the way they become in fossil.

 I had some tag in the original git repo, which was not branch, only a
 tag to a particular version. Once I convert to fossil, those tag
 propagate to future versions until next tag is reach. Those tags
 seems to be like real branches after conversion to fossil.

 Did someone else get the same problem? Or I miss something?

 I've seen the same thing.

 Either I'm misunderstanding the git-fast-export file format documentation
 or else git-fast-export is getting branches and tags confused.

 git-fast-import works and generates the correct repository for the output of
 git-fast-export.  So there must be some way of interpreting the output of
 git-fast-export correctly.  Anybody with clues on how to do this, please
 help!



   I'm not sure which it is, but I am leaning toward the problem being in
 git-fast-export.  Others have reported issues with that tool, and the
 documentation for git-fast-export itself explains that it cannot
 successfully export the Linux kernel repository

 I've got some ideas on how I might work around the (presumed) brokenness
 in git-fast-export.  If you are able to send me the output of
 git-fast-export from your repository, or let me clone you git repository,
 that will give me another example repository to work with.



 Thanks

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



 --
 D. Richard Hipp
 d...@sqlite.org



 --
 D. Richard Hipp
 d...@sqlite.org

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



Maybe I am missing something here, but aren't tags simply identifiable
by commits with revision prefix /refs/tags?


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

Re: [fossil-users] branch vs tags when importing from git

[Mark Janssen]

On Tue, Feb 15, 2011 at 2:31 PM, Mark Janssen mpc.jans...@gmail.com wrote:
 On Tue, Feb 15, 2011 at 1:41 PM, Richard Hipp d...@sqlite.org wrote:


 On Sun, Feb 13, 2011 at 4:15 PM, Richard Hipp d...@sqlite.org wrote:


 On Sun, Feb 13, 2011 at 4:09 PM, Martin Gagnon eme...@gmail.com wrote:

 I've convert a git repository to fossil and I'm a bit confuse with my
 tags I had in git, the way they become in fossil.

 I had some tag in the original git repo, which was not branch, only a
 tag to a particular version. Once I convert to fossil, those tag
 propagate to future versions until next tag is reach. Those tags
 seems to be like real branches after conversion to fossil.

 Did someone else get the same problem? Or I miss something?

 I've seen the same thing.

 Either I'm misunderstanding the git-fast-export file format documentation
 or else git-fast-export is getting branches and tags confused.

 git-fast-import works and generates the correct repository for the output of
 git-fast-export.  So there must be some way of interpreting the output of
 git-fast-export correctly.  Anybody with clues on how to do this, please
 help!



   I'm not sure which it is, but I am leaning toward the problem being in
 git-fast-export.  Others have reported issues with that tool, and the
 documentation for git-fast-export itself explains that it cannot
 successfully export the Linux kernel repository

 I've got some ideas on how I might work around the (presumed) brokenness
 in git-fast-export.  If you are able to send me the output of
 git-fast-export from your repository, or let me clone you git repository,
 that will give me another example repository to work with.



 Thanks

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



 --
 D. Richard Hipp
 d...@sqlite.org



 --
 D. Richard Hipp
 d...@sqlite.org

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



 Maybe I am missing something here, but aren't tags simply identifiable
 by commits with revision prefix /refs/tags?


 Mark


After some further investigation, it seems that git fast-export is
making a mess of the tags. Commit commands refer to tags that have not
been created yet. This does not play very well with the fossil
approach of not rewriting history. I suspect the only way to solve
this is to make a separate non propagating tagging phase after the
whole repo has been converted.

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

[fossil-users] Fossil cannot add filenames with \*[]?

[Mark Janssen]

Hi,

I noticed fossil will not add files containing any of the characters
\*[]?. If I remove the checks for these chars, I cannot find any
adverse effects. Is there a specific reason these characters are
forbidden?

Regards,
Mark
___
fossil-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 cannot add filenames with \*[]?

[Mark Janssen]

On Mon, Aug 17, 2009 at 3:08 PM, Stephan Bealsgb...@googlemail.com wrote:
 On Mon, Aug 17, 2009 at 12:06 PM, Mark Janssen mpc.jans...@gmail.com
 wrote:

 I noticed fossil will not add files containing any of the characters
 \*[]?. If I remove the checks for these chars, I cannot find any
 adverse effects. Is there a specific reason these characters are
 forbidden?

 The ?:* characters are forbidden by FAT/VFAT filesystems. i cannot account
 for the [] being forbidden - it may be limited on other platforms (i just
 tried it on WinXP and Solaris 10, and [] are allowed there).



 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/


Hmmm for [] VMS comes to mind.
So fossil takes the common denominator for file names on all
platforms? Although that's certainly good for portability of the
repos, it does limit the artifact names you can use. Renaming the
artifacts to a name which is allowed, is not always an option. Perhaps
a warning would be more appropriate?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users