Re: [fossil-users] Fossil use question

[D. Richard Hipp]

On Apr 22, 2010, at 7:29 AM, verizon wrote:

   No the repository has no branches.  I did find the server where the  
 repository is kept had a clock that was 1 hour ahead of current  
 time.  (Not sure how it got that way, it had shifted to Daylight  
 savings time but was an hour ahead).  Anyway this is now fixed but  
 the problem persists.

 Also I have my repository set to NOT auto sync since I am frequently  
 not connected to the company network.  But when I sync I sometimes  
 have to do this a number of times before it stabilizes and large  
 chunks of data stop being exchanged.

 I am running  fossil version [2255e4e3ba] 2009-12-20 02:58:18 UTC.

I don't know what is causing the problem and can't really trouble- 
shoot it without access to your specific repository.  Please know that  
we do pretty much the same thing you describe multiple times per day,  
every day, and it works great for us and has so for years.  So there  
must be something different about your configuration that is tickling  
a bug somehow.  But I don't yet have any idea what that might be.

It wouldn't hurt you to upgrade to the latest version of Fossil.  It  
might not fix the problem, but on the other hand it might, and it  
probably won't hurt in any event.  Be sure to run fossil rebuild  
after upgrading.



   --jim schimpf
 On 21 Apr, 2010, at 16:44, D. Richard Hipp wrote:


 On Apr 21, 2010, at 4:39 PM, verizon wrote:

 I am working on a project with another developer and we are using a
 server hosted fossil repository and have hit this problem.  When say
 I make changes to some source files, commit this to the repository
 and sync with the network server.  The other developer then sync's
 with the repository but then fossil update does not show any changes
 needed.  So he does not see any file changes with command:

 fossil update -n -v | grep -v UNCHANGED

 We have found (at least for now) the easiest approach is to blow
 away his source files, do fossil open to his (synched) local
 repository and then he has the updated files.

 I know I am missing something really obvious here as I thought just
 this situation was what source control systems were for.  I had not
 noticed this previously since I was the only one using the  
 repository.


 This might happen if the you and the other developer are on separate
 branches or forks.  Try running

  fossil update --latest

 And/or run fossil ui and look at the graph to see whether or not  
 you
 are on separate forks, and if so, merge them together.

 If you just run fossil update it moves you to the latest check-in
 which is a direct descendent of your current check-in.  So if another
 developer has made check-ins that are on a different branch or fork,
 nothing will happen.

 D. Richard Hipp
 d...@hwaci.com



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

 ___
 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...@hwaci.com



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

Re: [fossil-users] Fossil use question

[D. Richard Hipp]

On Apr 22, 2010, at 7:29 AM, verizon wrote:

   No the repository has no branches.  I did find the server where the  
 repository is kept had a clock that was 1 hour ahead of current  
 time.  (Not sure how it got that way, it had shifted to Daylight  
 savings time but was an hour ahead).  Anyway this is now fixed but  
 the problem persists.

 Also I have my repository set to NOT auto sync since I am frequently  
 not connected to the company network.  But when I sync I sometimes  
 have to do this a number of times before it stabilizes and large  
 chunks of data stop being exchanged.

 I am running  fossil version [2255e4e3ba] 2009-12-20 02:58:18 UTC.

Are you *sure* you are not on separate forks of the same branch?

If you upgrade to the latest version of Fossil, you'll see a graph of  
changes on the left hand side of the timeline.  That graph might give  
clues to your problem.  Remember to run fossil rebuild after  
upgrading.


   --jim schimpf
 On 21 Apr, 2010, at 16:44, D. Richard Hipp wrote:


 On Apr 21, 2010, at 4:39 PM, verizon wrote:

 I am working on a project with another developer and we are using a
 server hosted fossil repository and have hit this problem.  When say
 I make changes to some source files, commit this to the repository
 and sync with the network server.  The other developer then sync's
 with the repository but then fossil update does not show any changes
 needed.  So he does not see any file changes with command:

 fossil update -n -v | grep -v UNCHANGED

 We have found (at least for now) the easiest approach is to blow
 away his source files, do fossil open to his (synched) local
 repository and then he has the updated files.

 I know I am missing something really obvious here as I thought just
 this situation was what source control systems were for.  I had not
 noticed this previously since I was the only one using the  
 repository.


 This might happen if the you and the other developer are on separate
 branches or forks.  Try running

  fossil update --latest

 And/or run fossil ui and look at the graph to see whether or not  
 you
 are on separate forks, and if so, merge them together.

 If you just run fossil update it moves you to the latest check-in
 which is a direct descendent of your current check-in.  So if another
 developer has made check-ins that are on a different branch or fork,
 nothing will happen.

 D. Richard Hipp
 d...@hwaci.com



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

 ___
 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...@hwaci.com



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

Re: [fossil-users] Fossil use question

[D. Richard Hipp]

On Apr 21, 2010, at 4:39 PM, verizon wrote:

   I am working on a project with another developer and we are using a  
 server hosted fossil repository and have hit this problem.  When say  
 I make changes to some source files, commit this to the repository  
 and sync with the network server.  The other developer then sync's  
 with the repository but then fossil update does not show any changes  
 needed.  So he does not see any file changes with command:

   fossil update -n -v | grep -v UNCHANGED

   We have found (at least for now) the easiest approach is to blow  
 away his source files, do fossil open to his (synched) local  
 repository and then he has the updated files.

   I know I am missing something really obvious here as I thought just  
 this situation was what source control systems were for.  I had not  
 noticed this previously since I was the only one using the repository.


This might happen if the you and the other developer are on separate  
branches or forks.  Try running

 fossil update --latest

And/or run fossil ui and look at the graph to see whether or not you  
are on separate forks, and if so, merge them together.

If you just run fossil update it moves you to the latest check-in  
which is a direct descendent of your current check-in.  So if another  
developer has made check-ins that are on a different branch or fork,  
nothing will happen.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] three-way merge

[D. Richard Hipp]

On Apr 12, 2010, at 10:48 AM, Wilson, Ronald wrote:

 Hello,
 is there some way to use vimdiff or a gui tool like meld for merging?
 I always end up with the automerged file after update that I have to
 edit by hand and that easily becomes messy on bigger changes. I am
 used to perforce 3-way merge or the .THIS, .OTHER, .BASE files in
 bazaar. The only way I can think of is making a second checkout and
 then diffing against my repo with changes.
 Am I missing something here?
 Petr

 Rational ClearCase also does 3-way merges on conflict.  I haven't
 figured out how to get fossil to do similar, but I didn't try very  
 hard.

 If anyone is curious, basically the idea is that you have three source
 panes - this or the code you're merging from - other or the code
 you're merging to - and base or the common ancestor of this and  
 other.
 Based on these three windows, you can construct a fourth window that
 contains the desired merged code.

 I use Beyond Compare 3 for 3-way merges and have been very happy.  I
 would love it if fossil could do 3-way merges, but I'm too busy to
 contribute right now.


Fossil uses the same approach (with some nomenclature changes, for  
example pivot instead of base).  What you are asking for, I think,  
is the ability to override Fossil's built-in 3-way merge so that it  
calls some external 3-way merge program instead, passing in three  
input files and receiving a 4th result file as the result.  This could  
be accomplished using  a new setting.  It wouldn't be that hard to do.


 RW

 Ron Wilson, Engineering Project Lead
 (o) 434.455.6453, (m) 434.851.1612, www.harris.com

 HARRIS CORPORATION   |   RF Communications Division
 assuredcommunications(tm)
 ___
 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...@hwaci.com



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

Re: [fossil-users] three-way merge

[D. Richard Hipp]

On Apr 12, 2010, at 12:48 PM, Johan Samyn wrote:

 It would be interesting to have Fossil automatically use any
 configured external 3-way merge tool when it's own 3-way merge ends
 with conflicts, so one can manually and visually solve them, instead
 of having to go to the sourcefiles. And I thought the gdiff-command
 setting was meant for that ? Or is that one just for 2-way (graphical)
 diff viewing ?

setting gdiff is for 2-way graphical diff viewing only.

Your idea of only using the 3-way graphical merger when there are  
conflicts is a good one.  Tnx

Can anyone suggest a good 3-way graphical merger that I can use for  
testing (Mac or Linux).

 Johan
 ___
 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...@hwaci.com



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

Re: [fossil-users] three-way merge

[D. Richard Hipp]

On Apr 12, 2010, at 12:52 PM, D. Richard Hipp wrote:


 On Apr 12, 2010, at 12:48 PM, Johan Samyn wrote:

 It would be interesting to have Fossil automatically use any
 configured external 3-way merge tool when it's own 3-way merge ends
 with conflicts, so one can manually and visually solve them, instead
 of having to go to the sourcefiles. And I thought the gdiff-command
 setting was meant for that ? Or is that one just for 2-way  
 (graphical)
 diff viewing ?

 setting gdiff is for 2-way graphical diff viewing only.

 Your idea of only using the 3-way graphical merger when there are
 conflicts is a good one.  Tnx

Or would it be sufficient for Fossil to merely retain the three input  
files to the merge using some suffix when there is a conflict:

  problem.c~BASE
  problem.c~OTHER
  problem.c~THIS

Fossil would still writes its output (contain the  CONFLICT  
marks that people don't like) but the user would be able to manually  
invoke whatever graphical 3-way merging tool they want.



 Can anyone suggest a good 3-way graphical merger that I can use for
 testing (Mac or Linux).

 Johan
 ___
 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...@hwaci.com



 ___
 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...@hwaci.com



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

Re: [fossil-users] Compiling fossil under windows

[D. Richard Hipp]

On Apr 11, 2010, at 6:46 AM, Rene de Zwart wrote:


 Having had my way with fossil compiling under windows. I was looking  
 for
 new challenges by compiling with other free compilers.
 I tried digital mars c compiler. Which promptly said
  unistd.h is for unix systems (The smart little bugger :-)

 Do I correctly infer from this that native windows compilers are not
 tested/used/supported?


Correct.

I don't own a windows machine. The windows binaries on the website are  
generated by cross-compiling off of Linux.  I do have the capability  
of running windows under VMWare (for testing), but I don't bring  
VMWare up that often and do not have any compilers installed there.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Evaluation Assurance Level (EAL) testing?

[D. Richard Hipp]

On Apr 6, 2010, at 11:58 AM, Stephen De Gabrielle wrote:

 Hi,

 does anyone know if fossil had been put through any EAL testing?

I haven't done any EAL testing on Fossil and if anyone had, it seems  
like it would have probably been me.


 http://en.wikipedia.org/wiki/Evaluation_Assurance_Level

 Cheers,

 Stephen


 --
 Stephen De Gabrielle
 stephen.degabrie...@acm.org
 Telephone +44 (0)20 85670911
 Mobile+44 (0)79 85189045
 http://www.degabrielle.name/stephen
 ___
 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...@hwaci.com



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

Re: [fossil-users] Editing a tag causes confusion on branches?

[D. Richard Hipp]

On Apr 5, 2010, at 12:34 AM, Jeremy Cowgar wrote:

 I created a new branch on as 0.2.0. I then however, realized I  
 goofed. I
 wanted the branch to be 0.2. I would later create a tag for the 0.2.0
 release of the 0.2 branch (expecting 0.2.1, 0.2.3, etc... which would
 all be tags in the 0.2 branch).

 So I edited it via the web UI. This, however, changed the properties  
 but
 did not change the branch display:

 http://fossil.josl.org/brlist

 You can see 0.2.0 listed (which I just closed this evening).

 Now, clicking on it, you do not see any checkins tagged with 0.2.0.

 http://fossil.josl.org/timeline?t=0.2.0  (which you could get to  
 also by
 clicking on the 0.2.0 branch link).

 I assume this is because I change 0.2.0 to be 0.2. So, if you manually
 change the URL to read:

 http://fossil.josl.org/timeline?t=0.2

In the Tags And Properties section of http://fossil.josl.org/info/0bc11bf7ae 
  you will see that you did not change the branch - the branch is  
still 0.2.0.  You just added a new tag named 2.0.   To change the  
branch from 0.2.0 to 0.2, you should go to the first check-in of the  
branch and then edit that check-in and select Make this check-in the  
start of a new branch named: [0.2]  where you fill in the 0.2 part.

The action above will not remove the 0.2.0 branch, but it will make it  
empty.  And it will create a new branch name 0.2 that contains all the  
elements that were formerly in 0.2.0.


 Then you will see 0.2 checkins (well, checkin). Or, you can browse the
 timeline and find the checkin as well:

 http://fossil.josl.org/info/0bc11bf7ae

 I looked in source code and was unable to solve this problem. Any  
 thoughts?

 Jeremy

 ___
 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...@hwaci.com



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

Re: [fossil-users] Fossil GUI for local source tree operations

[D. Richard Hipp]

On Apr 5, 2010, at 4:42 PM, Wilson, Ronald wrote:

 I'm just not sure how that really works out in practice.  If you allow
 remote users to perform checkins, how do you sort it out if someone
 makes a mess?  Maybe I just don't understand tagging.  I would want to
 be able to move untrusted checkins to another branch and keep my main
 line clean.  Does tagging do that?  Is a pgp signature essentially a
 form of tag?  I need to play with it some.  So far my use case for
 fossil is only single-user with a canonical remote repo and only
 accidental forking.  I've had no use for tags yet.


I initially set out to design Fossil so that anonymous users on the  
open internet could commit and the permissions and signing system  
would be sufficient to keep out malicious content.  But I quickly  
found that such a system is difficult to both implement and use.  So I  
backed up to the traditional model of only giving check-in privileges  
to people you trust.

Of course in a DVCS, anybody who can clone can also do local check-ins  
to their private copy of the repository - there is nothing you can do  
to stop them.  But you can stop them from pushing those changes back  
into official servers.  That is what we do at Fossil and SQLite.  Any  
anonymous user can clone the repositories and start checking in  
whatever they want to their local copies.  But they can't push the  
results back to official Fossil or SQLite servers.

Messes are avoided by simply not giving push privileges to anyone who  
is likely to create a mess.  Select your developers carefully, but  
then trust them to do the right thing.  In the (rare) circumstance  
where a developer goes bad on you, there is alway shunning to clean  
up the mess.  Note that each SQLite server tracks the IP address from  
which it received each artifact via push.  This feature is there to  
make it easier to track down and shun all artifacts from a single  
rogue developer.


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Editing a tag causes confusion on branches?

[D. Richard Hipp]

On Apr 5, 2010, at 7:38 PM, Jeremy Cowgar wrote:

 On 4/5/2010 7:12 AM, D. Richard Hipp wrote:
 In the Tags And Properties section of
 http://fossil.josl.org/info/0bc11bf7ae
   you will see that you did not change the branch - the branch is
 still 0.2.0.  You just added a new tag named 2.0.   To change the
 branch from 0.2.0 to 0.2, you should go to the first check-in of the
 branch and then edit that check-in and select Make this check-in the
 start of a new branch named: [0.2]  where you fill in the 0.2 part.

 The action above will not remove the 0.2.0 branch, but it will make  
 it
 empty.  And it will create a new branch name 0.2 that contains all  
 the
 elements that were formerly in 0.2.0.


 I got it all goofed up now.

 http://fossil.josl.org/brlist

 0.2 is showing as an open branch but the only item in it says it's  
 closed.

Send me an admin login and password by private email and I will try to  
untangle it for you.


 Jeremy

 ___
 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...@hwaci.com



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

Re: [fossil-users] be careful what you wish for

[D. Richard Hipp]

On Apr 3, 2010, at 12:27 PM, Joshua Paine wrote:

 * But using the same project code on all passwords means that it's
 easier to build a custom rainbox table to attack at once all passwords
 stored in a given repo.

Not so in this case.  The stored has is computed as follows:

 SHA1( project-code + / + login + / + password )

This means that the password hash will always be unique (to an  
exceedingly high probability) even if the same password is used by two  
or more users on the same project, or by the same user on different  
projects.


 * The only plausible benefit of using the project code instead of a
 random salt that I can think of is to make stored passwords non- 
 portable
 across repos. (With salt and hash stored together, the lot could be
 copied to a user in another repo with the same name and used.) But for
 my use case this is a hinderance, not a benefit, and I can't think of
 any situation in which it would actually help.

Another (important) benefit of using the project code instead of  
random salt is that the client already knows the project code, and  
hence it does not need to do a preliminary round-trip to the server  
just to get the salt prior to encoding the users password whenever it  
does a push or pull.

