At 06:34 PM 12/22/2010, altufa...@mail.com wrote:
>Hi Ross,
>I face this issue even on Win32 XP SP2. It used to build
>successfully before recent commit [e084092a07].
>
>Were you successful to build it after above commit?
I don't know (yet). The last build I built myself was probably
[6fd2ff1
Hi Ross,
I face this issue even on Win32 XP SP2. It used to build successfully
before recent commit [e084092a07].
Were you successful to build it after above commit?
- Altu
-Original Message-
From: Ross Berteig
To: fossil-users@lists.fossil-scm.org; fossil-users@lists.fossil-scm.org
At 04:29 PM 12/22/2010, Richard Hipp wrote:
>I spent a very frustrating morning on Monday, downloading mingw
>and trying to get the makefile to work on a new windows7 box I
>have sitting off to might right. It appears that getting the
>makefile to work on win7 will be very hard indeed. If any
I spent a very frustrating morning on Monday, downloading mingw and trying
to get the makefile to work on a new windows7 box I have sitting off to
might right. It appears that getting the makefile to work on win7 will be
very hard indeed. If anybody has any hints, I would like to hear them. At
t
> Od: "Arnel Legaspi"
> Komu: fossil-users@lists.fossil-scm.org
> Datum: 22.12.2010 20:21
> Předmět: Re: [fossil-users] Errors during compile in Windows 7 x64
>
>On 12/22/2010 5:35 PM, fossil-users-requ...@lists.fossil-scm.org wrote:
>> On Mon, Dec 20, 2010 at 6:11 PM, Arnel Legaspi wrote:
>>
>>
Right, okay -- that's fairly reasonable, you couldn't realistically
prepare an attack on a repository then.
(The question of using things that are slower than SHA1 as in my
original post still stands, of course. As you've said, it's definitely
better than some stuff that gets used -- such as the r
On Thu, Dec 23, 2010 at 12:12:05AM +0100, Laurens Van Houtven wrote:
> On Thu, Dec 23, 2010 at 12:01 AM, Joerg Sonnenberger
> wrote:
> > On Wed, Dec 22, 2010 at 11:06:47PM +0100, Laurens Van Houtven wrote:
> >> I was looking at
> >> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki
Ahh, yes, I just realized you were probably talking about PBKDF1/2. My
apologies :-) That is a fair comparison, since they're both tunably
hard to compute KDFs.
cheers
lvh
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossi
On Thu, Dec 23, 2010 at 12:18:32AM +0100, Laurens Van Houtven wrote:
> On Thu, Dec 23, 2010 at 12:05 AM, Joerg Sonnenberger
> wrote:
> > On Thu, Dec 23, 2010 at 12:01:43AM +0100, Joerg Sonnenberger wrote:
> >> Using scrypt wouldn't increase size much as most of the primitives exist
> >> already. U
On Thu, Dec 23, 2010 at 12:05 AM, Joerg Sonnenberger
wrote:
> On Thu, Dec 23, 2010 at 12:01:43AM +0100, Joerg Sonnenberger wrote:
>> Using scrypt wouldn't increase size much as most of the primitives exist
>> already. Using a format like $id$salt$encrypted like most UNIX systems
>> for passwd woul
On Dec 9, 2010, at 15:45 , Remigiusz Modrzejewski wrote:
> I've implemented this feature, fix to the ticket:
> http://fossil-scm.org/index.html/info/7ffe8a6cee
>
> Available for pulling at:
> http://dev.lrem.net:8004/doc/trunk/www/index.wiki
As requested, I remind about this feature.
Kind reg
On Thu, Dec 23, 2010 at 12:01 AM, Joerg Sonnenberger
wrote:
> On Wed, Dec 22, 2010 at 11:06:47PM +0100, Laurens Van Houtven wrote:
>> I was looking at
>> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and
>> worried about the case of a compromised repository. Why does Fossil
>> u
On Thu, Dec 23, 2010 at 12:01:43AM +0100, Joerg Sonnenberger wrote:
> Using scrypt wouldn't increase size much as most of the primitives exist
> already. Using a format like $id$salt$encrypted like most UNIX systems
> for passwd would be an improvement in any case.
s/scrypt/HMAC-SHA1 based crypt/
On Wed, Dec 22, 2010 at 11:06:47PM +0100, Laurens Van Houtven wrote:
> I was looking at
> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and
> worried about the case of a compromised repository. Why does Fossil
> use SHA1 and not scrypt/bcrypt to store passwords?
Positive: the pa
On Wed, Dec 22, 2010 at 11:39 PM, Richard Hipp wrote:
> On Wed, Dec 22, 2010 at 5:06 PM, Laurens Van Houtven
> wrote:
>> Hi.
>>
>> I was looking at
>> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and
>> worried about the case of a compromised repository. Why does Fossil
>> use
On Dec 22, 2010, at 23:39 , Richard Hipp wrote:
> SHA1 is already available in the source tree whereas scrypt/bcrypt introduce
> unwanted and undesirable dependencies. Also, if the repository is
> compromised, such that the adversary is able to mount a dictionary attack
> against the passwords,
On Wed, Dec 22, 2010 at 5:06 PM, Laurens Van Houtven wrote:
> Hi.
>
>
>
> I was looking at
> http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and
> worried about the case of a compromised repository. Why does Fossil
> use SHA1 and not scrypt/bcrypt to store passwords?
>
SHA1 is al
Hi.
I was looking at
http://www.fossil-scm.org/index.html/doc/trunk/www/password.wiki and
worried about the case of a compromised repository. Why does Fossil
use SHA1 and not scrypt/bcrypt to store passwords?
thanks in advance (and happy holidays),
lvh
_
On Wed, Dec 22, 2010 at 10:59 AM, Joshua Paine wrote:
> On 12/22/2010 01:33 PM, Russ Paielli wrote:
> > Does that mean I should not close fossil even when I logout or
> > restart my computer?
>
> Correct. Fossil does not stay running when you `fossil open`. Open means
> 'create a working copy', no
On Wed, Dec 22, 2010 at 10:46 AM, Joerg Sonnenberger <
jo...@britannica.bec.de> wrote:
>
> On Wed, Dec 22, 2010 at 10:33:17AM -0800, Russ Paielli wrote:
> > By the way, I answered the overwrite query as "a (always)", and I got
> this:
> >
> > fossil: unable to open file
> > "/home/paielli/TSAFE/co
On Wed, Dec 22, 2010 at 10:59 AM, Joshua Paine wrote:
> On 12/22/2010 01:33 PM, Russ Paielli wrote:
> > Does that mean I should not close fossil even when I logout or
> > restart my computer?
>
> Correct. Fossil does not stay running when you `fossil open`. Open means
> 'create a working copy', no
On 12/22/2010 5:35 PM, fossil-users-requ...@lists.fossil-scm.org wrote:
> On Mon, Dec 20, 2010 at 6:11 PM, Arnel Legaspi wrote:
>
>> Hello,
>>
>> Compiling Fossil in 64-bit Windows 7 appears to stop after the
>> "makeheaders" step. It produces the following error:
>>
>> Can't read input file ".\wo
On 12/22/2010 01:33 PM, Russ Paielli wrote:
> Does that mean I should not close fossil even when I logout or
> restart my computer?
Correct. Fossil does not stay running when you `fossil open`. Open means
'create a working copy', not 'start a background process'. If you have
any fossil server or
On Wed, Dec 22, 2010 at 10:33:17AM -0800, Russ Paielli wrote:
> On Wed, Dec 22, 2010 at 8:11 AM, Joshua Paine wrote:
>
> > On 12/22/2010 01:49 AM, Russ Paielli wrote:
> > > I keep getting this question when I open fossil:
> >
> > `fossil open` should be a relatively rarely used command. 'open' mea
On Wed, Dec 22, 2010 at 8:11 AM, Joshua Paine wrote:
> On 12/22/2010 01:49 AM, Russ Paielli wrote:
> > I keep getting this question when I open fossil:
>
> `fossil open` should be a relatively rarely used command. 'open' means
> 'create working copy'. I.e., fill the current (usually empty) directo
On Wed, Dec 22, 2010 at 11:28:26AM -0500, Richard Hipp wrote:
> On Wed, Dec 22, 2010 at 11:08 AM, Joerg Sonnenberger <
> jo...@britannica.bec.de> wrote:
>
> > Hi all,
> > one of the smaller issues when comparing cvs and fossil is the handling
> > of mtime on checkout and update. If you checkout a
On Wed, Dec 22, 2010 at 11:08 AM, Joerg Sonnenberger <
jo...@britannica.bec.de> wrote:
> Hi all,
> one of the smaller issues when comparing cvs and fossil is the handling
> of mtime on checkout and update. If you checkout a new working copy with
> CVS, all files will get the time of last commit as
On Wed, Dec 22, 2010 at 11:18:52AM -0500, Richard Hipp wrote:
> On Wed, Dec 22, 2010 at 10:48 AM, Michael Barrow wrote:
>
> > Slight correction: HFS+ if you created the filesystem w/o the
> > case-sensitivity option. the fact that case-insensitivity is the default
> > puzzles me, being a Unix pur
On Wed, Dec 22, 2010 at 10:48 AM, Michael Barrow wrote:
> Slight correction: HFS+ if you created the filesystem w/o the
> case-sensitivity option. the fact that case-insensitivity is the default
> puzzles me, being a Unix purist and all. :-)
>
>
Case is locale-dependent. So what do these case-in
On 12/22/2010 01:49 AM, Russ Paielli wrote:
> I keep getting this question when I open fossil:
`fossil open` should be a relatively rarely used command. 'open' means
'create working copy'. I.e., fill the current (usually empty) directory
with the files from a repo. If there are files already in
Hi all,
one of the smaller issues when comparing cvs and fossil is the handling
of mtime on checkout and update. If you checkout a new working copy with
CVS, all files will get the time of last commit as mtime. This is highly
useful as it makes it very easy to find out the age of a file when
browsi
Slight correction: HFS+ if you created the filesystem w/o the
case-sensitivity option. the fact that case-insensitivity is the default
puzzles me, being a Unix purist and all. :-)
On Wed, Dec 22, 2010 at 1:54 AM, chi wrote:
>
>
> Russ Paielli wrote:
> > Sorry if I am being dense, folks, but I ke
On Wed, Dec 22, 2010 at 10:35:52AM +0100, Ramon Ribó wrote:
>Hello,
>
>We have had this problem in the past.
>
>A simple workaround is to go to the server ui and edit by hand the
> checkin, for example changing the commit date or the comment.
So, I reported this ticket with details,
Russ Paielli wrote:
> Sorry if I am being dense, folks, but I keep getting this question when
> I open fossil:
>
> overwrite (a=always/y/N)?
>
> It goes through all of my files with the same question. I have no idea
> what this means, why it is being asked, or what the correct reply is.
> Over
Hello,
We have had this problem in the past.
A simple workaround is to go to the server ui and edit by hand the
checkin, for example changing the commit date or the comment.
RR
El 22 de desembre de 2010 10:27, Lluís Batlle i Rossell
ha escrit:
> We had a fossil server 2010-10-05 on
We had a fossil server 2010-10-05 on linux-i686, and clients with fossil
2010-12-07.
In a client we committed a change. Synced with the server, and the server showed
the change in the timeline (a simple new checkin in trunk).
Other clients synced to the server, and they did not get the new checki
36 matches
Mail list logo
