On 04/05/2010 04:02 PM, D. Richard Hipp wrote:
On Apr 5, 2010, at 3:50 PM, Wilson, Ronald wrote:
Is there a way yet to require a GPG signature for all checkins?
No, not yet.
There are two things that could be done here. (1) Require all check-
ins to be signed in the client software.
D. Richard Hipp wrote:
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.
Hi,
As for the case of removing illegal insertions, I think it is far better
to have the real history saying we had these from this date to that date,
as you can see, but you can also see that they were removed at a
particular time and not used thereafter. This follows the accounting
On Mon, 5 Apr 2010, Twylite wrote:
The point about accountability is well made though - perhaps the shun
action should cause an entry in the timeline at the time the shun is
effected, indicating the artifact that was shunned, the parent of the
shunned artifact, and a comment (why it was
Hence, Fossil has from the beginning supported the ability to PGP sign
check-ins. The PGP signature is optional. If a check-in is signed,
you know exactly who originally made that check-in. In situations
where it matters, simply assume that an unsigned check-in is malicious
and avoid using
Hence, Fossil has from the beginning supported the ability to PGP sign
check-ins. The PGP signature is optional. If a check-in is signed,
you know exactly who originally made that check-in. In situations
where it matters, simply assume that an unsigned check-in is malicious
and avoid using
Is there a way yet to require a GPG signature for all checkins?
No, not yet.
There are two things that could be done here. (1) Require all check-
ins to be signed in the client software. Of course, a hacker could
easily defeat such a system, so it is really only to prevent honest
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
D. Richard Hipp wrote:
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
On Sun, 4 Apr 2010, D. Richard Hipp wrote:
I argue that abandoned branches are part of the historical record and
ought to be preserved. Fossil does distinguish between Open and
Closed branches. The user interface currently displays all branches
on the same page, but if it got to be a
On Sun, April 4, 2010 at 3:33 pm, Gé Weijers g...@weijers.org wrote:
On Sun, 4 Apr 2010, D. Richard Hipp wrote:
I argue that abandoned branches are part of the historical record and
ought to be preserved. Fossil does distinguish between Open and
Closed branches. The user interface
On 04/04/2010 01:40 PM, Eric wrote:
As for the case of removing illegal insertions, I think it is far better
to have the real history saying we had these from this date to that date,
as you can see, but you can also see that they were removed at a
particular time and not used thereafter.
That
-
From: Gé Weijers g...@weijers.org
To: e...@deptj.eu; fossil-users@lists.fossil-scm.org
Sent: Sun, Apr 4, 2010 4:47 am
Subject: Re: [fossil-users] Fossil GUI for local source tree operations
On Thu, 1 Apr 2010, Eric wrote: And that is the way SCM should be -
_no_ opportunity to rewrite
To: fossil-users@lists.fossil-scm.org
Sent: Wed, Mar 31, 2010 6:55 pm
Subject: [fossil-users] Fossil GUI for local source tree operations
I understand the rationale for the command line interface, of course.
I am very comfortable using the command line (I always have at least
one dos-box open
I expected e.g. fossil changes to give me my current directory
changes only.
This is indeed a reasonable requirement. When working inside a checkout
repository, all local commands should operate within working directory.
- Altu
Well, no. I would never use that. What I need is Where was
On Thu, Apr 1, 2010 at 7:58 PM, Eric e...@deptj.eu wrote:
This is indeed a reasonable requirement. When working inside a checkout
repository, all local commands should operate within working directory.
- Altu
Well, no. I would never use that. What I need is Where was I? when the
day
On Thu, 2010-04-01 at 14:07 -0400, Stephan Beal wrote:
If i'm in my src tree under a/b/c and run svn status, i see only the
status of stuff under that branch of the tree
This makes some sense in SVN because multiple projects and branches are
all represented in a single tree.
I prefer the way
I understand the rationale for the command line interface, of course.
I am very comfortable using the command line (I always have at least one
dos-box open).
But sometimes you get a list of files e.g. fossil changes and for some of those
files you would like to see the diffs - it's just easier
Folks,
Re a Fossi GUI, please note I've suggested a Tk Fossil GUI in the Google Summer
of Code (GSOC) Tcl/TK projects. Search for Fossil in http://wiki.tcl.tk/23186
If you know of any students who would like to earn $5k over the summer whilst
learning about GUI design and development (not to
Hi Folks,
I have been using fossil for a week or so now and I really like its balance of
features and small footprint.
fossil ui is great for repository based work but there is no gui to help with
local file admin is there?
I mean ops like fossil changes - I would like to get a list of
20 matches
Mail list logo