You cannot copy the hashed password between repositories.  But Fossil  
still accepts unhashed passwords in the USER table.  If the USER.PW  
field contains text that is not 40 characters in length, then that  
text is interpreted as an unhashed password and is hashed at run-time.

So if you want to add a user to multiple repositories, you can simply  
write a script that inserts entries into the USER table of the various  
repositories with a cleartext password.

Or, if you are writing scripts, your script can invoke fossil user  
password LOGIN PASSWORD --repository REPOSITORY-FILENAME which will  
cause the password to be inserted hashed instead of cleartext.


 So for improved utility (for certain uses, anyway) and slightly  
 improved
 security, the project code in the hash should be replaced with a per- 
 row
 random salt.

 -- 
 Joshua Paine
 LetterBlock LLC
 http://letterblock.com/
 Web applications built with joy.
 ___
 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...@hwaci.com



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

Re: [fossil-users] Regression Testing

[D. Richard Hipp]

On Apr 2, 2010, at 2:50 AM, Rob Powell wrote:

 Hey folks;

 What are some thoughts on creating a Regression Test Suite for fossil?

I would love to have regression tests for Fossil.  Are you  
volunteering to write them?  :-)

I'm not so worried about bugs that might corrupt a repository (see 
http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki 
  for an explanation of why not) but it would be great to be able to  
automatically detect other problems that I accidently introduce while  
making changes.

Some kind of automated or semi-automated security audit would be nice  
to have too, though I'm not sure how to go about building such a thing.


 Would it make sense to have some code package that would be run  
 against a built fossil to verify functions?

 Thoughts/suggestions on language/framework?

 (The situation being testing the SSL build that I have previously  
 posted, how could I verify its functions, etc.)

 -rppowell

 Hotmail is redefining busy with tools for the New Busy. Get more  
 from your inbox. See  
 how.___
 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...@hwaci.com



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

Re: [fossil-users] TONS of errors after upgrade, rebuild does not help

[D. Richard Hipp]

On Mar 31, 2010, at 10:25 AM, Zed A. Shaw wrote:

 Hey,

 I upgraded to the latest fossil, with mine not being that old at all
 (only a few months), and even after several rebuilds I get a ton of
 bizarre errors:

 -- logging into the server
 unable to open database file
 UPDATE user SET
 cookie='1/02AAB0D7FFB698CD97B848BEC1159977A498AA58CDD03213E9',
 ipaddr='127.0.0.1',   cexpire=julianday('now')+31557600/86400.0 WHERE
 uid=1

 -- fossil up
 Error: Database error: unable to open database file
 DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)

 -- fossil clone
 Error: Database error: unable to open database file
 DELETE FROM unclustered WHERE rid IN (SELECT rid FROM private)


 So what's going on?  Is it some kind of permissions problem?  The  
 files
 are owned by the user, and the web interface works right until it  
 tries
 to write like the above UPDATE and DELETE commands.  They're being run
 out of inetd with:

 4545 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http
 /home/USER/fossils/source.fossil

 Did fossil change this or something?

Nothing has changed in Fossil, that I know of, that would cause this.

Are you sure your permissions are right?  Do you have write permission  
on the directory that contains the source.fossil file?



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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] TONS of errors after upgrade, rebuild does not help

[D. Richard Hipp]

On Mar 31, 2010, at 10:33 AM, Zed A. Shaw wrote:

 On Wed, Mar 31, 2010 at 07:25:47AM -0700, Zed A. Shaw wrote:
 Hey,

 I upgraded to the latest fossil, with mine not being that old at all
 (only a few months), and even after several rebuilds I get a ton of
 bizarre errors:
 ...
 4545 stream tcp nowait.1000 root /usr/bin/fossil /usr/bin/fossil http
 /home/USER/fossils/source.fossil

 Did fossil change this or something?

 Yep, looks like running out of inetd is now read only.  If I run it  
 with
 fossil serve it's just fine.

 Is there a reason this changed?  What was the change for?

Perhaps this:  http://www.fossil-scm.org/fossil/info/7ba10f1a6a

But that change (really a bug fix) was in August 2009.  How old was  
your prior version of Fossil, did you say?



 Sending out a changelog to the mailing list when there's a new drop,  
 and
 using version numbers that aren't giant hashes with a date in them  
 would
 *really* help people keep up.

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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] TONS of errors after upgrade, rebuild does not help

[D. Richard Hipp]

On Mar 31, 2010, at 10:45 AM, Zed A. Shaw wrote:

 All signs point to some recent change in the way inetd operation works
 that would cause this to happen now.


I don't recall changing anything associated with the inetd logic.  Of  
course, that might just mean that I forgot...

What does the /test_env URL to your inetd server tell you?  (example: 
http://www.fossil-scm.org/fossil/test_env) 
   Any clues there?

I just checked in a change - http://www.fossil-scm.org/fossil/ci/99fea6cde4 
  - that logs all SQLite errors to the reply HTML.  If you can  
recompile to the latest, it might give us better clues about what is  
going wrong.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] TONS of errors after upgrade, rebuild does not help

[D. Richard Hipp]

On Mar 31, 2010, at 1:04 PM, Heinrich Huss wrote:

 It seems I'm running in the same problem. After recompile I'm not  
 able to login.

 It looks like the sqite cannot open the database with write access.  
 Filepermissions are ok and I did a rebuild.

 -rwxrw-rw-1 adminadminist 10977280 Mar 31 18:47 fossil.fossil*


 I've got the following error message:
 SQLITE_CANTOPEN: cannot open file at source line 26160

Please recompile with http://www.fossil-scm.org/fossil/ci/a158c4e75d  
and let me know what error message you get then.



 SQLITE_CANTOPEN: statement aborts at 31: [UPDATE user SET  
 cookie='1/669CBDB7E9AB8F1565A3C3F19FB96E3900C5C9B8F18BE6031C',  
 ipaddr='10.0.0.10', cexpire=julianday('now')+31557600/86400.0 WHERE  
 uid=1] unable to open database file

 Database Error
 unable to open database file
 UPDATE user SET  
 cookie='1/669CBDB7E9AB8F1565A3C3F19FB96E3900C5C9B8F18BE6031C',  
 ipaddr='10.0.0.10',   cexpire=julianday('now')+31557600/86400.0  
 WHERE uid=1
 If you have recently updated your fossil executable, you might need  
 to run fossil all rebuild to bring the repository schemas up to  
 date.



 Any ideas?



 Thanks

 Hein



 Am 31.03.2010 um 16:56 schrieb D. Richard Hipp:


 On Mar 31, 2010, at 10:45 AM, Zed A. Shaw wrote:

 All signs point to some recent change in the way inetd operation  
 works
 that would cause this to happen now.


 I don't recall changing anything associated with the inetd logic.  Of
 course, that might just mean that I forgot...

 What does the /test_env URL to your inetd server tell you?   
 (example: http://www.fossil-scm.org/fossil/test_env)
   Any clues there?

 I just checked in a change - http://www.fossil-scm.org/fossil/ci/99fea6cde4
  - that logs all SQLite errors to the reply HTML.  If you can
 recompile to the latest, it might give us better clues about what is
 going wrong.

 D. Richard Hipp
 d...@hwaci.com



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

 ___
 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...@hwaci.com



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

Re: [fossil-users] TONS of errors after upgrade, rebuild does not help

[D. Richard Hipp]

On Mar 31, 2010, at 1:42 PM, Heinrich Huss wrote:

 I have recompiled. Now I do have the following fossil version:

 Fossil version [a158c4e75d] 2010-03-31 17:14:18

 This is the error message I got:

 SQLITE_CANTOPEN: cannot open file [/share/HDA_DATA/Public/Hein/ 
 fossil.fossil-journal]: No such file or directory

SQLite is unable to create and open a new rollback journal.  Does your  
process have write permission on the directory?



 SQLITE_CANTOPEN: statement aborts at 31: [UPDATE user SET  
 cookie='1/0F420A8378AC596FC324F1ED6E647662CF99B3BE8144E2DA70',  
 ipaddr='10.0.0.10', cexpire=julianday('now')+31557600/86400.0 WHERE  
 uid=1] unable to open database file

 Database Error
 unable to open database file
 UPDATE user SET  
 cookie='1/0F420A8378AC596FC324F1ED6E647662CF99B3BE8144E2DA70',  
 ipaddr='10.0.0.10',   cexpire=julianday('now')+31557600/86400.0  
 WHERE uid=1
 If you have recently updated your fossil executable, you might need  
 to run fossil all rebuild to bring the repository schemas up to  
 date.



 Thanks for your help.

 Hein





 Am 31.03.2010 um 19:15 schrieb D. Richard Hipp:


 On Mar 31, 2010, at 1:04 PM, Heinrich Huss wrote:

 It seems I'm running in the same problem. After recompile I'm not
 able to login.

 It looks like the sqite cannot open the database with write access.
 Filepermissions are ok and I did a rebuild.

 -rwxrw-rw-1 adminadminist 10977280 Mar 31 18:47  
 fossil.fossil*


 I've got the following error message:
 SQLITE_CANTOPEN: cannot open file at source line 26160

 Please recompile with http://www.fossil-scm.org/fossil/ci/a158c4e75d
 and let me know what error message you get then.



 SQLITE_CANTOPEN: statement aborts at 31: [UPDATE user SET
 cookie='1/669CBDB7E9AB8F1565A3C3F19FB96E3900C5C9B8F18BE6031C',
 ipaddr='10.0.0.10', cexpire=julianday('now')+31557600/86400.0 WHERE
 uid=1] unable to open database file

 Database Error
 unable to open database file
 UPDATE user SET
 cookie='1/669CBDB7E9AB8F1565A3C3F19FB96E3900C5C9B8F18BE6031C',
 ipaddr='10.0.0.10',   cexpire=julianday('now')+31557600/86400.0
 WHERE uid=1
 If you have recently updated your fossil executable, you might need
 to run fossil all rebuild to bring the repository schemas up to
 date.



 Any ideas?



 Thanks

 Hein



 Am 31.03.2010 um 16:56 schrieb D. Richard Hipp:


 On Mar 31, 2010, at 10:45 AM, Zed A. Shaw wrote:

 All signs point to some recent change in the way inetd operation
 works
 that would cause this to happen now.


 I don't recall changing anything associated with the inetd  
 logic.  Of
 course, that might just mean that I forgot...

 What does the /test_env URL to your inetd server tell you?
 (example: http://www.fossil-scm.org/fossil/test_env)
  Any clues there?

 I just checked in a change - http://www.fossil-scm.org/fossil/ci/99fea6cde4
 - that logs all SQLite errors to the reply HTML.  If you can
 recompile to the latest, it might give us better clues about what  
 is
 going wrong.

 D. Richard Hipp
 d...@hwaci.com



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

 ___
 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...@hwaci.com



 ___
 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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] TONS of errors after upgrade, rebuild does not help

[D. Richard Hipp]

On Mar 31, 2010, at 1:56 PM, D. Richard Hipp wrote:


 On Mar 31, 2010, at 1:42 PM, Heinrich Huss wrote:

 I have recompiled. Now I do have the following fossil version:

 Fossil version [a158c4e75d] 2010-03-31 17:14:18

 This is the error message I got:

 SQLITE_CANTOPEN: cannot open file [/share/HDA_DATA/Public/Hein/
 fossil.fossil-journal]: No such file or directory

 I think I know the problem.  Fossil now opens the database file
 *before* it enters the chroot jail.  But SQLite remembers the original
 path to the database, not the chroot-ed path.

 I guess what I need to do is close the database before entering the
 chroot jail then reopen the database under the new name

OK.  This problem should be fixed now (as of 
http://www.fossil-scm.org/fossil/info/42ba7b97aa) 
.  Please let me know if you have any other problems.



 SQLITE_CANTOPEN: statement aborts at 31: [UPDATE user SET
 cookie='1/0F420A8378AC596FC324F1ED6E647662CF99B3BE8144E2DA70',
 ipaddr='10.0.0.10', cexpire=julianday('now')+31557600/86400.0 WHERE
 uid=1] unable to open database file

 Database Error
 unable to open database file
 UPDATE user SET
 cookie='1/0F420A8378AC596FC324F1ED6E647662CF99B3BE8144E2DA70',
 ipaddr='10.0.0.10',   cexpire=julianday('now')+31557600/86400.0
 WHERE uid=1
 If you have recently updated your fossil executable, you might need
 to run fossil all rebuild to bring the repository schemas up to
 date.



 Thanks for your help.

 Hein





 Am 31.03.2010 um 19:15 schrieb D. Richard Hipp:


 On Mar 31, 2010, at 1:04 PM, Heinrich Huss wrote:

 It seems I'm running in the same problem. After recompile I'm not
 able to login.

 It looks like the sqite cannot open the database with write access.
 Filepermissions are ok and I did a rebuild.

 -rwxrw-rw-1 adminadminist 10977280 Mar 31 18:47
 fossil.fossil*


 I've got the following error message:
 SQLITE_CANTOPEN: cannot open file at source line 26160

 Please recompile with http://www.fossil-scm.org/fossil/ci/a158c4e75d
 and let me know what error message you get then.



 SQLITE_CANTOPEN: statement aborts at 31: [UPDATE user SET
 cookie='1/669CBDB7E9AB8F1565A3C3F19FB96E3900C5C9B8F18BE6031C',
 ipaddr='10.0.0.10', cexpire=julianday('now')+31557600/86400.0 WHERE
 uid=1] unable to open database file

 Database Error
 unable to open database file
 UPDATE user SET
 cookie='1/669CBDB7E9AB8F1565A3C3F19FB96E3900C5C9B8F18BE6031C',
 ipaddr='10.0.0.10',   cexpire=julianday('now')+31557600/86400.0
 WHERE uid=1
 If you have recently updated your fossil executable, you might need
 to run fossil all rebuild to bring the repository schemas up to
 date.



 Any ideas?



 Thanks

 Hein



 Am 31.03.2010 um 16:56 schrieb D. Richard Hipp:


 On Mar 31, 2010, at 10:45 AM, Zed A. Shaw wrote:

 All signs point to some recent change in the way inetd operation
 works
 that would cause this to happen now.


 I don't recall changing anything associated with the inetd
 logic.  Of
 course, that might just mean that I forgot...

 What does the /test_env URL to your inetd server tell you?
 (example: http://www.fossil-scm.org/fossil/test_env)
 Any clues there?

 I just checked in a change - 
 http://www.fossil-scm.org/fossil/ci/99fea6cde4
 - that logs all SQLite errors to the reply HTML.  If you can
 recompile to the latest, it might give us better clues about what
 is
 going wrong.

 D. Richard Hipp
 d...@hwaci.com



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

 ___
 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...@hwaci.com



 ___
 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

 D. Richard Hipp
 d...@hwaci.com



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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Hyperlinks Disabled

[D. Richard Hipp]

On Mar 29, 2010, at 8:18 AM, Jeremy Cowgar wrote:

 When you are not logged in to Fossil, you get the message in many  
 areas:

 Many hyperlinks are disabled.
 Use anonymous login to enable hyperlinks.

 Is it really a problem? I just have assumed so since the message was  
 there, but it's a bit of a roadblock for new users to fossil when  
 they see this message and try to navigate around.

 I understand the intent is to cause bots not to index your repo, but  
 is that a problem? Can a robots.txt not just be used instead of  
 disabling hyperlinks?

The problem robots all ignore robots.txt.  For example, some users  
think it is a good idea to run wget -r on http://www.sqlite.org/ in  
order to download the entire site, and were it not for the disabled  
hyperlinks in Fossil, that would result in pulling down a ZIP archive  
for all 7424 historical check-ins of SQLite as well has every  
historical version of every file in the source tree, in both binary  
and hex, with its diff, and its annotation.

If you want to enable hyperlinks for everyone, give the history  
privilege to user nobody.



 Jeremy

 ___
 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...@hwaci.com



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

Re: [fossil-users] [PATCH!] SSL verify fails on centos when there's an intermediate certificate involved

[D. Richard Hipp]

On Mar 23, 2010, at 1:59 PM, Brian Smith wrote:

 Not to be impatient, just wanted to clarify that there is a patch to
 fix the issue described here.


I don't really have a way of testing it.  I set out trying to make  
arrangements to test it over the weekend, but I ran out of time.  I'm  
currently engaged by more pressing matters.

The patch is also incomplete - it only works for Debian and CentOS.   
My SuSE system, for example, does not have a single certificate file  
to hand over to SSL_CTX_load_verify_locations() interface.  Instead,  
you have to pass in a directory as the third argument.   And the patch  
has no provision for win32.  How many other variations might be  
lurking out there?

I also prefer an approach where there is a list of candidate  
certificate files and/or directories which we loop through until an  
appropriate certificate file/directory is located.  That would make it  
much easier to add variations for new and different installations.  I  
might have entered such a change over the weekend, but I have no way  
of testing it

If you have to have a patched Fossil right away, clone the Fossil  
repository and patch it yourself in your clone.  I intend to  
understand the problem better and work out a means of testing the  
solution before I put it in the official tree.

 -B

 On Sun, Mar 21, 2010 at 4:57 PM, Brian Smith br...@linuxfood.net  
 wrote:
 Hi All,

 With the patch from ticket
 http://www.fossil-scm.org/index.html/info/45f89e504b, bare SSL
 syncing now works properly with self-signed certificates. However,
 Fossil doesn't load the system certificate store on Centos/linux (and
 probably other *nix type platforms as well). Which means that if you
 present a certificate signed by an external party (CAcert or  
 Verisign,
 for example), fossil will fail the verification with
 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY which normally means  
 that
 the list of trusted certificates is not complete [1].

 There are few solutions to this problem. First, we could load the
 system certificate store.
 Though, that's not as simple as it sounds, since, there is no
 standardized location across *nix distributions for the system store.
 After just a quick survey, Centos stores them at
 /etc/pki/tls/cert.pem, Debian stores them as a bundle in
 /etc/ssl/certs/ca-certificates.crt (and that's generated from single
 files under /usr/share/ca-certificates), FreeBSD stores them at
 /usr/local/share/certs/ca-root-nss.crt, Arch appears to store them in
 the same way as Debian, OpenSolaris doesn't even include any by
 default. You get the idea.
 The second solution is to prompt, or otherwise encourage the user to
 manually specify the path to the certificate chain. This has the
 advantage of maximum control, but may be a little frightening to
 new/less savvy users.

 Probably the best solution is do some runtime detection and allow the
 user to override if the auto detection doesn't work quite right. It's
 probably even worthwhile to allow the user to manually load (via a  
 new
 command? web ui?) certificates into the global fossil configuration
 for those situations where they don't have the ability to modify the
 system certificate store and/or don't want maintain their own
 certificate bundle.

 I've attached a patch which does some simple detection of system
 certificate stores. I've tested it  on OS X (10.6), Centos 5.3,  
 Debian
 5.0, and FreeBSD 7.2. I need someone to test on Windows since my
 Windows VM is broken at the moment. On OS X, we don't actually need  
 to
 load the system or login stores since they appear to have patched
 openssl to do that for us.

 [1] See manpage verify(1) from the openssl distribution.

 detect-platform- 
 certs.patch___
 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...@hwaci.com



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

Re: [fossil-users] Deleting a wiki page?

[D. Richard Hipp]

On Mar 18, 2010, at 4:37 AM, Krum Pet wrote:

 Is there a way to delete a wiki page? Maybe by issuing SQL?

 If you simply want to hide the page so it is not listed using
 /wcontent then perhaps you could edit the 'tag' table and change the
 wiki-PageName tag to xwiki-PageName.

 I don't know what other side effects this may have so check thoroughly
 before using ;)

That will prevent the wiki page from appearing - until you run  
rebuild.  I'm thinking Jeremy is looking for a more permanent  
solution.


 I have found the Firefox sqlite extension an excellent tool for
 screwing up sqlite databases.

 On 18/03/2010, D. Richard Hipp d...@hwaci.com wrote:


 I agree with Jeremy that shunning is a pretty awkward way to clean  
 up
 the 'desktop', but if that is the only way . . .


 I'm working on providing attachments right this moment.  I have your
 request, though.  I'll see what I can do

 D. Richard Hipp
 d...@hwaci.com



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



 -- 
 --
 krumpet http://kp.hcoop.net
 ___
 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...@hwaci.com



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

Re: [fossil-users] Attaching artifacts to a ticket?

[D. Richard Hipp]

On Mar 18, 2010, at 11:11 AM, Chris wrote:

 I hope you will forgive my ignorance or blindness but
 I don't know how make use of this feature.

 As a Setup/Admin privileged user I should have all
 privileges without further qualification but:

 1. There is no extra entry field for attachments in the
 'new ticket' or 'edit ticket' forms.

There is an Attach link in the submenu on the tktview page.


 2. If an attachment should be identified in the body of
 the comment/remark field, what syntax should be used?

You want a hyperlink to the attachment?

a href=attachview?tkt=TICKETIDfile=FILENAME.../a

or

img src=attachimage?tkt=TICKETIDfile=FILENAME

The above is for a ticket. For a wiki page, use page=PAGENAME  
instead of tkt=TICKETID.  The full 40-character ticket ID must be  
used.

Or, you could just say See the NAME attachment below because all of  
the attachments are listed at the bottom of the page, together with  
links for viewing and downloading them.



 Chris Peachment

 On Thu, 2010-03-18 at 10:36 -0400, D. Richard Hipp wrote:
 On Mar 15, 2010, at 9:16 PM, Kevin Kenny wrote:

 I find that my users frequently want to attach one or more artifacts
 to a ticket.

 The latest version of Fossil supports adding attachments to wiki  
 pages
 and tickets.  You have to turn on Attachment permission for users  
 to
 be able to do this.  Users will also need Append-Ticket and Append-
 Wiki permission in order to add attachments to tickets and wiki,
 respectively.

 Please let me know if you find any problems with this new capability.


 D. Richard Hipp
 d...@hwaci.com



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


 ___
 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...@hwaci.com



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

Re: [fossil-users] Direct URL for downloading a file from the repository via CGI interface

[D. Richard Hipp]

On Mar 18, 2010, at 3:15 PM, Michael Barrow wrote:

 I'm trying to make a URL with a link to directly download something  
 from the repository. By navigating through the Files interface, I  
 eventually see the Download link and could definitely use this.  
 However, I have a question: what's the purpose of the name=XX at  
 the end of the URL. For example,
 http://server/repo/raw/path1/path2/file.c?name=22


The 22 is a semi-transient rowid on an internal table (semi- 
transient in the sense that it is different on each repository and  
probably changes when you rebuild).  Allowing rowids in this context  
is bad design, it seems to me.  This is something I am working to fix.

You can substitute the 40-character hex artifact ID for the 22  
here - or any unique prefix of the artifact ID.  For example:

 http://server/repo/raw/path1/path2/file.c?name=cfa2bf991fb8

Note that the /path1/path2/file.c part of the URL is currently only  
used to determine the mimetype and suggested filename for the  
download.  That too might change in the future so that the /path1/ 
path2/file.c carries more meaning and plays a bigger role in  
selecting the object to be downloaded.  For example, it should  
probably allow:

 http://server/repo/raw/path1/path2/file.c?name=release

... in order to download the latest version of path1/path2/file.c that  
appears in a check-in tagged with release.  It should, but it  
doesn't.  At least not yet...

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Deleting a wiki page?

[D. Richard Hipp]

On Mar 17, 2010, at 5:02 PM, Jeremy Cowgar wrote:

 Is there a way to delete a wiki page? Maybe by issuing SQL?

You could shun all the wiki artifacts associated with that page.   
There is no other way at present.  Because the design of Fossil is to  
save everything forever, it is not clear would could be down to  
delete a wiki page.




 Jeremy

 ___
 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...@hwaci.com



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

Re: [fossil-users] Deleting a wiki page?

[D. Richard Hipp]

 I agree with Jeremy that shunning is a pretty awkward way to clean up
 the 'desktop', but if that is the only way . . .


I'm working on providing attachments right this moment.  I have your  
request, though.  I'll see what I can do

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] New --ignore option

