Hi, all,
Another status update for what is still tentatively known as libfossil...
As of a few minutes ago its tagging support is more or less functional:
[stephan@host:~/cvs/fossil/f2]$ ./f-tag
Usage:
./f-tag -a ARTIFACT_TO_TAG -t TAGNAME [-v VALUE] [-u USER] [-R REPO_DB]
Adds a tag to the giv
Thus said Chad Perrin on Sun, 11 Aug 2013 10:10:40 -0600:
> On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote:
> > On 2013-08-11 14:49, Chad Perrin wrote:
> > >
> > > Err . . . wait. Is it not logging the *user*, or just the IP
> > > address? What would it log in place of the actual au
Thus said "Andy Bradford" on 11 Aug 2013 09:15:53 -0600:
> # will prompt for Fossil user otheruser but login to SSH using local
> USER fossil clone -h on -l otheruser ssh://remote//tmp/proj.fossil
> clone.fossil
I'm also considering dropping -h altogether, and making neither options
global
Very glad you like it.
On Aug 10, 2013 10:55 PM, "Sam Sellars" wrote:
> Thank you sir! This is exactly the type of thing I am looking for. I
> appreciate the time you put into this.
>
>
> —
>
>> Hi Sam.
>>
>> Welcome aboard. I think Fossil is excellent, and I hope you will too.
>>
>> I'm typing
On Sun, Aug 11, 2013 at 6:10 PM, Richard Hipp wrote:
> On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal wrote:
>
>> That wasn't terribly clear. FastCGI basically starts 1 instance of the
>> app and keeps feeding it new data for each request. Fossil's structure does
>> not allow it to do that.
>>
>>
On Sun, Aug 11, 2013 at 9:20 AM, Stephan Beal wrote:
>
> On Sun, Aug 11, 2013 at 3:18 PM, Stephan Beal wrote:
>
>> Fossil is not fastcgi-compatible. i tried to get it working a few years
>> ago but fastcgi requires that each execution of the app has a clean
>> starting state, and fossil's app is
On Sun, Aug 11, 2013 at 03:24:40PM +0200, Rene wrote:
> On 2013-08-11 14:49, Chad Perrin wrote:
> >
> > Err . . . wait. Is it not logging the *user*, or just the IP address?
> > What would it log in place of the actual authenticated Fossil user
> > account that initiated the sync?
>
> The user in
On Sun, Aug 11, 2013 at 03:20:14PM +0200, Stephan Beal wrote:
> On Sun, Aug 11, 2013 at 3:18 PM, Stephan Beal wrote:
> >
> > Fossil is not fastcgi-compatible. i tried to get it working a few years
> > ago but fastcgi requires that each execution of the app has a clean
> > starting state, and fossi
Thus said Stephan Beal on Sun, 11 Aug 2013 15:26:50 +0200:
> One of the devs (Andy?) has been working on integrating ssh forced
> commands with fossil so that ssh connections can use fossil's
> authentication. i'm not sure what the status of that is, but from what
> i've read it sound
Thus said Chad Perrin on Sun, 11 Aug 2013 06:38:45 -0600:
> It should still log Fossil usernames though -- right? If so, that'll
> do, at least for now.
Yes, it will do that.
Andy
--
TAI64 timestamp: 400052079daa
___
fossil-users mailing list
fos
On 2013-08-11 15:26, Stephan Beal wrote:
On Sun, Aug 11, 2013 at 3:24 PM, Rene wrote:
However If your going to break that relation by having n keys on 1
account
then, I presume, your doing something with fossil which wasn't
designed.
One of the devs (Andy?) has been working on integrating
On Sun, Aug 11, 2013 at 3:24 PM, Rene wrote:
> However If your going to break that relation by having n keys on 1 account
> then, I presume, your doing something with fossil which wasn't designed.
One of the devs (Andy?) has been working on integrating ssh forced commands
with fossil so that s
On 2013-08-11 14:49, Chad Perrin wrote:
Thanks for all your information about issues related to axTLS. Not
everything you said warrants a specific response from me, but the
"thanks" is my general response for everything to which I do not
[snip]
Much simpler provided that all you need/want is
On Sun, Aug 11, 2013 at 3:18 PM, Stephan Beal wrote:
> Fossil is not fastcgi-compatible. i tried to get it working a few years
> ago but fastcgi requires that each execution of the app has a clean
> starting state, and fossil's app is built to work only for a single
> execution.
>
That wasn't te
On Sun, Aug 11, 2013 at 2:37 PM, Chad Perrin wrote:
> . . . but you can use fastcgi with nginx. Is that not good enough for
> Fossil?
>
Fossil is not fastcgi-compatible. i tried to get it working a few years ago
but fastcgi requires that each execution of the app has a clean starting
state, and
Thanks for all your information about issues related to axTLS. Not
everything you said warrants a specific response from me, but the
"thanks" is my general response for everything to which I do not
specifically respond below.
Specific comments follow.
On Sun, Aug 11, 2013 at 01:21:37PM +0200, R
On Sat, Aug 10, 2013 at 11:40:34PM -0600, Andy Bradford wrote:
> Thus said Chad Perrin on Sat, 10 Aug 2013 20:07:41 -0600:
> >
> > Thank you. This looks like it will probably suit our needs quite well
> > for the time being. I'll investigate further on my own at this point,
> > though if any mo
On Sun, Aug 11, 2013 at 12:43:24PM +0200, Eduardo Morras wrote:
> On Sat, 10 Aug 2013 20:07:41 -0600
> Chad Perrin wrote:
>
> > Dr. Hipp's series of suggestions have, of course, also been informative
> > for me, and while I do intend to expand capabilities to the point where
> > a separate webser
On 2013-08-10 04:21, Chad Perrin wrote:
On Sun, Aug 04, 2013 at 01:06:38PM +0200, Rene wrote:
The reason I choose axTLS
. . . snip . . .
If this is of interest I can add it on a branch.
I find it pretty interesting. The biggest problem I see with axTLS is
the protocol support limitation yo
On 10 Aug 2013 21:54:59 -0600
"Andy Bradford" wrote:
> Hello,
>
> After having recently discovered the single sign-on functionality
> provided by the Login Groups configuration, I've started experimenting
> with it. I must be doing something wrong because it doesn't seem to
> work:
On Sat, 10 Aug 2013 20:07:41 -0600
Chad Perrin wrote:
> Dr. Hipp's series of suggestions have, of course, also been informative
> for me, and while I do intend to expand capabilities to the point where
> a separate webserver (probably nginx) is involved for some purposes as
> described in one of
21 matches
Mail list logo