Re: [fossil-users] problems with links in embedded documents

[Michal Suchanek]

On 23 November 2015 at 22:59, Ron W  wrote:
>
>
> On Mon, Nov 23, 2015 at 2:19 PM, Richard Hipp  wrote:
>>
>> That's all well and good, but Joerg is right - it would be convenient
>> to be able to specify the root of the repository in a hyperlink.  I've
>> pondered making that possible with some bit of magic like
>> "[$ROOT/wcontent]" or "".  But it seems
>> hackish.
>
>
> Why not use the  tag in the generated HTML?
>

Last time I tried using  it did not work out very well. Do you
have some idea what is browser support for this tag like? Especially
restricted and terminal-based browsers might be interesting.

More importantly, you might not know what the base is if you are
behind CGI. And the base might become invalid when you save the
generated HTML.

The most reliable thing would be to automagically generate enough ../
so the link points to the root of the repo, and the fossil service
knows what URL it was called by so it can generate those ../ just
fine. Anything else is asking for trouble imho.

This was my major grief with fossil web as well so I gave up on using
it since cross-linking between wiki and source becomes pretty much
impossible.

Thanks

Michal
___
fossil-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 links in embedded documents

[Richard Hipp]

On 11/23/15, Warren Young  wrote:
>
> I was curious, so I looked into it.  The Fossil docs only talk about nginx,
> but I’m more familiar with name-based virtual hosting on Apache, so I worked
> out how to configure it:

That's all well and good, but Joerg is right - it would be convenient
to be able to specify the root of the repository in a hyperlink.  I've
pondered making that possible with some bit of magic like
"[$ROOT/wcontent]" or "".  But it seems
hackish.

>
> NameVirtualHost prj1.yourcompany.private:80
> 
> ServerAdmin webmaster@yourcompany.private
> ServerName prj1
> ServerAlias prj1
> ProxyPass / scgi://localhost:4000/
> SetEnvIf Request_URI . proxy-scgi-pathinfo
> 
>
> Then, set up the back-end server via:
>
> $ fossil server /path/to/prj1.fossil --scgi --localhost --port 4000 &
>
> Having done this, visiting http://prj1 will transparently show the Fossil UI
> for prj1.fossil.
>
> The point of this scheme is that you can run one fossil instance for each
> repository you want to serve, using a different SCGI port number for each,
> mapping each SCGI port to an alias on your web server.  Each of those
> name-based virtual hosts will present the corresponding Fossil UI at the
> root of the URL hierarchy, so you won’t run into local/remote discrepancies
> like the one you found.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] problems with links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 20:19:28 +0100, Richard Hipp  wrote:


That's all well and good, but Joerg is right - it would be convenient
to be able to specify the root of the repository in a hyperlink.  I've
pondered making that possible with some bit of magic like
"[$ROOT/wcontent]" or "".  But it seems
hackish.