[D. Richard Hipp]

On Mar 16, 2010, at 8:22 AM, Jeremy Cowgar wrote:

 For my fossil checkout, I do: mkdir build  cd build  make -f ../ 
 Makefile

 So, from my root fossil directory, I do fossil extras --ignore build  
 but
 still wind up with everything under the build directory.


 fossil extra --ignore 'build/*'

 I can do
 --ignore *.o and get rid of the .o files in the build directory but it
 still shows up with all the .c and .h files, which of course I cannot
 ignore.

 Also, once this problem is fixed, does it make sense to store this
 option in the database? Maybe in the Behavior section of the setup  
 web page?

 Jeremy

 ___
 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...@hwaci.com



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

Re: [fossil-users] New --ignore option

[D. Richard Hipp]

On Mar 16, 2010, at 8:22 AM, Jeremy Cowgar wrote:

 Also, once this problem is fixed, does it make sense to store this
 option in the database? Maybe in the Behavior section of the setup  
 web page?


 fossil setting ignore-glob


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] fossil operations deadly slow

[D. Richard Hipp]

On Mar 16, 2010, at 5:24 PM, Joshua Paine wrote:

 So, I had a fossil repo for a web app that has a lot of hands in it.  
 I'm
 the only code developer (though not the first by many years--repo
 converted from CVS), but the application serves hundreds of clients,  
 and
 images and other such customizations for each client are done by  
 others.

 The directory with these custom images etc. is large, so I left it out
 of the repo initially. But now those others need to do a lot of work
 replacing old graphics, so I added the images dir and subdirs so  
 there'd
 be a safe place for them to get their old versions back and we  
 wouldn't
 end up with dozens of files renamed to OLDfoo.bar.

 Now that I've added these image dirs, fossil is inconceivably slow.
 `fossil status` takes 45 sec on my dev machine, 4.5 minutes on the
 server. Trivial commits take minutes.

 The fossil repo is about 1GB.

 Is this expected-ish behavior for a repo with many files at 1GB?

 If I delete all these images from any branch I work with, will it get
 fast again?

The problem is probably that Fossil is computing SHA1 checksums on all  
the files in the check-out to see if they have changed.  You can get  
Fossil to use mtimes instead by doing:

  fossil setting mtime-changes on

Mtime-changes is now the default, but I'm guessing you are using an  
older version of Fossil.  After you turn mtime-changes on, you have to  
do a check-out before it takes full effect, I think, but after that  
things should go faster.

Check-ins and check-outs will still be kind of slow in as much as  
Fossil still computes MD5 checksums over everything in those cases.   
See http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki for an  
explanation of why we do this expensive computation.  If you find  
things are still too slow, let me know.  We can work together to  
profile your runs and try to figure out what the inefficiency is and  
fix it.


 -- 
 Joshua Paine
 LetterBlock: Web applications built with joy
 http://letterblock.com/
 301-576-1920

 ___
 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...@hwaci.com



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

Re: [fossil-users] workflow glitch

[D. Richard Hipp]

