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
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
virik...@gmail.comha escrit:
We had a fossil
Russ Paielli wrote:
Sorry if I am being dense, folks, but I keep getting this question when
I open fossil:
overwrite file (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.
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, some
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 ml-fos...@qiao.in-berlin.de wrote:
Russ Paielli wrote:
Sorry if I am being
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
On Wed, Dec 22, 2010 at 10:48 AM, Michael Barrow mich...@barrow.me 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
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: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 new
On Wed, Dec 22, 2010 at 10:33:17AM -0800, Russ Paielli wrote:
On Wed, Dec 22, 2010 at 8:11 AM, Joshua Paine jos...@letterblock.comwrote:
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
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 12/22/2010 5:35 PM, fossil-users-requ...@lists.fossil-scm.org wrote:
On Mon, Dec 20, 2010 at 6:11 PM, Arnel Legaspijalespr...@gmail.com 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
On Wed, Dec 22, 2010 at 10:59 AM, Joshua Paine jos...@letterblock.comwrote:
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
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
On Wed, Dec 22, 2010 at 5:06 PM, Laurens Van Houtven l...@laurensvh.bewrote:
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?
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 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
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 Thu, Dec 23, 2010 at 12:01 AM, Joerg Sonnenberger
jo...@britannica.bec.de 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
On Thu, Dec 23, 2010 at 12:05 AM, Joerg Sonnenberger
jo...@britannica.bec.de 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
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
jo...@britannica.bec.de 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
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
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
jo...@britannica.bec.de wrote:
On Wed, Dec 22, 2010 at 11:06:47PM +0100, Laurens Van Houtven wrote:
I was looking at
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
Od: Arnel Legaspi jalespr...@gmail.com
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
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
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
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 r...@cheshireeng.com
To: fossil-users@lists.fossil-scm.org;
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
[6fd2ff1b09]
29 matches
Mail list logo