could you elaborate on that? it's not currently an option to do something  
like that, right? if it would be implemented I would think this to be  
rather more natural than the currently necessary `../../../wcontent' when  
linking from some embedded doc in `repo-root/www' which requires knowledge  
of the `/doc/trunk' "mount point" as well in order to get it right.



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-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 links in embedded documents

[Warren Young]

On Nov 23, 2015, at 9:42 AM, j. van den hoff  wrote:
> 
>> You could still serve multiple Fossil repositories via your web server’s 
>> name-based virtual hosting feature
> 
> I will have to look into this, thank you for this tip.

I was curious, so I looked into it.  The Fossil docs only talk about nginx, but 
I’m more familiar with name-based virtual hosting on Apache, so I worked out 
how to configure it:

NameVirtualHost prj1.yourcompany.private:80

ServerAdmin webmaster@yourcompany.private
ServerName prj1
ServerAlias prj1
ProxyPass / scgi://localhost:4000/
SetEnvIf Request_URI . proxy-scgi-pathinfo


Then, set up the back-end server via:

$ fossil server /path/to/prj1.fossil --scgi --localhost --port 4000 & 

Having done this, visiting http://prj1 will transparently show the Fossil UI 
for prj1.fossil.

The point of this scheme is that you can run one fossil instance for each 
repository you want to serve, using a different SCGI port number for each, 
mapping each SCGI port to an alias on your web server.  Each of those 
name-based virtual hosts will present the corresponding Fossil UI at the root 
of the URL hierarchy, so you won’t run into local/remote discrepancies like the 
one you found.
___
fossil-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 links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 20:13:40 +0100, Warren Young  wrote:

On Nov 23, 2015, at 9:42 AM, j. van den hoff   
wrote:


You could still serve multiple Fossil repositories via your web  
server’s name-based virtual hosting feature


I will have to look into this, thank you for this tip.


I was curious, so I looked into it.  The Fossil docs only talk about  
nginx, but I’m more familiar with name-based virtual hosting on Apache,  
so I worked out how to configure it:


NameVirtualHost prj1.yourcompany.private:80

ServerAdmin webmaster@yourcompany.private
ServerName prj1
ServerAlias prj1
ProxyPass / scgi://localhost:4000/
SetEnvIf Request_URI . proxy-scgi-pathinfo


Then, set up the back-end server via:

$ fossil server /path/to/prj1.fossil --scgi --localhost --port 4000 &

Having done this, visiting http://prj1 will transparently show the  
Fossil UI for prj1.fossil.


The point of this scheme is that you can run one fossil instance for  
each repository you want to serve, using a different SCGI port number  
for each, mapping each SCGI port to an alias on your web server.  Each  
of those name-based virtual hosts will present the corresponding Fossil  
UI at the root of the URL hierarchy, so you won’t run into local/remote  
discrepancies like the one you found.


will put this on the "things to investigate stack", thank you.

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-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 links in embedded documents

[Ron W]

On Mon, Nov 23, 2015 at 2:19 PM, Richard Hipp  wrote:
>
> That's all well and good, but Joerg is right - it would be convenient
> to be able to specify the root of the repository in a hyperlink.  I've
> pondered making that possible with some bit of magic like
> "[$ROOT/wcontent]" or "".  But it seems
> hackish.
>

Why not use the  tag in the generated HTML?
___
fossil-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 links in embedded documents

[Andy Bradford]

Thus said Warren Young on Mon, 23 Nov 2015 14:43:53 -0700:

> Yes.  It already  has a  legal meaning,  at least  on POSIX-based  web
> servers. Basically, multiple  slashes are suppressed, so  that you can
> do things like:

In some  parts of Fossil, //  has a different  meaning than / in  a URL.
Specifically,  it's  the  difference  between an  absolute  path  and  a
relative path when cloning. E.g.,

The following  will clone  relative to  the user  home directory,  so it
results in the server looking for a file named /home/user/repo.fossil:

fossil clone ssh://user@server/repo.fossil

The  following will  clone  with an  absolute path  beginning  at /  and
looking for exactly /repo.fossil in the filesystem:

fossil clone ssh://server//repo.fossil

Andy
-- 
TAI64 timestamp: 40005653db1a


___
fossil-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 links in embedded documents

[Warren Young]

On Nov 22, 2015, at 6:47 AM, j. van den hoff  wrote:
> 
> my (obviously
> wrong/incomplete understanding so far is that `/wcontent' is an absolute
> path relative to the repository root…

I think the problem is that you’re serving a collection of Fossils, instead of 
just one.

I don’t use the CGI model, but with “fossil server /path/to/one.fossil” the 
URLs are of the form http://server.ip:port/wcontent.

The difference with the “local” case is that “fossil ui” is only serving a 
single Fossil repo.

So, bottom line, you need to either use relative URLs, or remove this 
confounding difference between the local and CGI cases, serving only one repo 
per Fossil server.

You could still serve multiple Fossil repositories via your web server’s 
name-based virtual hosting feature, so that http://prj1.mycompany.private maps 
to prj1.fossil, and so on for prj2, etc.