On Mar 16, 2010, at 5:35 PM, Joshua Paine wrote:

 It seems like adding the images directories as I described in my last
 was a bad idea. Besides the unbearable slowness, it doesn't seem to  
 be a
 prudent model if the 'others' aren't going to keep fossil up to date  
 on
 the image changes. (They aren't. And with commits taking minutes, I
 couldn't possibly convince them.)

 But still I ran into behavior that seems a glitch:

 'other' deletes /path/images/CLIENTID/foo.jpg

 Me: Just fixed a bug on my dev machine and checked it in. Time to
 'deploy' on the server.

 $ cd /path/
 $ fossil update
 fossil: not an ordinary file: /path/images/CLIENTID/foo.jpg
 fossil: abort due to prior errors

 Me: Well, it could get annoying cleaning up after the 'others' all  
 the
 time, but ok...

 $ fossil rm images/CLIENTID/foo.jpg
 DELETED  images/CLIENTID/foo.jpg

 $ fossil commit -m keeping up with image changes
 fossil: would fork.  update first or use -f or --force.
 $ fossil update
 UPDATE app/file_with_bug_fix.php
 UPDATE images/CLIENTID/foo.jpg

 Me: fossil update brought back the files I just deleted, which delete
 it told me not to check-in? (This was more annoying in real life b/ 
 c it
 was actually several files, and the site was in an incorrect state  
 for 5
 minutes while I ran fossil status and tried to figure what had
 happened.)

Seems like I fixed this bug a few weeks ago.  What version of Fossil  
are you using?


 -- 
 Joshua Paine
 LetterBlock: Web applications built with joy
 http://letterblock.com/
 301-576-1920

 ___
 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...@hwaci.com



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

Re: [fossil-users] workflow glitch

[D. Richard Hipp]

On Mar 16, 2010, at 6:03 PM, Joshua Paine wrote:

 On Tue, 2010-03-16 at 17:53 -0400, D. Richard Hipp wrote:
 Seems like I fixed this bug a few weeks ago.  What version of Fossil
 are you using?

 [02f638a16f] 2010-02-13 12:30:48 UTC

 Should I be good with the 3/8 snapshot on fossil-scm.org?


I think so.  Please try it and let me know whether or not it clears  
your problem.

 -- 
 Joshua Paine
 LetterBlock: Web applications built with joy
 http://letterblock.com/
 301-576-1920

 ___
 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...@hwaci.com



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

Re: [fossil-users] Attaching artifacts to a ticket?

[D. Richard Hipp]

On Mar 15, 2010, at 9:16 PM, Kevin Kenny wrote:

 Sorry if this is a repost, but I don't think the original made
 it to the list:

 I'm sure this *must* be an FAQ, but I'm not seeing anything obvious
 on fossil-scm.org, and my Google-fu is failing me. So please be  
 patient!

 I find that my users frequently want to attach one or more artifacts
 to a ticket. These artifacts may be test cases, supporting
 documentation, snippets of program output, whatever. (Sometimes they
 are text files that must be preserved verbatim; sometimes they are
 binary files.)

 A few sophisticated ones have got the idea that text files, at least,
 can be attached by enclosing them in the ticket description and
 bracketing them with verbatim/verbatim. And a few others have
 simply put copypasta into the descriptions (and I've been able to
 retrieve the stuff from the database, even though it gets misformatted
 in the UI, by reaching behind fossil's back with sqlite3).

 But there must be an easier way; attaching artifacts to a ticket
 seems to be a capability of most bug trackers, and I can't imagine
 that I'm the first to ask for it.  What am I missing?

Easier ways are planned.  There are provisions for such in the file  
format.  But I've never gotten around to implementing them :-)



 ___
 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...@hwaci.com



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

Re: [fossil-users] Slightly broken repository

[D. Richard Hipp]

On Mar 10, 2010, at 9:13 AM, verizon wrote:

 Yes with this version:

 This is fossil version [599e6abfb1] 2010-03-08 14:18:44 UTC

Please email me (d...@hwaci.com) your FiringBox.fossil and _FOSSIL_  
files and I'll have a look.


 I get the same thing:

 project-name: Firing Box
 repository:   /Users/jschimpf/Public/FOSSIL/FiringBox.fossil
 local-root:   /Users/jschimpf/Public/FiringBox/
 project-code: f6963c318732b1af73668b2576c84082c237df1c
 server-code:  d8e74be5e75a2b09a78925c0d00a2fd502807b4c
 checkout: f5d728ccd1e177f42176b0368b8b66f234335fc4 2009-02-03  
 15:57:15 UTC
 parent:   5a7c975bbb245e92455de113f53824a5e59931d2
 new_fossil(34856) malloc: *** error for object 0x100096658: pointer  
 being freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap

   --jim schimpf

 On 10 Mar, 2010, at 8:50, D. Richard Hipp wrote:


 On Mar 10, 2010, at 8:42 AM, verizon wrote:

 Hi,

 I have a repository that does this:

 project-name: Firing Box
 repository:   /Users/jschimpf/Public/FOSSIL/FiringBox.fossil
 local-root:   /Users/jschimpf/Public/Firingbox/
 project-code: f6963c318732b1af73668b2576c84082c237df1c
 server-code:  d8e74be5e75a2b09a78925c0d00a2fd502807b4c
 checkout: f5d728ccd1e177f42176b0368b8b66f234335fc4 2009-02-03
 15:57:15 UTC
 parent:   5a7c975bbb245e92455de113f53824a5e59931d2
 fossil(33920) malloc: *** error for object 0x100093a48: pointer
 being freed was not allocated
 *** set a breakpoint in malloc_error_break to debug
 Abort trap
 530 Firingbox

 When I run fossil open or status on it.  I have done a rebuild and
 reconstruct on the repository.  I am running:

 This is fossil version [2255e4e3ba] 2009-12-20 02:58:18 UTC

 Have you tried this with the latest version of Fossil?


 Any suggestions ?  I think it has brought all files back and I could
 just delete _FOSSIL_ and generate a new repository but I want to see
 if you could suggest a fix first.

 Oh yes, I don't have anything important in here so you can have the
 repository if you want.

 --jim schimpf


 ___
 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...@hwaci.com



 ___
 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

D. Richard Hipp
d...@hwaci.com



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

[fossil-users] Done a helpful hint. Was: Export repo

[D. Richard Hipp]

See http://www.fossil-scm.org/fossil/ci/2582ecf2ed

A helpful hint (which applies to more than just the zip command):

In most places where a version or check-in name is request, you  
can substitute a branch name or a tag and it will use the most recent  
check-in on that branch or the most recent check-in with the given  
tag.  So for example, we tag certain check-ins in Fossil with  
release to indicate that they are check-ins that are officially  
released.  To generate a ZIP archive of the most recent release:

  fossil zip release output.zip

If you have a separate branch named experimental, you can get the  
most recent check-in of that branch using:

 fossil zip experimental output.zip

You can also substitute an ISO8601 date and time to get the most  
recent check-in prior to the specified date:

 fossil zip 2009-11-05 18:00:00 output.zip

If you want the most recent version of a branch prior to a date, put  
the branch name first followed by the date, and separated by a colon:

 fossil zip experimental:2009-11-05 18:00:00 output.zip

All of these forms apply to most commands.  For example:

 fossil update experimental:2009-11-05 18:00:00
 fossil merge trunk
 fossil open repo.fossil in-test

All of the above forms also apply to URLs.  So, for example, to see  
what the Fossil website looked like on trunk branch on July 4, 2009:

 http://www.fossil-scm.org/fossil/doc/trunk:2009-07-04/www/ 
index.wiki

Or to get the details of the check-in that is the latest release:

 http://www.fossil-scm.org/fossil/info/release

And so forth   Yes, you're right:  I need to document this  
someplace

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] skins selection mis-behaving

[D. Richard Hipp]

On Mar 7, 2010, at 11:42 PM, Rodney Malone wrote:

 I was just trying out the latest snapshot of Fossil and ran into a
 small quirk that might cause a headache for someone.

Thanks for pointing this out.  The problem is now fixed.  The previous  
release cancelled and a new release is now available on the website.

The new release also includes changes that makes the File menu show  
only files in the latest check-in.


 Fossil Version: [10989b5c42] 2010-03-06 19:21:10 UTC
 Platform: XP Home SP3
 Browser: Firefox/3.6

 When selecting a new skin, the page format becomes garbled, in some
 cases an error string appears in a heading saying:
  ERROR: wrong # args: should be puts STRING

 To reproduce this bad behavior: (very repeatable)

 *** Create a new repository -
 fossil new test.fossil

 *** Start ui/server -
 fossil ui test.fossil


 *** Browse to -
 http://127.0.0.1:8080/setup_skin

 *** Select -
 Plain Gray, No Logo.   [Use This Skin]

 At this point the page is garbled.  Presumably either the CSS or the
 header is overwritten incorrectly.  The default skin can be
 re-selected and the screen refreshed and the proper formatted page
 will re-appear.

 Version [4f24addea9] 2009-12-20 21:34:51 UTC does NOT display this  
 behavior.

 Just thought you should know.

 Thanks for an awesome program.

 RM



 ___
 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...@hwaci.com



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

Re: [fossil-users] Merge two repositories

[D. Richard Hipp]

On Mar 6, 2010, at 6:29 AM, Twylite wrote:

 Hi,

 Is it possible to merge two repositories, or to import one repository
 into another?

Suppose your two projects are A and B.  You want to import B into A.

First find the project-code for A using the fossil info command.   
Then change the project code of B to match the project code of A using  
the sqlite3 command-line client:

 sqlite3 B.fossil UPDATE config SET value='project-code-for-A'  
WHERE name='project-code';

Then you will be able to push all the content of B into A.


 I would like to retain the identity of one repository (and if possible
 its artifact IDs), but I don't really care about the artifact IDs of  
 the
 repository being imported -- mainly I want to bring all history of two
 different projects into one repository.

 I seem to have managed something along these lines by deconstructing
 multiple repos into one folder, and then reconstructing a new  
 repository
 from that folder.

 One problem I have encountered is that the new repository is just  
 that:
 new.  It has a different project-id and server-id.  This seems to be a
 feature of reconstruct even when a single repo is involved.  The  
 effect
 is that I get C = A + B, rather than A += B, which means that existing
 clients of my large repository A will need to clone a new repository  
 (in
 this case C) if  when I do such merges, rather than just pulling down
 updates.

 Any suggestions?

 Regards,
 Twylite

 ___
 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...@hwaci.com



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

Re: [fossil-users] getting fossil working

[D. Richard Hipp]

On Mar 5, 2010, at 11:58 AM, vannia wrote:

 at ~/fossil :
 ./fossil new r_test
 ./fossil open r_test
 ./fossil add testwww
 ./fossil commit
 ./fossil server


 at ~/fossil2:
 ( i have another copy of the executable )
 ./fossil clone http://localhost:8080 testClone
 ( ls shows the repository )
 ./fossil open testClone
 ( ls shows the source tree and repository, now i want the code files  
 for
 editing )
 ./fossil checkout --latest
 ( not sure if this is the correct command or if i'm missing something,
 shows error is not a check in )


That shows me enough to replicate the problem (I suppose - I haven't  
actually tried yet.)  But it also shows me that while this is a bug,  
it is not something to worry about.  The fossil open has already  
done the fossil checkout for you.  You can omit the checkout  
command.

What does fossil timeline show?  fossil status?

 vannia




 -- 
 Este mensaje ha sido analizado por MailScanner
 en busca de virus y otros contenidos peligrosos,
 y se considera que está limpio.

 ___
 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...@hwaci.com



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

Re: [fossil-users] getting fossil working

[D. Richard Hipp]

On Mar 4, 2010, at 7:26 PM, vannia wrote:

 I'm sorry to bother w such a basic question, this is my first time  
 using
 a cms, and I will need one for a project that will begin shortly,
 i don't want to move to testing other cms's, and  I'm hoping to get  
 this
 running.

 I've downloaded fossil, created a new rep, added  committed files .
 Next I started the server, and cloned the repository,
 now I open the clone , but I want to see the actual files (code) and
 I haven't succeeded.
 If i do a checkout i getobject [#] is not a check-in 
 error,
 but i don't know what i'm missing.


What command did you enter in order to get the error message above?


 Thanks for reading this,

 Vannia H.


 -- 
 Este mensaje ha sido analizado por MailScanner
 en busca de virus y otros contenidos peligrosos,
 y se considera que está limpio.

 ___
 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...@hwaci.com



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

Re: [fossil-users] Graphical display of fork/merge actions in timeline

[D. Richard Hipp]

On Feb 8, 2010, at 9:28 PM, altufa...@mail.com wrote:

 In my local copy of fossil (with two extra branches) some arrows go  
 over boxes:

 graph.png

 Here is how merging is done: trunk → ufossil → mycfg, although  
 mycfg branch was branched out from trunk.

 Is this expected?

No.  It's a bug.  I'm working on it.


 - Altu



 -Original Message-
 From: Clark Christensen cdcmi...@yahoo.com
 To: fossil-users@lists.fossil-scm.org
 Sent: Tue, Feb 9, 2010 3:47 am
 Subject: Re: [fossil-users] Graphical display of fork/merge actions  
 in timeline

 FWIW, IE6 on XP, well, not so good.  The boxes appear to be shifted  
 down to
 align with the second line of text in the notes.

 Personally, I don't care about IE6, but it _is_ out there in large  
 numbers.  If
 it were up to me, I would disable the graphical display for IE6 with  
 a simple
 browser sniff.

 Also, IE supports conditional comments (blocks of code that can be
 parsed/rendered depending on browser version).  Might something like  
 that be
 useful here?

 http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx

  -Clark




 - Original Message 
 From: D. Richard Hipp d...@hwaci.com
 To: fossil-users@lists.fossil-scm.org
 Sent: Mon, February 8, 2010 10:58:11 AM
 Subject: Re: [fossil-users] Graphical display of fork/merge actions  
 in timeline


 On Feb 8, 2010, at 1:41 PM, verizon wrote:

  Looking at it with Firefox 3.6 and Safari 4.0.4 (on OS X 10.6.2) I
  don't see any difference in the presentation. vertical and
  horizontal alignment appear identical on both browsers.
 
  --jim

 Tnx, Jim;  I fixed the Safari thing.  And I fixed it so that the graph
 regenerates when you resize the browser.  (Same fix, really.)

 IE is still given trouble, of course...

 
  On 8 Feb, 2010, at 13:23, Brett Schwarz wrote:
 
  On Mon, Feb 8, 2010 at 9:28 AM, Jeremy Cowgar jer...@cowgar.com
  wrote:
  So the updated score is:
 
  * Firefox, Opera, Chrome and Konqueror all work
  * IE does not work at all (at least versions 6 and 8, so we can
  *assume* 7 as well)
  * Safari has some issues
 
 
  I have IE 8. I got it to work by changing the Document Mode to IE8
  Standards. There's probably someway around this programmable...I
  just
  haven't looked yet...
  ___
  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

 D. Richard Hipp
 d...@hwaci.com



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

 ___
 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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] commercial support / development

[D. Richard Hipp]

On Feb 9, 2010, at 1:03 PM, tyju tiui wrote:

 Hi,

 Is there any way to get commercial support / development for fossil?


We don't have a formal system in place for commercial support as there  
is for SQLite, but we have taken on one support customer under a  
custom contract.  If you or someone you know are interested in  
becoming support customer #2, please call me at my office.   
+1.704.948.4565.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] titles in embedded documentation

[D. Richard Hipp]

On Feb 9, 2010, at 1:55 PM, Higham, Paul wrote:

 I am using embedded documentation for a small project and I want to  
 be able to control the page titles, one title per .wiki file.  Is  
 there a way to do that using the wiki markup only or do you have to  
 control the whole page in html?  Left as is all the .wiki pages  
 display with the default title of ‘Documentation’ and I don’t see a  
 way of intercepting this.


Yes.  Just put your preferred title inside of title.../title  
markup at the beginning of the document.  For example:

Raw Markup:  http://www.fossil-scm.org/fossil/artifact?name=5108txt=1

Yields: http://www.fossil-scm.org/fossil/doc/tip/www/stats.wiki

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Graphical display of fork/merge actions in timeline

[D. Richard Hipp]

On Feb 8, 2010, at 1:41 PM, verizon wrote:

 Looking at it with Firefox 3.6 and Safari 4.0.4 (on OS X 10.6.2) I  
 don't see any difference in the presentation. vertical and  
 horizontal alignment appear identical on both browsers.

   --jim

Tnx, Jim;  I fixed the Safari thing.  And I fixed it so that the graph  
regenerates when you resize the browser.  (Same fix, really.)

IE is still given trouble, of course...


 On 8 Feb, 2010, at 13:23, Brett Schwarz wrote:

 On Mon, Feb 8, 2010 at 9:28 AM, Jeremy Cowgar jer...@cowgar.com  
 wrote:
 So the updated score is:

 * Firefox, Opera, Chrome and Konqueror all work
 * IE does not work at all (at least versions 6 and 8, so we can  
 *assume* 7 as well)
 * Safari has some issues


 I have IE 8. I got it to work by changing the Document Mode to IE8
 Standards. There's probably someway around this programmable...I  
 just
 haven't looked yet...
 ___
 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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Graphical display of fork/merge actions in timeline

[D. Richard Hipp]

On Feb 8, 2010, at 2:08 PM, Jeremy Cowgar wrote:

 Hm, in what way is IE giving you fits? It's *almost* working for me.  
 If you resize the window, the graph does not resize, but at least  
 it's displaying now :-)

The graph is misaligned.  The node boxes do not line up with the text  
to the right.


 Jeremy


 On Feb 8, 2010, at 1:41 PM, verizon wrote:

 Looking at it with Firefox 3.6 and Safari 4.0.4 (on OS X 10.6.2)
 I don't see any difference in the presentation. vertical and
 horizontal alignment appear identical on both browsers.

 --jim

 Tnx, Jim;  I fixed the Safari thing.  And I fixed it so that the
 graph regenerates when you resize the browser.  (Same fix, really.)

 IE is still given trouble, of course...


 On 8 Feb, 2010, at 13:23, Brett Schwarz wrote:

 On Mon, Feb 8, 2010 at 9:28 AM, Jeremy Cowgar
 jer...@cowgar.com wrote:

 So the updated score is:

 * Firefox, Opera, Chrome and Konqueror all work
 * IE does not work at all (at least versions 6 and 8, so we
 can *assume* 7 as well) * Safari has some issues


 I have IE 8. I got it to work by changing the Document Mode to
 IE8 Standards. There's probably someway around this
 programmable...I just haven't looked yet...
 ___ 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

 D. Richard Hipp
 d...@hwaci.com


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-
 users
 ___
 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...@hwaci.com



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

Re: [fossil-users] How to set-up multiple-repo CGI-based server?

[D. Richard Hipp]

On Feb 3, 2010, at 1:33 AM, Ron Aaron wrote:

 Hi all -

 At the moment, I'm serving a number of repositories from the same  
 CGI-based
 Apache server, using a separate script for each repo.  This works  
 fine, of
 course.

 What I would like to do, is have magic happen so that I can simply  
 put a new
 Fossil repo on the server, and have it available without  
 necessitating another
 CGI script.

With check-in http://www.fossil-scm.org/fossil/vinfo/49cffc0187 the  
multi-repository feature of Fossil is enhanced in two ways:

(1) For the fossil http and fossil server commands when the  
REPOSITORY is really a directory full of repositories, there is now a  
new command-line option:  --notfound URL.  If the pathname does not  
match any of the repositories in the directory, then instead of  
issuing a 404 Not Found reply, the server issues a 302 Moved  
Temporarily redirect to the URL specified as an option to the -- 
notfound.  You can use this to specify a default repository, or to  
redirect to some other page that provides a listing of available  
repositories.  Example:

  fossil server -port 80 -notfound default .

In the above, Fossil listens on port 80 and processes requests against  
repositories in the working directory.  If the pathname does not  
specify a valid repository, the repository default.fossil is used.

The command above works all the time on windows.  On unix, you have to  
be root in order to bind to port 80.  But this is safe, it turns out.   
Fossil will automatically put itself into a chroot jail and drop root  
privileges prior to processing user input.  Fossil will chroot to the  
directory that holds the repository.  If a repository is specified  
directly, then fossil will take on the same userid and groupid as the  
repository file. If a directory-of-repositories is specified, then  
fossil will take on the userid and groupid of the directory.
As of the 49cffc check-in the automatic chroot jail feature works with  
the server command in addition to the http command, and automatic  
chroot jail also works with the directory-of-repositories feature.

(2) The CGI script now has additional options to make use of the  
directory-of-repository feature and the --notfound redirect.  Example:

   #!/usr/bin/fossil
   directory: /home/www/fossil
   notfound: /sqlite

In the example above, the directory /home/www/fossil presumably  
contains many fossil repositories.  The first element of the pathname  
selects the repository.  If the first element of the pathname does not  
match any repository, then a 302 redirect to /sqlite (which will  
target the sqlite.fossil repository)l is performed.

Setting up a Fossil server is getting complicated with all these new  
possibilities.  Can someone please write up a concise tutorial for new  
users.  Perhaps begin with the simple and easy cases, then guide the  
reader toward more complex settings made possible by resent changes.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Repository-dependant cookies

[D. Richard Hipp]

On Feb 1, 2010, at 7:24 AM, Wilson, Ronald wrote:

 I wish it served a page at the root that listed all hosted  
 repositories.  Would it be a security problem to do that?


I thought it would be.  Perhaps not in every instance, but I can  
envisions scenarios where a user would not want that listing to appear.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] can't clone or sync from fossil directory server

[D. Richard Hipp]

