On Sun, 29 Apr 2012 18:46:49 -0700, Leo Razoumov slonik...@gmail.com
wrote:
On Sun, Apr 29, 2012 at 12:08, Kevin Quick qu...@sparq.org wrote:
This isn't quite as convincing an argument to me: I can see the utility
of a
pull/sync from a read-only repository, but a fossil open implies that
On Mon, Apr 30, 2012 at 09:45, Kevin Quick qu...@sparq.org wrote:
On Sun, 29 Apr 2012 18:46:49 -0700, Leo Razoumov slonik...@gmail.com wrote:
And at least in UNIX you really
do not want making your repository writable by several people.
Huh? Bob works on stuff and commits it. After Bob
On Mon, Apr 30, 2012 at 7:25 PM, Leo Razoumov slonik...@gmail.com wrote:
others (chmod 0644 repo.fossil). In the case of CGI the owner is
whatever your http server likes (www-data on Ubuntu).
Tip: many CGI environments run user CGIs as that user. If you are lucky
enough to have such a service
On Mon, Apr 30, 2012 at 13:43, Stephan Beal sgb...@googlemail.com wrote:
On Mon, Apr 30, 2012 at 7:25 PM, Leo Razoumov slonik...@gmail.com wrote:
others (chmod 0644 repo.fossil). In the case of CGI the owner is
whatever your http server likes (www-data on Ubuntu).
Tip: many CGI environments
Hi All,
the recent changes to the trunk make fossil open to modify the
fossil repository being opened.
If this repository is read-only or mounted on a read-only file system
than fossil open fails [2] and no _FOSSIL_ file is created.
I would prefer the solution proposed by Matt Welland [1] to keep
On Sun, Apr 29, 2012 at 1:01 PM, Leo Razoumov slonik...@gmail.com wrote:
~/.fossil is, on the other hand, a completely different story. Its
purpose is precisely to help a user to organize its work with all
his/her fossil repositories and their checkouts.
FWIW: +1
And that file won't ever
On Sun, 29 Apr 2012 04:01:08 -0700, Leo Razoumov slonik...@gmail.com
wrote:
Hi All,
the recent changes to the trunk make fossil open to modify the
fossil repository being opened.
If this repository is read-only or mounted on a read-only file system
than fossil open fails [2] and no _FOSSIL_
On Sun, Apr 29, 2012 at 12:08, Kevin Quick qu...@sparq.org wrote:
This isn't quite as convincing an argument to me: I can see the utility of a
pull/sync from a read-only repository, but a fossil open implies that one
will be doing work with the opened contents and further implies that one
8 matches
Mail list logo