> hitting the
> `/wcontent' link on the server GUI does not simply just not work with
> error 404 or something like that but rather navigates to the home page of
> another unrelated fossil cgi repository residing in the same directory on
> the server. what's going on here?

That sounds like a CGI-specific behavior.  We use “fossil server /museum” 
(where /museum is where the Fossils live) here, and http://server:port/wcontent 
*does* give a 404.
___
fossil-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 links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 16:10:02 +0100, Warren Young  wrote:

On Nov 22, 2015, at 6:47 AM, j. van den hoff   
wrote:


my (obviously
wrong/incomplete understanding so far is that `/wcontent' is an absolute
path relative to the repository root…


I think the problem is that you’re serving a collection of Fossils,  
instead of just one.


yes, that's quite probably true, but I'm not sure whether its a "natural"
problem or might be something calling for a fix...



I don’t use the CGI model, but with “fossil server /path/to/one.fossil”  
the URLs are of the form http://server.ip:port/wcontent.


The difference with the “local” case is that “fossil ui” is only serving  
a single Fossil repo.


So, bottom line, you need to either use relative URLs, or remove this  
confounding difference between the local and CGI cases, serving only one  
repo per Fossil server.


this is not really an option, at least not desirable: its much easier to  
administrate when putting all the repositories into a common directory  
following the procedure recommended for that in the Fossil documentation.


I still wonder, whether the observed behavior is to be expected and/or  
unavoidable in my setup, maybe you or someone else could help me  
understand the situation further/better:


* is it "obvious" that `/wcontent' will point to  
`https://server.domain/wcontent' for a cgi-served repo?
  ** if so could this not be changed, since one ends up with the link  
`/wcontent' working correctly locally (in the clone) but not on the server


* what causes the weird "redirection" I see when using something like  
`/wcontent' as a link, namely the switch to a different repo residing in  
the same cgi-served directory on the server?




You could still serve multiple Fossil repositories via your web server’s  
name-based virtual hosting feature, so that  
http://prj1.mycompany.private maps to prj1.fossil, and so on for prj2,  
etc.


I will have to look into this, thank you for this tip.




hitting the
`/wcontent' link on the server GUI does not simply just not work with
error 404 or something like that but rather navigates to the home page  
of
another unrelated fossil cgi repository residing in the same directory  
on

the server. what's going on here?


That sounds like a CGI-specific behavior.  We use “fossil server  
/museum” (where /museum is where the Fossils live) here, and  
http://server:port/wcontent *does* give a 404.

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



--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-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 links in embedded documents

[Richard Hipp]

On 11/23/15, j. van den hoff  wrote:
> On Mon, 23 Nov 2015 20:19:28 +0100, Richard Hipp  wrote:
>
>> That's all well and good, but Joerg is right - it would be convenient
>> to be able to specify the root of the repository in a hyperlink.  I've
>> pondered making that possible with some bit of magic like
>> "[$ROOT/wcontent]" or "".  But it seems
>> hackish.
>
> could you elaborate on that? it's not currently an option to do something
> like that, right? if it would be implemented I would think this to be
> rather more natural than the currently necessary `../../../wcontent' when
> linking from some embedded doc in `repo-root/www' which requires knowledge
>
> of the `/doc/trunk' "mount point" as well in order to get it right.
>

What should the magic symbol be?  Some ideas:

FOSSIL_ROOT
$
THIS
THIS_REPO

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] problems with links in embedded documents

[j. van den hoff]

On Mon, 23 Nov 2015 22:04:07 +0100, Richard Hipp  wrote:


On 11/23/15, j. van den hoff  wrote:

On Mon, 23 Nov 2015 20:19:28 +0100, Richard Hipp  wrote:


That's all well and good, but Joerg is right - it would be convenient
to be able to specify the root of the repository in a hyperlink.  I've
pondered making that possible with some bit of magic like
"[$ROOT/wcontent]" or "".  But it seems
hackish.