On Feb 1, 2010, at 9:24 AM, Wilson, Ronald wrote:

 I started using the latest fossil server today that serves multiple  
 repositories in a directory.  The ui for each repository is working,  
 but I can’t clone and I can’t sync.  For example:

 http://svn.thereverend.org:8080/xywinservice -- this works

 but this doesn’t:

 PS C:\rev fossil clone http://svn.thereverend.org:8080/xywinservice  
 test.f

I'm guessing your workaround is to append /xfer to the end of the  
URL - until I get this fixed.

 Bytes  Cards  Artifacts Deltas
 Send:  49  1  0  0
 ERROR. server says:  404 not found
 Send: 619 24  0  0
 ERROR. server says:  404 not found
 Total network traffic: 624 bytes sent, 390 bytes received
 Rebuilding repository meta-data...
 0 (0%)...
 project-id: (null)
 server-id:  824e44c20f7188111774cfd76f87e4e6709178cc
 admin-user: rwilso20 (password is c4fea3)

 Ron Wilson, Engineering Project Lead
 (o) 434.455.6453, (m) 434.851.1612, www.harris.com

 image001.pngHARRIS CORPORATION   |   RF Communications  
 Division 
 
 assuredcommunications™

 NOTICE:  This e-mail transmission (and any of its attachments) may  
 contain confidential, proprietary and/or privileged information.   
 The sender intends this transmission only for the designated  
 recipient(s).  If you are not a designated recipient (or authorized  
 to receive for a designated recipient), you are hereby notified that  
 the disclosure, copying, distribution or use of any of the  
 information contained in this transmission is strictly prohibited.   
 If you have received this transmission in error, please destroy this  
 message, delete any copies which may exist on your system and notify  
 the sender immediately.  Thank you.


 ___
 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...@hwaci.com



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

Re: [fossil-users] Potential webhost accepting a fossil

[D. Richard Hipp]

On Feb 1, 2010, at 9:16 PM, Simon Tremblay wrote:

 I set my budget at 5-12$ per month.

 Does anyone have any suggestions on hosts that would allow hosting a  
 fossil server?

 If anyone could give me more information on what I would need to ask  
 or look for on a hosting plan to be able to host it or could tell me  
 about their current hosting it would also really help me a lot.


Fossil itself is hosted on three separate geographically distributed  
systems.  (See http://www.fossil-scm.org/fossil/doc/tip/www/selfhost.wiki 
  for details.)  The primary server is a Linode 720 ($40/month).   
Another server is a Linode 360 at $20/month.  Both are out of your  
budget range.  But the third is a Hurricane Electric Starter Virtual  
Host account at $10/month.  The HE Starter Virtual Host gives you SSH  
access to an account on a linux box with 5GB of storage, 500GB/month  
of transfer, 1000 POP3/IMAP mailboxes, a C compiler, and Apache with a  
cgi-bin.  You'll have to upload the fossil sources to your account and  
compile the fossil server.  The details on how to set up the CGI  
script are shown in the link above.  Contact HE at 
http://he.net/web_hosting.html

I have no connection with HE other than being a satisfied customer  
since 1999.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Repository-dependant cookies

[D. Richard Hipp]

On Jan 30, 2010, at 8:24 AM, rat...@stumvolls.de  
rat...@stumvolls.de wrote:

 Hello

 I'm hosting more than one repository on a single machine. I have to
 logon everytime, when i change in my browser from one to another
 repository.

 Would it be possible to have a Login-Cookie for every repository? I
 think the Cookie-name should have a repository-dependend part.

That is the way it is currently implemented.

I host about 2 dozen repositories on http://www.sqlite.org (examples: 
http://www.sqlite.org/src 
, http://www.sqlite.org/docsrc, http://www.sqlite.org/br3317) and my  
browser (Firefox) keeps separate cookies for each.  Are you saying  
this does not work for you?



 Thanks
 Wolfgang

 ___
 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...@hwaci.com



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

Re: [fossil-users] Repository-dependant cookies

[D. Richard Hipp]

On Jan 30, 2010, at 12:33 PM, rat...@stumvolls.de  
rat...@stumvolls.de wrote:

 Hello again

 Here are some more informations about my configuration:

 * Server OS: Windows Home Server(Windows 2003 based)
 * running two different fossil repositories on ports 8000 and
 8001(Fossil version [a3c97c9063] 2010-01-21 20:53:59)
 * client OS: XP prof.
 * Browser: Firefox 2

 If i switch between the repositories, the current login becomes  
 invalid.

 I opened the cookie-dialog of firefox. There i can see One cookie from
 my server, named
  fossil_login_

I guess firefox 2 sends to same cookie to port 8001 as it sends to  
port 8000. as if localhost:8000 and localhost:8001 were the same  
website.

If you switch to running a webserver (on port 80, say) and run your  
repositories as CGI scripts, the names of each CGI script will be  
appended (as hex) to the login cookie name and this problem will go  
away.  It is not clear to me what (if anything) we ought do to Fossil  
to make it easier to work around this.

There was another recent request for the ability to serve multiple  
repositories off of the same TCP port without using a web server.  The  
current syntax to launch a stand-alone server is:

   fossil server REPOSITORYFILE

Suppose we expanded this to allow multiple repositories to be named on  
the command-line.  So if you had a directory full of repositories, you  
could do:

   fossil server *.fossil

Suppose the names of the repositories files are abc.fossil,  
def.fossil, ghi.fossil and so forth.  Then to reach each repository,  
visit:

 http://localhost/abc
 http://localhost/def
 http://localhost/ghi

And so forth.  If this functionality were implemented, then the cookie  
names would be fossil_login_2F616263, fossil_login_2F646566, and  
fossil_login_2F676869.  Since the cookie names are different, you  
could log onto all repositories all at once.  If no repository is  
specified in the URL (if  you enter http://localhost/) what should it  
do?  Show an error?  Return a list of repositories?  Choose the first  
one named?

Perhaps the syntax should be:

 fossil server --directory FOLDER_HOLDING_REPOSITORIES

In that case, fossil is able to serve any fossil repository in the  
named directory.  The particular repository chosen by the path in the  
URL.  With this syntax, new repositories can be added to the site  
without having to restart the server - simply move files into the  
appropriate folder.  We still have the problem of what to do with an  
unknown path.


 I think the problem is, that there is no 'repository-extension' behind
 the last underscore.

 The test_env-information, given by one of the servers is:
 g.zBaseURL = http://DELETED BY ME:8000
 g.zTop =
 GATEWAY_INTERFACE = CGI/1.0
 HTTP_COOKIE =
 fossil_login_=1%2F5A300CEC00A1528DAE8F21FD975FE6742534E95E2D2443872E
 HTTP_HOST = DELETED BY ME:8000
 HTTP_USER_AGENT = Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 (.NET CLR 3.5.30729)
 PATH_INFO = /test_env
 QUERY_STRING =
 REMOTE_ADDR = DELETED BY ME
 REQUEST_METHOD = GET
 REQUEST_URI = /test_env
 fossil_login_ = DELETED BY ME

 Maybe this information helps. Feel free to contact me, if you need
 further information.

 Wolfgang


 ___
 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...@hwaci.com



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

Re: [fossil-users] cloning http://www.fossil-scm.org/ fails

[D. Richard Hipp]

On Jan 24, 2010, at 2:11 AM, Michael Richter wrote:

 OK, maybe I'm being as thick as a whale sandwich, but when I try to  
 update my copy of fossil from fossil-scm.org, after downloading a  
 source tarball and compiling, I get the same login problem I had  
 with my earlier version:

 mich...@isolde:~/Development/fossil$ fossil version
 This is fossil version [a3c97c9063] 2010-01-21 20:53:59 UTC
 mich...@isolde:~/Development/fossil$ fossil remote-url
 http://fossil-scm.org/fossil
 mich...@isolde:~/Development/fossil$ fossil remote-url --show-pw
 http://fossil-scm.org/fossil

I removed the --show-pw option.   It seemed insecure.  But you can  
still put the userid on the remote-url:

 fossil remote http://ttmrich...@www.fossil-scm.org/

Then the first time you do

 fossil sync

You will get the login failed message and it will prompt you for  
your password and try again.

 mich...@isolde:~/Development/fossil$ fossil sync
 Server:http://fossil-scm.org/fossil
 Bytes  Cards  Artifacts Deltas
 Send: 589 10  0  0
 1Server Error: login failed

Because it did not backspace over the 1 here, I think that means  
that you are using an older version of Fossil.  I think I fixed that  
display bug.


 fossil: server says: login failed

 I can't clone a new copy either:

 mich...@isolde:~/Development/fossil$ fossil clone http://www.fossil-scm.org 
  ../junk.fsl
 Bytes  Cards  Artifacts Deltas
 Send: 625 25  0  0
 1Server Error: login failed
 fossil: server says: login failed

 This is from the source tarball taken from 
 http://www.fossil-scm.org/download/fossil-src-20100121205359.tar.gz 
  and compiled straight.

 2010/1/24 D. Richard Hipp d...@hwaci.com

 On Jan 23, 2010, at 5:55 PM, Florian Weimer wrote:

  * D. Richard Hipp:
 
  Better: Just download the latest precompiled binary or tarball from
  http://www.fossil-scm.org/download.html and use that instead of the
  version you are currently using.
 
  Is this supposed to reoccur?  I'm asking because Debian is  
 planning to
  release Fossil with squeeze, and this doesn't make sense if the  
 client
  needs constant code changes to stay interoperable with other  
 people's
  repositories.
 

 No.  It was a mistake that it occurred this time.  And probably soon
 I'll fix the server so that it works with both old and new clients.

 The change was that the server is now a little stricter about login
 credentials.  If the password is not correct, it complains and refuses
 to do anything.  Before the change, the server would continue running
 with the permissions of the special user nobody.  Meanwhile, older
 clients are sending (bogus) login credentials even if the user doesn't
 specify any.  (That has also been fixed.)  The combination of these
 two issues results in older clients not being able to clone from newer
 servers.

 I can probably come up with a hack to the server-side that allows
 older clients to work.  But it seems like a relatively minor problem,
 so I haven't put much effort into that yet.

  (This is a bit like changing the on-disk file format for SQLite. 8-)

 The Fossil file format is unchanged.  It is just the authentication
 protocol that has been updated and which caused the problem.

  ___
  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...@hwaci.com



 ___
 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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] cloning http://www.fossil-scm.org/ fails

[D. Richard Hipp]

On Jan 23, 2010, at 5:55 PM, Florian Weimer wrote:

 * D. Richard Hipp:

 Better: Just download the latest precompiled binary or tarball from
 http://www.fossil-scm.org/download.html and use that instead of the
 version you are currently using.

 Is this supposed to reoccur?  I'm asking because Debian is planning to
 release Fossil with squeeze, and this doesn't make sense if the client
 needs constant code changes to stay interoperable with other people's
 repositories.


No.  It was a mistake that it occurred this time.  And probably soon  
I'll fix the server so that it works with both old and new clients.

The change was that the server is now a little stricter about login  
credentials.  If the password is not correct, it complains and refuses  
to do anything.  Before the change, the server would continue running  
with the permissions of the special user nobody.  Meanwhile, older  
clients are sending (bogus) login credentials even if the user doesn't  
specify any.  (That has also been fixed.)  The combination of these  
two issues results in older clients not being able to clone from newer  
servers.

I can probably come up with a hack to the server-side that allows  
older clients to work.  But it seems like a relatively minor problem,  
so I haven't put much effort into that yet.

 (This is a bit like changing the on-disk file format for SQLite. 8-)

The Fossil file format is unchanged.  It is just the authentication  
protocol that has been updated and which caused the problem.

 ___
 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...@hwaci.com



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

Re: [fossil-users] https doesn't work through proxy?

[D. Richard Hipp]

HTTPS by its very nature cannot use a proxy.  It must go direct.

I should probably enhance Fossil so that it automatically bypasses the  
proxy when using HTTPS.  Until then, you can use the --proxy off  
command-line option to disable the proxy when using HTTPS.


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Numbering in the ticket view

[D. Richard Hipp]

On Jan 22, 2010, at 6:32 AM, Jacek Cała wrote:

 Hi,

 Do you have any idea how to add numbering to the list of tickets. It  
 would be nice to have a quantitative view on the solved/unsolved  
 issues. I was skimming through the sqllite manual but couldn't find  
 anything usable.



Are you asking for something like this:  
http://www.fossil-scm.org/fossil/rptview?rn=5

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] https doesn't work through proxy?

[D. Richard Hipp]

On Jan 22, 2010, at 10:58 AM, altufa...@mail.com wrote:

 Well,

 In my office all communication goes through same http proxy,  
 including https. I guess they do pass-thru somehow.

Think about it.  With HTTPS, only the two endpoints are able to read  
the content of the transmission.  How can the proxy get involved?  If  
the proxy could come into play, that would mean that HTTPS was  
vulnerable to a man-in-the-middle attack - it would be a serious  
weakness of HTTPS.


 - Altu



 -Original Message-
 From: D. Richard Hipp d...@hwaci.com
 To: fossil-users@lists.fossil-scm.org
 Sent: Fri, Jan 22, 2010 9:02 pm
 Subject: Re: [fossil-users] https doesn't work through proxy?

 HTTPS by its very nature cannot use a proxy.  It must go direct.

 I should probably enhance Fossil so that it automatically bypasses the
 proxy when using HTTPS.  Until then, you can use the --proxy off
 command-line option to disable the proxy when using HTTPS.


 D. Richard Hipp
 d...@hwaci.com



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 ___
 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...@hwaci.com



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

Re: [fossil-users] Publicize FOSSIL

[D. Richard Hipp]

On Jan 21, 2010, at 8:59 AM, verizon wrote:

   Would any of you consider appearing on the podcast FLOSS Weekly 
 (http://twit.tv/floss 
 ) to talk about FOSSIL ? This would be an excellent chance to get  
 the word out about how good and useful a tool this is.  They have a  
 wide audience and it would spark a lot of interest in the project.   
 Also as part of the interview they always ask what sort of help the  
 project can use.

   You can check on the website to listen to shows and also see the  
 projects he, Leo Laporte and Jono Bacon (from Ubuntu) have covered.

   The host (Randal Schwartz) stated, projects that contact him with  
 potential interviewees would get bumped up in the schedule.  The  
 spokesman should contact him at mer...@stonehenge.com.

   I'm just writing as a happy user that would like to get this  
 wonderful tool some more publicity.

Randal has interviewed me before (though about SQLite, not Fossil).  
http://twit.tv/floss26

But if he and others think it is worthwhile, I'll be happy to do  
another interview...

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Add files recursively?

[D. Richard Hipp]

On Jan 21, 2010, at 6:38 PM, Stephen De Gabrielle wrote:

 it also seems to have a successor - thought I don't know how well  
 'baked' it is.
 http://basieproject.org/



Both projects seem to be a big website that is installed.  Purely  
client/server.  No support for disconnected operation.  Do I have that  
right, or did I miss something?

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] cloning http://www.fossil-scm.org/ fails

[D. Richard Hipp]

On Jan 21, 2010, at 7:35 PM, Kyle McKay wrote:

 I just recently tried to clone http://www.fossil-scm.org/, but it  
 fails:

 fossil clone http://www.fossil-scm.org/ fossil.fossil
Bytes  Cards  Artifacts Deltas
 Send:  49  1  0  0
 Received:  20  1  0  0
 Send: 619 24  0  0
 1Server Error: login failed
 fossil: server says: login failed

 Is that expected?  Do I need to get a login in order to be able to
 clone?

 All 3 of the URLs listed on:

 http://www.fossil-scm.org/fossil/doc/tip/www/selfhost.wiki

 fail with the same error on a clone attempt.


I made some changes to the way the sync server works - it is much  
stricter about logins now.  If the userid/password is wrong, it aborts  
straightaway, whereas before it would continue running, but with the  
privileges of user nobody.  This is OK with the corresponding  
version of the client, since the latest client code doesn't even  
attempt to login if no login credentials are provided.

However, the old client tries to login even if not credentials are  
given.  So this doesn't work well with the new server.  Oops.

I'll work on a fix.  Please try again in a few hours


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] cloning http://www.fossil-scm.org/ fails

[D. Richard Hipp]

On Jan 21, 2010, at 7:57 PM, D. Richard Hipp wrote:


 On Jan 21, 2010, at 7:35 PM, Kyle McKay wrote:

 All 3 of the URLs listed on:

 http://www.fossil-scm.org/fossil/doc/tip/www/selfhost.wiki

 fail with the same error on a clone attempt.

 I'll work on a fix.  Please try again in a few hours


