On Mon, 23 Nov 2015 16:10:02 +0100, Warren Young <w...@etr-usa.com> wrote:
On Nov 22, 2015, at 6:47 AM, j. van den hoff <veedeeh...@gmail.com>
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