could you elaborate on that? it's not currently an option to do  
something

like that, right? if it would be implemented I would think this to be
rather more natural than the currently necessary `../../../wcontent'  
when
linking from some embedded doc in `repo-root/www' which requires  
knowledge


of the `/doc/trunk' "mount point" as well in order to get it right.



What should the magic symbol be?  Some ideas:

FOSSIL_ROOT
$
THIS
THIS_REPO


from these, I would choose FOSSIL_ROOT. spontaneous idea: would a single  
slash be out of the question, so that the link relative to repo-root would  
read


//wcontent


or similar?





--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-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 links in embedded documents

[Richard Hipp]

On 11/23/15, j. van den hoff  wrote:
>>
>> What should the magic symbol be?  Some ideas:
>>
>> FOSSIL_ROOT
>> $
>> THIS
>> THIS_REPO
>
>  from these, I would choose FOSSIL_ROOT. spontaneous idea: would a single
> slash be out of the question, so that the link relative to repo-root would
>
> read
>
> //wcontent
>
>
> or similar?

Dunno.  I'm open to suggestions.  Further input is requested.

I'm a little detached from this right this moment as I have multiple
balls in the air.  But if the community can reach a consensus on what
should happen, I'll write the code.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] problems with links in embedded documents

[Warren Young]

On Nov 23, 2015, at 2:09 PM, j. van den hoff  wrote:
> 
> from these, I would choose FOSSIL_ROOT.

I like “THIS” better, but maybe that’s just my C++ speaking.

> would a single slash be out of the question

Yes.  It already has a legal meaning, at least on POSIX-based web servers.  
Basically, multiple slashes are suppressed, so that you can do things like:

   string s1(“http://server/“), s2(“/path/to/page”);
   return s1 + s2;

…without adding explicit checks for this case of having both trailing and 
leading slashes.

It’ll also cause problems on Cygwin, since a leading // is interpreted as a UNC 
path.  e.g. //server/share/dir.  I believe I once read they justified that by a 
POSIX rule that said that doubled slashes at the start of the path were allowed 
to have implementation-defined meaning.  I could dig up the reference, if you 
like.

___
fossil-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 links in embedded documents

[Warren Young]

On Nov 23, 2015, at 2:43 PM, Warren Young  wrote:
> 
> It already has a legal meaning, at least on POSIX-based web servers. 

Hmmm…apparently Fossil’s internal web server doesn’t know that rule:

   http://fossil-scm.org/index.html/info//565d1b0a3880421e

gives a 404.

There’s also no rule that says that slashes in URLs *must* obey POSIX.  Some 
URL schemes make odd distinctions.  e.g. 

scp://server/path/to/file.txt
scp://server//home/user/path/to/file.txt

might well point to the same file, since the second URL is taken as an absolute 
path, and the first relative.

The point remains: doubled slashes already have lots of meaning already.  We 
shouldn’t overload the concept still further.
___
fossil-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 /doc/

[Sergey Sfeli]

http://www.fossil-scm.org/fossil/info/c99b4e34dd1db2cc does not fix an
issue 1 completely: http://localhost:8080/doc//index.md still crashes.

___
fossil-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 /doc/

[Richard Hipp]

On 7/15/15, Sergey Sfeli sergey.sf...@gmail.com wrote:
 http://www.fossil-scm.org/fossil/info/c99b4e34dd1db2cc does not fix an
 issue 1 completely: http://localhost:8080/doc//index.md still crashes.


Please try again now.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problems with the tkt-change-hook branch

[Jan Nijtmans]

2013/10/12 Justin Forest h...@umonkey.net:
 Hello.

 I wanted to use the ticket change hooks, and found a problem with the
 current code
.
 I fixed this by replacing the last return TH_OK in submitTicketCmd with
 return TH_RETURN.

Thank you very much! Your fix is committed now:
 http://fossil-scm.org/index.html/info/26d6877ff6

I also renamed the ticket-change script to xfer-ticket-script
script everywhere, as the new xfer script is apparently doing
something completely different from the old ticket-change
script. Next step will be to put the old ticket-change script
back to how it was (I'm not needing it, but someone else might).

Thank you very much for your explanation! I understand the ticket
code better now than I did when I wrote this code ;-)

The tkt-change-hook branch is not tested very much in the field,
it was written to assist the Tcl project in implementing email
hooks, like you are doing. It's not being used there yet, otherwise
I am sure that this redirect bug already would have been found
by someone. Many thanks!

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

Re: [fossil-users] Problems with Fossil 1.26 for Windows

[Richard Hipp]

On Tue, Jun 18, 2013 at 8:05 PM, Richie Adler richiead...@gmail.com wrote:

 Trying to run the Windows version in Windows XP SP3 gives the error Not a
 valid Win32 application.



Ugh.  I compiled it using a VS2012 x86 Native Tools Command Prompt on
Win8.  Anybody have a guess what might have gone wrong?

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problems with Fossil 1.26 for Windows

[og]

Maybe:


Project-Application Properties-Compile

Set Target CPU to *x86*



https://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx?Redirected=true

t+

og


On Tue, Jun 18, 2013 at 9:53 PM, Richard Hipp d...@sqlite.org wrote:



 On Tue, Jun 18, 2013 at 8:05 PM, Richie Adler richiead...@gmail.comwrote:

 Trying to run the Windows version in Windows XP SP3 gives the error Not a
 valid Win32 application.



 Ugh.  I compiled it using a VS2012 x86 Native Tools Command Prompt on
 Win8.  Anybody have a guess what might have gone wrong?

 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


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

Re: [fossil-users] Problems with Fossil 1.26 for Windows

[Richard Hipp]

On Tue, Jun 18, 2013 at 9:25 PM, og ogil...@gmail.com wrote:

 Maybe:


 Project-Application Properties-Compile

 Set Target CPU to *x86*

 The build was done from the *Command Line Prompt* not from a MSVC GUI, so
there is no Project-Application Properties-Compile menu.  If I update to
http://www.fossil-scm.org/fossil/info/340711f48c and recompile in the same
shell, it tells me that sizeof(void*)==4.  So it really does seem to be
building a 32-bit binary.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problems with Fossil 1.26 for Windows

[Edward Berner]

On 6/18/2013 5:53 PM, Richard Hipp wrote:



On Tue, Jun 18, 2013 at 8:05 PM, Richie Adler richiead...@gmail.com 
mailto:richiead...@gmail.com wrote:


Trying to run the Windows version in Windows XP SP3 gives the
error Not a
valid Win32 application.



Ugh.  I compiled it using a VS2012 x86 Native Tools Command Prompt 
on Win8.  Anybody have a guess what might have gone wrong?




It looks like the initial release of Visual Studio 2012 did not support 
targeting XP and that Update 1 added that capability.  The following 
blog article has more information including a raindance for targeting XP 
from the command line.  (Note that I haven't used VS2012 myself.)


Windows XP Targeting with C++ in Visual Studio 2012
http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx

--
Edward Berner

___
fossil-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 renames (patch included)

[Richard Hipp]

2012/2/10 Lluís Batlle i Rossell vi...@viric.name


 So, as I said, the patch solves that situation for us. I hope someone can
 review
 the patch.


A simpler change which accomplishes the same thing has been checked in at

http://www.fossil-scm.org/fossil/ci/f0359882c9?sbs=1

Please let me know if this solves your problem or not.  It seemed to work
for me.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Problems with renames (patch included)

[Lluís Batlle i Rossell]

On Fri, Feb 10, 2012 at 10:32:00AM -0500, Richard Hipp wrote:
 2012/2/10 Lluís Batlle i Rossell vi...@viric.name
 
 
  So, as I said, the patch solves that situation for us. I hope someone can
  review
  the patch.
 
 
 A simpler change which accomplishes the same thing has been checked in at
 
 http://www.fossil-scm.org/fossil/ci/f0359882c9?sbs=1
 
 Please let me know if this solves your problem or not.  It seemed to work
 for me.

I thought of some change like this, and now I can't remember fully why I
refused it... I imagine that I simply couldn't forecast side effects of the
change.

The change works for my case.

As the merge renames tests still work, I can only agree with the change by now
:)

Thank you!
___
fossil-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........

[Oliver Friedrich]

To start with someone must place a note that in windows paths must be 
treated differently (WITHOUT BEEN A 100% SURE)

c:/P/prg1.fossil and not c:\P\prg1.fossil
Your Path should point to fossil.exe not to the repository. On Windows 
Path must not be treated differently, but apparently like the OS needs 
them - and windows divides Paths with \.

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

Re: [fossil-users] problems........

[Mark Janssen]

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

 

 

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

 

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

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

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


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


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

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



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

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

Re: [fossil-users] problems........

[Lluís Batlle i Rossell]

On Mon, Jan 16, 2012 at 05:42:59PM +0200, android devkit wrote:
 Dear all
 I didn’t like to start this email in a negative manner but unfortunately I
 will. I have spent 2 days trying to make fossil run in my windows xp
 machine.

I think troubles like yours are on discussion already. Those involved should
know more.

OTH, I think that some of the binaries published passed the make test, while
others did not. Those who build the binaries may know. I recall something like
the fossil.exe windows binary being cross-built, so maybe it did not pass any
kind of make test.

Regards,
Lluís.
___
fossil-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] Problems with server

[Daniel Carrera]

D. Richard Hipp wrote:
 Why did you change the URL?
 
  fossil clone http://projecs.theingots.org/cgi-bin/awards.cgi  
 awards.fossil

Because that is how I interpreted the documentation. Look:

fossil clone http://www.fossil-scm.org/ myclone.fossil


Do you see a project.cgi anywhere in there? In addition, the space 
between the forward slash and myclone.fossil is hardly visible, so on 
a quick glance it looks like you are giving the path to a file. Yes, if 
I had studied that line very slowly I might have realized that that's 
not what you are doing, but the documentation should be clearer here.

Daniel.
___
fossil-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 proxy settings in client server mode with autosync

[Franz Brummer]

On Nov 9, 2009, at 8:11 AM, Franz wrote:

 Hello,

 this is my first post on this list so please bear with me! ;-)

 I want to set up a central fossil server in our company network. So
 I've created a local repository on my desktop machine, worked there
 for some time and decided it was time to make it public.

 Like it is recommended in the fossil quick start documentation I
 started the fossil server on my desktop and cloned (fossil clone...)
 the repository on the server.

 Setting up the cgi server worked as expected so that I was able to
 browse to the server repository.

 We are behind a proxy server but the access to the fossil server
 should bypass the proxy to work.

 When I make changes on my local repository and commit it says
 Autosync:  with the correct server URL.

Do you get a line that says via proxy: ...?

No, I get the following:

$fossil commit -m 'FOOBAR 3' --proxy off

Autosync:  http://icends.his.de/cgi-bin/fossil-server.cgi
Bytes  Cards  Artifacts Deltas
Send: 130  1  0  0
Received:   0  1  0  0
Total network traffic: 334 bytes sent, 440 bytes received

-- snip PGP snip --

New_Version: d7edf74845e393a3e3ed4328889f06940ddb1d52
Autosync:  http://icends.his.de/cgi-bin/fossil-server.cgi
Bytes  Cards  Artifacts Deltas
Send:   27196 16  1  1
Received:   0  2  0  0
Total network traffic: 7469 bytes sent, 440 bytes received
brum...@his2735:~/Projekte/perl$

Obviously _something_ gets sent over the network.

But when I open the cgi in my webbrowser the timeline is not current.

Is there any way to debug what is happening on the server?

Cheers
Franz

-- 
 Jesus Edits! Cool.
And he saves!
The real argument is whether Jesus saves using :w or C-x-C-s
___
fossil-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 proxy settings in client server mode with autosync

[Franz Brummer]

Sorry for the useless traffic. I've found out what my problem was. I
had the wrong name for the cgi script in the URL of some previous push
or sync action and didn't recognize that I should have specified the
right URL once more. Now it works!

But anyway I had to look in the apache logs on the server to find it
out. Maybe the client should warn about such errors as well to make it
easier to recognize for the client user?

Cheers
Franz

2009/11/10 Franz Brummer fbrum...@gmail.com:
On Nov 9, 2009, at 8:11 AM, Franz wrote:

 Hello,

 this is my first post on this list so please bear with me! ;-)

 I want to set up a central fossil server in our company network. So
 I've created a local repository on my desktop machine, worked there
 for some time and decided it was time to make it public.

 Like it is recommended in the fossil quick start documentation I
 started the fossil server on my desktop and cloned (fossil clone...)
 the repository on the server.

 Setting up the cgi server worked as expected so that I was able to
 browse to the server repository.

 We are behind a proxy server but the access to the fossil server
 should bypass the proxy to work.

 When I make changes on my local repository and commit it says
 Autosync:  with the correct server URL.

Do you get a line that says via proxy: ...?

 No, I get the following:

 $fossil commit -m 'FOOBAR 3' --proxy off

 Autosync:  http://icends.his.de/cgi-bin/fossil-server.cgi
                Bytes      Cards  Artifacts     Deltas
 Send:             130          1          0          0
 Received:           0          1          0          0
 Total network traffic: 334 bytes sent, 440 bytes received

 -- snip PGP snip --

 New_Version: d7edf74845e393a3e3ed4328889f06940ddb1d52
 Autosync:  http://icends.his.de/cgi-bin/fossil-server.cgi
                Bytes      Cards  Artifacts     Deltas
 Send:           27196         16          1          1
 Received:           0          2          0          0
 Total network traffic: 7469 bytes sent, 440 bytes received
 brum...@his2735:~/Projekte/perl$

 Obviously _something_ gets sent over the network.

 But when I open the cgi in my webbrowser the timeline is not current.

 Is there any way to debug what is happening on the server?

 Cheers
 Franz

 --
 Jesus Edits! Cool.
 And he saves!
 The real argument is whether Jesus saves using :w or C-x-C-s




-- 
 Jesus Edits! Cool.
And he saves!
The real argument is whether Jesus saves using :w or C-x-C-s
___
fossil-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 proxy settings in client server mode with autosync

[Dmitry Chestnykh]

On 10.11.2009, at 16:14, Franz Brummer wrote:

 Sorry for the useless traffic. I've found out what my problem was. I
 had the wrong name for the cgi script in the URL of some previous push
 or sync action and didn't recognize that I should have specified the
 right URL once more. Now it works!
 
 But anyway I had to look in the apache logs on the server to find it
 out. Maybe the client should warn about such errors as well to make it
 easier to recognize for the client user?
 

See also this ticket: 

http://www.fossil-scm.org/index.html/tktview?name=bfb8427cdd

--
Dmitry Chestnykh
Coding Robots

http://www.codingrobots.com
dmi...@codingrobots.com




smime.p7s
Description: S/MIME cryptographic signature
___
fossil-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 proxy settings in client server mode with autosync

[Dmitry Chestnykh]

On 10.11.2009, at 16:14, Franz Brummer wrote:

 Sorry for the useless traffic. I've found out what my problem was. I
 had the wrong name for the cgi script in the URL of some previous push
 or sync action and didn't recognize that I should have specified the
 right URL once more. Now it works!
 
 But anyway I had to look in the apache logs on the server to find it
 out. Maybe the client should warn about such errors as well to make it
 easier to recognize for the client user?
 

See also this ticket: 

http://www.fossil-scm.org/index.html/tktview?name=bfb8427cdd

--
Dmitry Chestnykh
Coding Robots

http://www.codingrobots.com
dmi...@codingrobots.com

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