Better:  Just download the latest precompiled binary or tarball from 
http://www.fossil-scm.org/download.html 
  and use that instead of the version you are currently using.

With the new client, you don't need to include the password in the URL  
of a sync.  Instead of:

   fossil sync http://userid:passw...@example.com/

You just include the userid, like this:

   fossil sync http://use...@example.com/

And it prompts you for the password.  So people looking over your  
shoulder can't see your password.  And if you enter the wrong  
password, it tells you and asks again.  Or if your password changes  
and you do just:

   fossil sync

It will prompt you to enter a new password (which it of course  
remembers for the next sync...)

So, I didn't break stuff arbitrarily.  I really am trying to make  
things better.  Thanks for your patience.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Web Interface Authentication

[D. Richard Hipp]

On Jan 20, 2010, at 1:13 PM, Daniel Carrera wrote:

 Hello,

 I was just reading this page:

 http://www.fossil-scm.org/index.html/doc/tip/www/password.wiki

 Under the section Web Interface Authentication it says:

 The user password is sent over the wire as cleartext on the initial
 login attempt. The plan moving forward is to compute the SHA1 hash of
 the password on the client using javascript and then send only the  
 hash
 over the wire, but that plan has not yet been set in code.


 This idea will do absolutely nothing for security. Anybody who would
 intercept the password could just as easily intercept the password  
 hash.
 Then he can login by sending the hash, without having to know the  
 password.

No, it does add to the security.  The idea is that many users will  
have the same password for multiple accounts.  (It is widely known  
that this is a bad practice, but people still do it.)  So while a  
snooper could intercept the hash and log into your Fossil account,  
they wouldn't be able to log into different Fossil repositories, or  
your gmail account, or your Bank of America account.



 The CORRECT way to handle web authentication is to use HTTPS. This  
 is a
 well-designed standard that actually does provide a reasonable  
 amount of
 privacy between client and server.


 Elsewhere in the documentation I read about the move from clear text
 passwords to SHA1 hashes. Although this is no doubt an improvements,
 please know that SHA1 hashes are not a good way to secure passwords.
 Anybody can make a large database of common passwords, calculate the
 SHA1 hash of each password, and compare the hashes.

If you read more closely, you will see that the SHA1 hash is of the  
Fossil project ID, the user name, and the password.  This means that  
the dictionary attack you describe won't work.  It also means that if  
a single user has the same password on multiple Fossil projects,  
nobody (but that user) will know because the hash is different each  
time.  It also means that if two users on the same project happen by  
chance to select the same password, nobody will know because, again,  
the hashes will be different.


 The CORRECT way to store passwords securely is using the PBKDF2  
 standard
 (Password-Based Key Derivation Function version 2) found in RFC  
 2898. To
 save you the trouble, I'll show you a simple implementation using  
 SHA1.

 Basically, you want every user to have a unique (or nearly unique)  
 salt.
 Just generate a random number (it doesn't matter if it's random). Then
 put the salt and password through the following function:

 // PBKDF2 function from RFC 2898
 // Using HMAC(SHA1) as the Pseudo-Random function.
 function pbkdf2( $pass, $salt, $count = 1000, $kl = 32) {
 $hl = 40;  # SHA1 hash length
 $kb = ceil($kl / $hl); # Key blocks to compute
 $dk = '';  # Derived key

 # Create key
 for ( $block = 1; $block = $kb; $block ++ ) {

 # Initial hash for this block
 $ib = $b = hash_hmac(sha1, $salt.pack('N', $block),$pass,  
 true);

 # Perform block iterations
 for ( $i = 1; $i  $count; $i ++ )

 # XOR each iterate
 $ib ^= ($b = hash_hmac($algo, $b, $pass, true));

 $dk .= $ib; # Append iterated block
 }

 # Return derived key of correct length
 return substr($dk, 0, $kl);
 }


 Cheers,
 Daniel.
 ___
 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...@hwaci.com



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

Re: [fossil-users] Add files recursively?

[D. Richard Hipp]

On Jan 20, 2010, at 4:58 PM, Daniel Carrera wrote:

 D. Richard Hipp wrote:
fossil add directory-name

 That recursively adds all files contained within the directory.

 Thanks.

 Now fossil polluted my root directory with several files (__FOSSIL__,
 manifest, manifest.uuid). Is that normal? is there anything I can do
 about that? Other SCMs are nice enough to put everything in one
 directory so they don't pollute my root directory too much (e.g.  
 _darcs/
 contains all the files darcs needs).


__FOSSIL__ is required, though you can rename it to .fos if you  
don't want to look at it.  This is the equivalent to _darcs/ or CVS/  
or whatever.  But it is a single file (an SQLite database) rather than  
a directory.

manifest and manifest.uuid are convenience information files.  They  
are not used by Fossil.  Fossil provides them to you for your  
information.  You can delete them if you want.  I think they will come  
back, though, the next time you check-in our check-out.  There have  
been a number of requests to add an option to omit those files.


 Daniel.
 ___
 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...@hwaci.com



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

Re: [fossil-users] Using fossil on a server

[D. Richard Hipp]

On Jan 20, 2010, at 5:21 PM, Daniel Carrera wrote:

 D. Richard Hipp wrote:
 push (also sync which is a combination of push and pull done
 all at once) transfers files from the local myproject.fossil out to
 the server repository.

 So... I should put each project in a separate directory otherwise the
 projects can trample on each other's files. Yes?

On your local machine where you have a check-out, then you can only  
have one check-out per directory.  I thought in your previous email  
you were asking where to put the repositories.  You can put the  
repositories anywhere you like.  But check-outs cannot overlap.



 It will onlyl work if you have write
 permission at the server repository.  You'll need to specify your
 userid and password as part of the URL:

  http://username:passw...@www.example.com/runfossil.cgi

 Ok. I can't test that yet. I'm still working on getting a hello  
 world
 CGI script working on my server.


 2) How do I give people passwords so they can commit to the server?

 Log in on the Fossil CGI script on the server as the administrator.
 Then visit the Setup menu option, and under that Users.  There is
 an Add button there.

 Ok, I ran fossil ui and it opened a browser window. In the Admin
 section I can see that my repository is set to not require local
 authentication. I do not see a place to change my password.

 There is no Setup menu option, but I go to Admin  Users. I see
 several users that I didn't create (anonymous, developer, nobody,
 reader). I do not see an Add button anywhere.

The Add button should be on a sub-menu bar below the main menu bar.



 You can create users manually using this same command-line interface
 too, if you want.  But I find it easier to use the web interface.

 I'd like to learn how to do it on the web interface.


 When you first created repository (or first cloned it) it should have
 created an initial admin user for you with a silly password.  If you
 remember that user and password you can use it.  Otherwise, create a
 new one as shown above.  Then use the web interface to clean up the
 old one.

 I have the old one, I wrote it down. How do I change my password?

If on the Users page you click on one of the user names, you can edit  
the password there.  (That only works if you are the Setup user.)  Or  
you can go to the Logout page and change your password there.   
(Anybody with permission to change their own password can change  
passwords there.)



 On the server side, I put *all* of my projects in a common folder.
 There are 30-odd different fossil repositories hosted by www.fossil-scm.org
  (which is the same machine and IP address as www.sqlite.org and 
 www.cvstrac.org
  and 3dcanvas.tcl.tk and a few others...)  Each repository has its
 own 2-line CGI script, of course.

 You don't have to put all the repositories in the same folder.  But I
 find that easier, since it makes it easier to keep up with them all.

 Ok. Thanks.

 Daniel.
 ___
 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...@hwaci.com



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

Re: [fossil-users] Problems with server

[D. Richard Hipp]

On Jan 20, 2010, at 6:13 PM, Daniel Carrera wrote:

 Hello,

 Ok, I've set up a server, and it seems to work:

 http://projects.theingots.org/cgi-bin/awards.cgi

 I created a user name and password. Then on my local computer I did:

 fossil clone http://projects.theingots.org/awards.fossil   
 awards.fossil

Why did you change the URL?

 fossil clone http://projecs.theingots.org/cgi-bin/awards.cgi  
awards.fossil



 This gave some errors:


 Bytes  Cards  Artifacts Deltas
 Send:  49  1  0  0
 ERROR. server says:  404 Not Found
 Send: 619 24  0  0
 ERROR. server says:  404 Not Found
 Total network traffic: 751 bytes sent, 760 bytes received
 Rebuilding repository meta-data...
 0 (0%)...
 project-id: (null)
 server-id:  1f24953a329877f5cf2f5813ee0ea39b3921ec3e



 But anyways, I decided to continue and add some files:


 fossil open awards.fossil
 fossil add some-dir/
 fossil commit


 The commit step gave some errors too. It succeeded in asking for my  
 GPG
 passphrase, but there are more 404 errors:


 % fossil commit
 Autosync:  http://projects.theingots.org/awards.fossil
 Bytes  Cards  Artifacts Deltas
 Send:  90  1  0  0
 ERROR. server says:  404 Not Found
 Total network traffic: 307 bytes sent, 380 bytes received
 nano /home/daniel/Work/Ingot/Apo/sandbox/ci-comment-C37923175DEF.txt

 You need a passphrase to unlock the secret key for
 user: Daniel Carrera (Personal Key) dcarr...@gmail.com
 1024-bit DSA key, ID 8B0C0559, created 2010-01-20

 New_Version: bb9d806859173586cf0083e84159fd312a70f2b7
 Autosync:  http://projects.theingots.org/awards.fossil
 Bytes  Cards  Artifacts Deltas
 Send:  293534746104  0
 ERROR. server says:  404 Not Found
 Total network traffic: 74196 bytes sent, 380 bytes received



 You will not be surprised to hear that trying fossil push also
 produced the same 404 error.

 Any ideas?

 Daniel.
 ___
 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...@hwaci.com



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

Re: [fossil-users] patch to give pull and sync an --update option

[D. Richard Hipp]

On Jan 18, 2010, at 3:14 PM, Ron Aaron wrote:

 The following patch makes it possible to sync-then-update
 or pull-then-update in one command (like Mercurial hg pull -u):

Fossil already does sync-then-update: simply enable autosync mode  
(on by default) and do an update.   Why do we need a new mechanism  
to accomplish the same thing?



 Index: src/sync.c
 ===
 --- src/sync.c
 +++ src/sync.c
 @@ -68,14 +68,16 @@
 ** This routine processes the command-line argument for push, pull,
 ** and sync.  If a command-line argument is given, that is the URL
 ** of a server to sync against.  If no argument is given, use the
 ** most recently synced URL.  Remember the current URL for next time.
 */
 +int alsoUpdate = 0;
 void process_sync_args(void){
   const char *zUrl = 0;
   int urlOptional = find_option(autourl,0,0)!=0;
   int dontKeepUrl = find_option(once,0,0)!=0;
 +  alsoUpdate = find_option(update,0,0)!=0;
   url_proxy_options();
   db_find_and_open_repository(1);
   if( g.argc==2 ){
 zUrl = db_get(last-sync-url, 0);
   }else if( g.argc==3 ){
 @@ -106,11 +108,12 @@
 **
 ** Usage: %fossil pull ?URL? ?options?
 **
 ** Pull changes from a remote repository into the local repository.
 ** Use the -R REPO or --repository REPO command-line options
 -** to specify an alternative repository file.
 +** to specify an alternative repository file.  Use the --update
 +** command-line option to perform an update after the pull.
 **
 ** If the URL is not specified, then the URL from the most recent
 ** clone, push, pull, remote-url, or sync command is used.
 **
 ** The URL specified normally becomes the new remote-url used for
 @@ -121,10 +124,13 @@
 ** See also: clone, push, sync, remote-url
 */
 void pull_cmd(void){
   process_sync_args();
   client_sync(0,1,0,0,0);
 +  if (alsoUpdate) {
 + update_cmd();
 +  }
 }

 /*
 ** COMMAND: push
 **
 @@ -156,11 +162,12 @@
 ** Usage: %fossil sync ?URL? ?options?
 **
 ** Synchronize the local repository with a remote repository.  This is
 ** the equivalent of running both push and pull at the same time.
 ** Use the -R REPO or --repository REPO command-line options
 -** to specify an alternative repository file.
 +** to specify an alternative repository file.  Use the --update
 +** command-line option to perform an update after the sync.
 **
 ** If a user-id and password are required, specify them as follows:
 **
 ** http://userid:passw...@www.domain.com:1234/path
 **
 @@ -175,10 +182,13 @@
 ** See also:  clone, push, pull, remote-url
 */
 void sync_cmd(void){
   process_sync_args();
   client_sync(1,1,0,0,0);
 +  if (alsoUpdate) {
 + update_cmd();
 +  }
 }

 /*
 ** COMMAND: remote-url
 **

 ___
 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...@hwaci.com



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

Re: [fossil-users] Non-checkout permissioned users and /doc

[D. Richard Hipp]

On Jan 13, 2010, at 10:01 AM, Jeremy Cowgar wrote:

 D. Richard Hipp d...@hwaci.com wrote:
 On Jan 13, 2010, at 9:19 AM, Jeremy Cowgar wrote:

 We could implement attachments for wiki pages and tickets and stuff
 the auxiliary files in an attachment.

 You could keep the code and documention in separate repositories.

 Wiki attachments seems like the right approach.  The file format is
 designed to support wiki attachments - I've just never implemented
 them.  It isn't something that I can add in 5 minutes


 Attach javascript code such as jQuery, TinyMCE and a few others to a  
 wiki page so I can access them via the theme? I'm a bit confused.

 Wouldn't it just be simpler to have a new security attribute, say  
 RdDoc? Then the /doc web handler can check okRead || okRdDoc ?


If you can read using /doc, then you might as well just turn on  
okRead, because a user can read out the text of any source code file  
they want. If /doc can read javascript files out of the repository,  
what is to stop it from reading any other source file out of the  
repository?

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Passwords stored in cleartext in 'user' table

[D. Richard Hipp]

On Jan 9, 2010, at 5:24 PM, D. Richard Hipp wrote:


 OK.  Beginning with http://www.fossil-scm.org/fossil/ci/cfe33dcf92
 Fossil will store passwords on servers as either cleartext or as a
 SHA1 hash of the password. ...

I have tagged this change experimental for now.  I'm planning to  
make some additional (incompatible) changes to make the password  
handling more secure.  You can experiment with this version, but you  
should create backups to restore from after my upcoming incompatible  
changes.

d...@hwaci.com



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

Re: [fossil-users] Passwords stored in cleartext in 'user' table

[D. Richard Hipp]

On Jan 9, 2010, at 11:29 AM, Ron Aaron wrote:

 On Saturday 09 January 2010 18:21:00 D. Richard Hipp wrote:

 There is a trade-off.

 You can store an cryptographic checksum of the password in the user
 table.  ...
 Or you can store the cleartext password in the user
 table and send a cryptographic checksum of the password...

 There is another option: send a crypto checksum over the wire, and  
 store a
 different sum in the user table.  Then the server file does not have a
 cleartext password, nor is one sent on the wire.


I'm not familiar with that algorithm. Can you explain or provide a link?


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Passwords stored in cleartext in 'user' table

[D. Richard Hipp]

On Jan 9, 2010, at 11:35 AM, D. Richard Hipp wrote:


 On Jan 9, 2010, at 11:29 AM, Ron Aaron wrote:

 On Saturday 09 January 2010 18:21:00 D. Richard Hipp wrote:

 There is a trade-off.

 You can store an cryptographic checksum of the password in the user
 table.  ...
 Or you can store the cleartext password in the user
 table and send a cryptographic checksum of the password...

 There is another option: send a crypto checksum over the wire, and
 store a
 different sum in the user table.  Then the server file does not  
 have a
 cleartext password, nor is one sent on the wire.


 I'm not familiar with that algorithm. Can you explain or provide a  
 link?


Wait - I think I get it.  Feed the user-supplied password through a  
cryptographic hash to convert the real password that is the shared  
secret.  Store only the shared secret on the server.  Then use the  
current algorithm to security authenticate using the shared secret.   
Breaking into the server still allows an attacker to recover the  
shared secret and then log into the server in the future, but they  
cannot recover the original password text which might be used on other  
unrelated systems.

OK.  I'll work on that.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Passwords stored in cleartext in 'user' table

[D. Richard Hipp]

On Jan 9, 2010, at 11:04 AM, Ron Aaron wrote:

 I didn't see an option, perhaps it's not even on the list of  
 requests... but
 when I look at the 'user' table, the user's password is stored in  
 cleartext.

 Having my fossil file on a shared server, this makes me a bit  
 nervous.  Anyone
 who has access to that file can read all the user passwords.

 It would be trivial to change the password stored to sha1(login 
 +pw).  In that
 case it would also be difficult to hack, since different users with  
 the same
 password would have wildly different values saved in the user table.


OK.  Beginning with http://www.fossil-scm.org/fossil/ci/cfe33dcf92  
Fossil will store passwords on servers as either cleartext or as a  
SHA1 hash of the password.  It tells the difference by looking at the  
length of the password.  A password in the USER table that is exactly  
40 characters long is assumed to be a SHA1 hash.  Otherwise, the  
password is assumed to be cleartext.

Whenever you change a password, the new password is stored as the SHA1  
hash.   When you create new users, the password is stored as the SHA1  
hash.  There is no mechanism to force the password to be cleartext.   
You can force all cleartext passwords to become SHA1 hashes using this  
command:

 fossil test-hash-password REPOSITORY

Converting from cleartext to SHA1 hash is irreversible, of course.

The client always uses the SHA1 hash as the shared secret, unless the  
password for a sync operation begins with '*'.  If the password for a  
sync begins with '*', then the characters after the '*' are taken to  
be the cleartext password used as the shared secret.  This allows  
newer clients to communicate with legacy servers that do not know  
about the password format change.  If  you have a new fossil client  
and you want to sync against a legacy server, do it this way:

  fossil sync http://userid:*passw...@legacy-server.com/

The new server accepts both the cleartext passwords and the SHA1 has  
as the shared secret, assuming the cleartext is stored in the USER  
table.  That means that newer servers will work with older clients as  
long as you do not update the USER table to store hashes.  Once a hash  
is stored in the USER table, the sync protocol will only work with  
newer clients.

So, older clients will work with newer servers as long as cleartext  
passwords are stored in the USER table, and older servers will work  
with newer clients by adding '*' before the password in the URL.

The simplest upgrade path is probably just to upgrade all clients and  
servers all at once.

The second simplest upgrade path is:

(1) Upgrade servers, but do not modify the USER table.
(2) Start upgrading clients.
(3) After all clients are upgraded, run [fossil test-hash-password] to  
convert the USER table to use hashes instead of cleartext.

I have not yet done step (1) on  the server that runs www.fossil- 
scm.org.  I'll do that after additional testing and after you, gentle  
readers, have reviewed my changes and informed me that my changes are  
free of new security boo-boos.  I eagerly await the results of your  
review.  Tnx.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Security Changes to Timeline

[D. Richard Hipp]

On Dec 31, 2009, at 10:28 AM, Jeremy Cowgar wrote:

 For those who do not follow the commit logs, I just made a change to  
 the way security works in the timeline. I wanted to make everyone  
 aware of the change.

 Here is the commit log entry (with an additional note for clarity):

 

 Changed security for timeline. To view the timeline, you must now  
 have History access (previously you needed Check-out access). The  
 timeline will then display only items which you have access to.  
 o (Check-out) is required for source history, j (Read-Wiki) is  
 required for Wiki history and r (Read-Tkt) is required for Ticket  
 history.


This change makes it so that it is impossible to see the timeline  
without first logging in as anonymous.  I consider that unacceptable.

The purpose of the history capability is to turn off hyperlinks -  
nothing more.  The idea is that for user nobody (which is the user  
that all spiders will have) none of the hyperlinks will be visible and  
so msnbot and Googlebot won't burn through gigabytes of bandwidth  
downloading diffs of every historical version of a project.

User nobody should be able to see the timeline.  They just shouldn't  
have any hyperlinks on the timeline page.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Security Changes to Timeline

[D. Richard Hipp]

On Dec 31, 2009, at 3:46 PM, Jeremy Cowgar wrote:

 Ok, I see what you are saying. I wonder if the history capability  
 would be better named as show links or something along those  
 lines? To me the timeline shows history. The current use of  
 history doesn't seem to be intuitive.

 I see you made some changes in a more recent commit, what does your  
 method do?

 Alternative implementation of timeline security changes - this  
 implementation always shows the timeline link if it is applicable,  
 even if the history capability is disabled.

 Specifically, what do you mean always show the timeline link if it  
 is applicable?

 The final result I was after was to allow someone to view the  
 timeline but not a certain part of it, mainly source code. In my  
 particular situation I use fossil with some open source projects and  
 also at work. I've not used the ticket system built into fossil with  
 my work because I did not want other employees/co-workers to have  
 access to the source code. So, with my change (and probably yours  
 also) you have enough security control to show the timeline but  
 depending on your security you may not see checkin history, wiki  
 history or ticket history.

 From reading your diff it seems that yours does the same (and more  
 eloquently) but I don't understand what you mean always show the  
 timeline.


The Timeline link on the menubar is moved to the left so that it is  
now the second from the left.  This seems a better place, to me.  I  
also arranged for the File menubar option to only appear if the user  
has both history and check-out privileges.

The Timeline menubar link appears if the user has any of check-out,  
read-wiki, or read-ticket.  Only those lines of the timeline that  
are appropriate for the user's capabilities are shown.  So if you set  
up a user to have read-ticket capability, but not check-out, they will  
only see tickets in the timeline, and not check-ins.  That's what you  
wanted, right?


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Please contribute Fossil skins or themes

[D. Richard Hipp]

On Dec 20, 2009, at 2:30 PM, Eric wrote:


 I started this one ages ago to try to get the main menu at the side  
 and a
 bit of a
 different feel, but only realised today that what it needed was an  
 extra
 div. Anyway
 here you are... (tested Firefox 3.5.5, IE 6.0)


 Thanks Richard for putting that one in. But we have now learnt that an
 HTML comment in a skin (in skin.c) will be chopped to just ! by the
 translate program. In this case it would be OK to take that line out  
 of
 the skin altogether, but I don't know if there can be a case where  
 it will
 matter.


The @-translator defaults to SQL comment mode, and omits everything  
following -- as a comment.  The solution is to change the commenting  
mode of the @-translator to treat // as the comment character  
instead of --.  See check-in

 http://www.fossil-scm.org/fossil/ci/4f24addea9


D. Richard Hipp
d...@hwaci.com



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

[fossil-users] Please contribute Fossil skins or themes

[D. Richard Hipp]

Earlier today, I checked in a version of Fossil that has the ability  
to host multiple themes or skins for the web interface and that  
allows users (with Admin privilege) to switch between skins with a  
simple mouse click.

However, the current implementation contains only two built-in skins:   
The old default and a new black theme which is very similar to the  
default.  It would be good, I think to have 6 to 10 different themes  
that show a wide variety of possible looks.  Therefore, I am calling  
on the user community to submit themes for consideration.

To create a new theme or skin, edit the CSS, header, and footer to  
obtain the look you want.  Then run the following command:

 fossil configuration export skin outputfile.txt

And post the outputfile.txt here.  Thanks for contributing.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] tree checksum does not match

[D. Richard Hipp]

On Dec 17, 2009, at 11:15 AM, Michael wrote:

 Richard, were you able to reproduce the problem I described ?

 Do you have any idea(s) why you saw 'MISSING' and I saw 'DELETED'
 using the same packages ?

I have not tried to reproduce it.  I think other issue are more  
pressing - such as dealing with files that have changed into  
directories and handling MISSING files on update. If this really is an  
issue, we'll get to it.  But I'm willing to believe this was operator  
error on my part or something.


 (sha1sum (GNU coreutils) 6.10)
 sha1sum p*.fossil.private == d715284f35c6186827b8a5562acd3fe84d3c1d08
 sha1sum tarball == 26078d9d35687f1635ee58da81481b70cb43d01f


 ~Michael
 ___
 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...@hwaci.com



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

Re: [fossil-users] How to merge a fork with binary files?

[D. Richard Hipp]

On Dec 15, 2009, at 3:30 PM, Heinrich Huss wrote:

 Hi,

 It seems there is something broken in fossil. I'm always getting this
 error when I try to make a 'fossil update':

 $ fossil update
 Assertion failed: (pBlob)-xRealloc==blobReallocMalloc ||
 (pBlob)-xRealloc==blobReallocStatic, file blob_.c, line 170


Bummer.  What does fossil status tell you?  If you don't have any  
changes that you need to check-in, you can probably work around this  
problem by running fossil checkout instead of fossil update.  But  
I'd still like to get to the bottom of the problem.  Do you have a C- 
compiler and a debugger?  Can you run fossil in the debugger and give  
me additional information about where it is failing, so that I can  
find and fix the problem?

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] How to merge a fork with binary files?

[D. Richard Hipp]

On Dec 15, 2009, at 3:53 PM, Stephan Beal wrote:

 On Tue, Dec 15, 2009 at 9:50 PM, Heinrich Huss 
 heinrich.h...@psh-consulting.de 
  wrote:
 I will try running this with an debugger later but I have to shift  
 this
 to tomorrow. I will than give you an update.


 Have you tried doing a clean checkout to a different directory? You  
 could then copy over your changes and continue work from there.

That will probably fix Heinrich's problem, but it doesn't help me to  
fix the original problem in Fossil...

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] tree checksum does not match

[D. Richard Hipp]

On Dec 15, 2009, at 5:19 PM, Michael wrote:

 I did 'fossil rebuild --repository X'  after I upgraded to

 $ fossil version
 This is fossil version [5bccc5a526] 2009-12-10 02:25:45 UTC


 $ fossil commit
 ...
 New_Version: 20e486405a4e5cbd5d1a65360b0a562e27e3ea1b
 fossil: tree checksum does not match repository after commit
 $


I'm looking at the code and it should have printed the two non- 
matching checksums after the word commit above.  Did it not?  Did it  
segfault? Are you able to run in a debugger to see what is going on?


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] tree checksum does not match

[D. Richard Hipp]

On Dec 15, 2009, at 6:42 PM, D. Richard Hipp wrote:


 On Dec 15, 2009, at 5:19 PM, Michael wrote:

 I did 'fossil rebuild --repository X'  after I upgraded to

 $ fossil version
 This is fossil version [5bccc5a526] 2009-12-10 02:25:45 UTC


 $ fossil commit
 ...
 New_Version: 20e486405a4e5cbd5d1a65360b0a562e27e3ea1b
 fossil: tree checksum does not match repository after commit
 $


 I'm looking at the code and it should have printed the two non-
 matching checksums after the word commit above.  Did it not?  Did it
 segfault? Are you able to run in a debugger to see what is going on?


I was looking at the wrong section of code.  Sorry.  I withdraw the  
question.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] tree checksum does not match

[D. Richard Hipp]

On Dec 15, 2009, at 7:02 PM, Michael McDaniel wrote:

 On Tue, Dec 15, 2009 at 06:58:02PM -0500, D. Richard Hipp wrote:
 What does fossil status show you?

 D. Richard Hipp
 d...@hwaci.com

 _

 repository:   /home/fossil/repositories/putitgetit.fossil.private
 local-root:   /home/erl/putitgetit/
 server-code:  0e50280d536c31b94362470841e606e9658d8797
 checkout: e9aff5b32f740a0ee838a589803fa565fe164013 2009-12-15  
 02:19:03 UTC
 parent:   da646056826e22ccab9a020ee5576f76267b4bc6 2009-12-14  
 00:41:04 UTC
 tags: trunk

 ...


 The ... is a list of 249 items, 236 DELETED,  14 EDITED.


Can you send me your repository and a tarball of your checkout via  
private email so that I can try to reproduce the problem here?

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] default repo logo image

[D. Richard Hipp]

On Dec 14, 2009, at 9:46 AM, Stephan Beal wrote:

 Hi, all!

 i'm currently editing a repo on a netbook and i noticed three things:

 a) The default (and very attractive) skeleton lizard icon takes up  
 way too much space on a netbook screen. i'm losing a good 30-50  
 pixels, which is a lot on a netbook.

 b) i can find no way of disabling the logo, only replacing it (and i  
 have no images in my repo, so this doesn't help me).

 c) All of my repos now have the same logo, which would seem to imply  
 that my projects are somehow related to the fossil project (or to  
 each other). i.e. fossil's brand identity is probably hurt, not  
 helped, by having all fossil repos use this image by default.


 Is there a way to get rid of the logo without having to add a small/ 
 placeholder image in its place?


Edit the header and comment out the logo.

I agree that there ought to be an easier way

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Commit failing... retyping commit message

[D. Richard Hipp]

On Dec 11, 2009, at 10:51 AM, Stephan Beal wrote:

 On Fri, Dec 11, 2009 at 2:11 PM, Jeremy Cowgar jer...@cowgar.com  
 wrote:
 I thought he was working on a method of my #1 item, i.e. saving the  
 commit message when a commit had failed. I didn't think he was  
 working on anything in regards to #2... loading the commit message  
 from a file.

 (I'm also waiting :-D)

 Here it is:

 http://www.fossil-scm.org/index.html/vinfo/9517cc7486cb68df5de66ae7000337ea2d718574



I think you busted my prior check-in 
http://www.fossil-scm.org/index.html/vinfo/68bfc1d5ccf9

The comment text is no longer preserved if the commit aborts.  I  
didn't actually test this, I'm just looking at the code.  But it  
appears that the comment text is only preserved if the comment is an  
empty string - not very useful.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] When did the Check-in page change ?

[D. Richard Hipp]

On Dec 11, 2009, at 10:58 AM, verizon wrote:

   I have various versions of fossil around and I see in the  
 2009-02-13 20:30 version the Check-in page shows File Changes  
 section where the changed files are listed and you have to click  
 them to view the diffs and history.  In the 2009-11-23 22:14 version  
 that section is now labeled Changes and shows the diff of each file.

   I went through the timeline on the fossil-scm.org site  between  
 those two times and I cannot seem to find where the page changed.   
 I  really like the old behavior and would like build my own version  
 that does that.  I want this because I am working on OS X under  
 XCode and include my project as part of the check-in.  This  
 generates a huge number of diff lines and clutters the check-in  
 page, I don't want to exclude the project but don't really want to  
 see its diffs.

   Where might that change be found ?

   --jim schimpf

Perhaps here:  http://www.fossil-scm.org/index.html/info/713b8be852



 ___
 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...@hwaci.com



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

Re: [fossil-users] Commit failing... retyping commit message

[D. Richard Hipp]

On Dec 9, 2009, at 12:39 PM, Jeremy Cowgar wrote:

 In the 3 features... thread, I read from Michael:

  Secondly, I always get bit with my commit failing and then
 having to type in my comment again (after the monkeying around
 with 'fossil rm'). 

 It seems that fossil is in need of two things:

 1. Save the commit message to a file when the commit failed
 2. Provide a means of making fossil read the commit message from a  
 file

It seems to me that a better approach would be to improve the commit  
command so that it does a better job of detecting problems *before* it  
asks you to type in the commit message.  In other words, if the commit  
is going to fail, have it fail early.

What is it that is causing your commits to fail so frequently?  What  
can we do to get fossil to detect these problems before you type in  
your commit message?



 i.e.

 $ fossil commit
 (enter your message in the editor that was loaded)
 ... ERROR ...
 ... Your commit message was saved to fossil-commit.a493bd8 ...
 $ # fix error
 $ fossil commit -cf fossil-commit.a493bd8
 ... SUCCESS ...

 This would also make it easier to integrate into various editors/ 
 IDEs, i.e. being able to ask a commit message, save it to a file  
 then call the appropriate fossil command.

 Jeremy

 ___
 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...@hwaci.com



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

Re: [fossil-users] File List via the Files Menu... Listing old files?

[D. Richard Hipp]

On Dec 8, 2009, at 10:19 AM, Stephan Beal wrote:

 On Tue, Dec 8, 2009 at 4:15 PM, Jeremy Cowgar jer...@cowgar.com  
 wrote:
  If you want the Files button on the main menu to only show currently
  existing files, simply change the link to be
 
   /dir?ci=trunk

 I think I will do that. To me it's more likely that someone will  
 browse the Files link thinking it is the current files list. If  
 they want a legacy file, they can always update to the revision they  
 wish to work with.

 i think it would make sense to mark files which aren't in the  
 currently-browsed version, such as rendering them like [foo.c] or  
 (foo.c) or simply *foo.c. When browsing an old version, we don't  
 really want to see files which weren't in that version. That implies  
 that we should mark old files using one convention and future  
 files using another, e.g. [foo.c] for old and (foo.c) for exists-in- 
 the-future.



How does Fossil know what the currently-browsed version is?

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] RSS times off?

[D. Richard Hipp]

On Dec 8, 2009, at 1:12 PM, Jeremy Cowgar wrote:

 The two listed in the timeframe are 17:20 and 17:10 but in the rss  
 feed those two same items are 21:20 and 22:10. The 17:20 and 17:10  
 are correct. Now, their are two problems with the RSS feed. It seems  
 like it's converting again to GMT and secondly, somehow one item is  
 ahead 1 hour.

 Any thoughts on this?


My first thought is this:  Shame on the designers of RSS for using  
archaic and obtuse rfc822 localtime dates instead of ISO8601 UTC  
dates!  What were they thinking?

I checked a simplification to the RSS code.  Why not try it and see if  
it works any better for you.



D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] feature proposal for anonymous login

[D. Richard Hipp]

On Dec 7, 2009, at 2:48 PM, Zed A. Shaw wrote:

 On Mon, Dec 07, 2009 at 08:33:12PM +0100, Stephan Beal wrote:
 Hi, all!

 i've just added a feature which is highly arguable and therefore i  
 want to
 check the general opinion on the topic before i commit it:

 When logging in as the anonymous user, it is painful to not be able  
 to
 copy/paste the captcha into the login field. In my experience a  
 simple

 I'd say no, I wouldn't want this feature is it makes bots trivial to
 implement.  The point of a captcha is to make it slightly painful, and
 since this is a tool designed for developers I don't see much of a
 problem with the current captcha.

 However, if it were an optional setting then there'd be nothing wrong
 with it being there.  Those who need simpler user input could turn it
 on, and those who need more spam/bot blocking can turn it off.


I was going to suggest the same thing, but Zed beat me to it

Another thing that would be really cool:  Add a feature to the Setup  
menu that gives the administrator a choice of several skins for  
Fossil using a single button click.  Leave the current look as the  
default, but make the wonderinghorse.net skin one of the preferred  
options.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Autosync hangs

[D. Richard Hipp]

On Nov 13, 2009, at 7:30 AM, Barry Kauler wrote:

 Continuing from my previous post:

 Continuing from before, I attempted a second time, this time the
 Internet connection is good:

 # fossil commit -m added file PKGS_MANAGEMENT --nosign
 Autosync:  http://bkhome.org/fossil/woof.cgi
Bytes  Cards  Artifacts Deltas
 Send: 130  1  0  0
 Received: 230  5  0  0
 Total network traffic: 323 bytes sent, 466 bytes received
 fossil: nothing has changed

 I found that file PKGS_MANAGEMENT was not added to the repository, so
 the failed 'commit' had also cleared the 'add'.

There are two autosyncs on a commit.  The first autosync is really  
just a pull. It checks to see if somebody else has already committed  
changes against the same version you are committing against and hence  
that you are about to fork.  If the first autosync fails, the commit  
does not occur.  It really shouldn't cancel your add (that seems  
like a bug) but at the same time, information you have previously  
committed should remain intact.

The second autosync is a push that sends the newly committed content  
back up to the remote repository.  The second autosync occurs after  
the commit was successful and so if the second autosync fails, it  
should be sufficient to simply rerun sync to push the contents again.



 So I had to do the whole thing again, and this time it worked:

 # fossil add PKGS_MANAGEMENT
 ADDED  PKGS_MANAGEMENT
 # fossil commit -m added file PKGS_MANAGEMENT --nosign
 Autosync:  http://bkhome.org/fossil/woof.cgi
Bytes  Cards  Artifacts Deltas
 Send: 130  1  0  0
 Received: 230  5  0  0
 Total network traffic: 322 bytes sent, 466 bytes received
 New_Version: 8db611a1f647f81834a5df1b7a59959c80a25f5a
 Autosync:  http://bkhome.org/fossil/woof.cgi
Bytes  Cards  Artifacts Deltas
 Send:8663  9  2  0
 Received: 322  7  0  0
 Total network traffic: 4649 bytes sent, 514 bytes received

 Regards,
 Barry Kauler


 On 11/13/09, Barry Kauler bkau...@gmail.com wrote:
 Hi guys,
 I'm enjoying playing with Fossil, but I've run into a problem...

 I have a satellite Internet connection. Apart from the incredible
 latency (over 1 second, testing with ping), my connection freezes
 every now and again.

 This freezing problem has something to do with communication with
 the satellite, so it's not just my system. What happens is that the
 Internet is dead for awhile, maybe a minute, maybe longer.

 Anyway, I did a 'fossil commit' just as one of these freezes
 occurred, and I got this:

 # fossil commit -m added file PKGS_MANAGEMENT --nosign
 Autosync:  http://bkhome.org/fossil/woof.cgi
Bytes  Cards  Artifacts Deltas
 Send: 130  1  0  0

 The freeze was temporary, a matter of seconds later the Internet was
 working again. However the 'fossil commit' operation was hung.

 I had to do a CTRL-C to terminate it.

 My question: Fossil should not be assuming a perfect Internet
 connection should it? Shouldn't a push (or pull) have a timeout, and
 maybe a retry? Just to hang is not very good.

 Then there's the question, as I had to terminate it with a CTRL-C, is
 there any kind of assurance that what did arrive at the remote
 repository, if anything, is not partial and thus corrupted?

 If I use a program like wget, it does have fallback code to handle
 this kind of situation.

 Regards,
 Barry Kauler

 ___
 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...@hwaci.com



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

Re: [fossil-users] Autosync hangs

[D. Richard Hipp]

On Nov 13, 2009, at 6:19 PM, Barry Kauler wrote:

 You have mentioned about possible schema changes in the database in a
 later version of Fossil. Ok, I have my online repository. If someone
 installs Fossil by downloading your latest binary executable, and then
 clones my repository, isn't there a potential problem, if I have been
 working with an older Fossil executable?



When I said schema changes I was referring to the auxiliary schema  
that holds repository metadata in an easily accessible format.  To put  
it another way, I meant the schema that holds derived data ithat is  
precomputed from the canonical artifacts for speedy access.  The  
content of the database with this schema can *always* be recomputed  
simply by rescanning all of the underlying immutable artifacts.

Call it the secondary schema if you will

The secondary schema does change from time to time.  When it does and  
you upgrade to the latest version of Fossil, simply run fossil all  
rebuild and the repositories will be updated with the new schema.

The underlying, canonical artifact representation of the repository  
does not change, however.  It is has been and always will be the same  
(or at least backwards compatible).  The same goes for the wire  
protocol.  Two different versions of Fossil, with different secondary  
schemas, can still sync against each other.  They don't even know what  
secondary schema the other end is running.  Really all they do is  
exchange artifacts until they both have the same set of artifacts,  
then they each independently recomputed the derived data for the  
secondary schema from those canonical artifacts.

Fossil is designed in such a way that someone could decide to  
reimplement the whole thing from scratch using a different technology  
and the new Fossil would be able to synchronize with the old.  (There  
are some people who have been threatening to reimplement Fossil using  
Tcl/Tk, for example, but no results on that front yet, at least not  
that I've heard of.)

For that matter, there is nothing in the artifact format or wire  
protocol of Fossil the requires the use of SQLite, or any other SQL  
database engine, as the repository format.  You could reimplement  
Fossil using a pile-of-files database (after the fashion of Git or Hg)  
if you wanted to and make it so that it was 100% compatible with the  
current SQLite-based Fossil.


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] push and sync not working

[D. Richard Hipp]

On Nov 11, 2009, at 9:29 AM, paolo lulli wrote:

 Then, I try to:

 fossil push  http://lulli.net/code/index.cgi

 and get:

 via proxy: http://localhost:3128
Bytes  Cards  Artifacts Deltas
 Send:  90  1  0  0
 Received:   0  1  0  0
 Total network traffic: 315 bytes sent, 464 bytes received

 What I get is that local modifications don't get on the server in any
 way, and via the remote GUI I cannot see them.
 What am I missing, then ? May be it a matter of user privileges ?


What does this tell you:

 fossil push http://lulli.net/code/index.cgi --httptrace

The error reporting in fossil for misconfigured network comms needs to  
be improved.  There is already a ticket on that:  
http://www.fossil-scm.org/fossil/tktview?name=bfb8427cdd

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] push and sync not working

[D. Richard Hipp]

On Nov 11, 2009, at 10:42 AM, paolo lulli wrote:

 On the web interface, under Setup/Users, which users have authority  
 to
 clone?  If you want to clone without given a userid and password,  
 then
 nobody needs clone privilege.  Otherwise, give a userid and  
 password
 on the URL when cloning:

 Ok, I've just given 'nobody' the right to clone; it seems now that the
 error before disappear. But I continue to see  project-id: (null)

 I'm sorry for annoying you about this, but once again: what do I  
 miss ?


If you will recompile your fossil.exe using the latest sources on the  
website, I just checked in changes to give better error messages.   
That might help.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] push and sync not working

[D. Richard Hipp]

On Nov 11, 2009, at 10:54 AM, paolo lulli wrote:

 If you will recompile your fossil.exe using the latest sources on the
 website, I just checked in changes to give better error messages.
 That might help.

 I'm doing this later in the evening, as I have no access via ssh to
 the remote site from here.



Can you not simply clone the fossil source repository?

 fossil clone http://www.fossil-scm.org/fossil

Or failing that, visit the website:

 
http://www.fossil-scm.org/fossil/vinfo/0690aa18a4aa3dfb6f055d486d278590f715a2cc

And click on the ZIP Archive link to download a ZIP archive  
containing all the latest source code?

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Newbie getting starting issues, plus 'add' question

[D. Richard Hipp]

On Nov 11, 2009, at 4:06 PM, Barry Kauler wrote:
 I too have just started with Fossil.

Barry Kauler, the Puppy Linux guy?  Welcome.


 One thing I did that might make the Fossil people cringe, is I created
 an empty repository locally (fossil new woof.fossil) then I uploaded
 it to my website by ftp. I reasoned that as it is empty, that wouldn't
 matter.

Actually, there nothing wrong with ftp-ing or scp-ing repositories  
between machines.  Set up a new project locally because it convenient  
to do so there (using fossil ui) then scp or ftp it to the  
destination (after setting up the privileges like you want.)  Works  
fine.

Beware of sending repositories to other people, though.  Remember that  
each repository database also contains sensitive information such as  
your passwords and email address, etc.  If you want to email a project  
repository to someone, it is best to first run:

  fossil scrub  WHATEVER.fossil

The scrub command will remove passwords from the database.  Add the  
--verily option to remove less sensitive things like email addresses.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] HTTPS implementation (update)

[D. Richard Hipp]

On Nov 9, 2009, at 10:16 AM, Dmitry Chestnykh wrote:

 What is the consensus on including this into Fossil? Should I push
 changes
 into main repository?


I'd like to see you push the changes - at least into a branch.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] cannot pull

[D. Richard Hipp]

On Nov 5, 2009, at 9:11 PM, Doug Currie wrote:

 fossil: table event has no column named tagid
 REPLACE INTO event(type,tagid,mtime,objid,user,comment,brief)VALUES
 ('t',263,2455096.863576389,5207,'anonymous','New ticket [3f0c73f2d2]
 idiff-command with parameter doesn''t work/i.','New ticket
 [3f0c73f2d2].')


You must have upgraded to a new version of fossil recently (or at  
least since the last time you did a pull on that repository).   
Sometimes the internal schema changes.  So whenever you upgrade, it is  
a good idea to run:

 fossil all rebuild

That command will reconstruct all your repositories based on the  
original artifacts and should fix the problem.


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] cannot pull

[D. Richard Hipp]

On Nov 5, 2009, at 9:27 PM, Doug Currie wrote:
  Perhaps
 fossil could detect the schema error and ask if I meant to fossil all
 rebuild?


That sounds like the right thing to do


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] HTTPS implementation

[D. Richard Hipp]

On Nov 4, 2009, at 6:03 PM, Dmitry Chestnykh wrote:


 Both DRH and I looked at the OpenSSL client-side code and decided it
 was going to be too much of a hassle to integrate.

 You mean, the requirement of libssl to be present on users' computers?


Not so much that as just getting libssl to work.  I spend a couple of  
days messing with it and never could get it to do right.

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] external links

[D. Richard Hipp]

On Nov 2, 2009, at 3:05 AM, altufa...@mail.com wrote:

 Hi DRH,

 Check-in [0039b7813e] shows a rectangle next to external links in IE  
 and chrome. Is that intentional? I expected to see some other shape.



OK.  Good to know.  I figured that all browsers these days could  
handle unicode, but apparently IE and Chrome cannot.  I'll take this  
back out for now.

I suppose I should also back out the similar change at 
http://www.sqlite.org/draft/index.html


D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] external links

[D. Richard Hipp]

On Nov 2, 2009, at 7:54 AM, Joshua Paine wrote:

 On Mon, 2009-11-02 at 11:17 +, James Gruessing wrote:
 I agree with that idea, but for people wanting to replicate the arrow
 or having something similar as prefix or suffix to the link would  
 mean
 most likely resorting to using the content CSS attribute

 Adding some left or right padding and a background image (aligned left
 or right) works pretty well.

An image does not change color according to whether or not the link  
has been visited.  :-(

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] external links

[D. Richard Hipp]

On Nov 2, 2009, at 8:20 AM, Michael Richter wrote:

 Are you kidding Richard?  Unicode is only 8 years old as a  
 standard.  It'll be at least another 20 before people finally get it  
 (semi-)right.



When I bring up IE (using VMWare) I see that the = symbol in the last  
two rows of the table at 
http://www.sqlite.org/draft/fileformat2.html#serialtype 
  works correctly but that the check-mark symbols at 
http://www.sqlite.org/draft/fileformat2.html#cellformat 
  do not work.

So I guess the rule is, always try out your HTML on IE to see what  
does and does not work

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] conflict resolution in practice?

[D. Richard Hipp]

On Oct 25, 2009, at 8:34 PM, Zed A. Shaw wrote:

 On Sun, Oct 25, 2009 at 07:20:16PM -0400, D. Richard Hipp wrote:

 On Oct 25, 2009, at 2:27 PM, Zed A. Shaw wrote:

 Currently, the behavior is that fossil overwrites files without any
 prompting using the latest one wins method.

 It shouldn't be doing that!  Can you give me an example so that I can
 track down the problem?

 Ah, I will try to track this down then.  Now just to be clear, do you
 mean that if I have uncommitted edits to a file, and fossil has edits
 that conflict, that fossil SHOULD prompt me before merging?  Or, do  
 you
 mean that it will merge and then I can use undo to get my stuff back?


The latter.  It will merge.  You can undo if you don't like the result.



 Update already does make backups.  If you do fossil update and  
 don't
 like the results, just type fossil undo and everything should  
 revert
 to the state it was in before the update.

 Yes!  I knew there had to be a little command I was missing.  Awesome,
 I'll let my peoples know.

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

D. Richard Hipp
d...@hwaci.com



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

Re: [fossil-users] Committing a subdirectory

[D. Richard Hipp]

On Oct 24, 2009, at 10:57 AM, Nick B wrote:

 I have a number of modified files but I would like to commit only a
 few files in a single subdirectory.

 Typing fossil changes returns
 snip list of EDITED files
 MISSING  brightside/images/bg.gif
 EDITED   brightside/images/headerbg.gif
 EDITED   brightside/images/tableft.gif
 EDITED   brightside/images/tabright.gif

 In the parent directory if I enter:
 fossil commit images or fossil commit images/ returns
 fossil: fossil knows nothing about: images/

 Similarly if I use:

 fossil commit images/* returns
 fossil: fossil knows nothing about: images/bg.gif.old

 In this case the file bg.gif.old can be safely ignored as I only want
 to commit edited files.

 What command do I use to commit the subdirectory images?

There is no command to commit a subdirectory.  You can commit  
individual files by naming them on the commit command-line, but there  
is no shorthand for specifying all the files in a subdirectory.

In your case, it might work to do:

 fossil commit images/*.gif

since the .gif suffix will omit the .old file.  But there is no  
general solution at this time.

You are welcomed to contribute one :-)



 Thanks
 ___
 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...@hwaci.com



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