Hi
SYNOPSIS
i.
./fossil version
This is fossil version 1.28 [b18f3a5cfb] 2014-04-08 09:37:43 UTC
ii.
./fossil ui -P
iii.
Click on [Code] tab (http://localhost:/dir?ci=trunk)
iv.
Now if I try to open any directory, e.g. www/ I get an error
no such checkin:
2014-04-08 15:14 GMT+02:00 Sergei Gavrikov sergei.gavri...@gmail.com:
no such checkin: b18f3a5cfb8bf40e265d4743191453cf44ab7d33www
as it forms the spurious request
http://localhost:/dir?name=ci=b18f3a5cfb8bf40e265d4743191453cf44ab7d33www
Can anybody confirm this?
Confirmed, and
On Tue, Apr 8, 2014 at 4:10 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote:
With the earlier commit I didn't take into account that in this tricky
line:
http://fossil-scm.org/index.html/artifact/5f55f7fe046?ln=281
A bit of background there: fossil places all path elements after the first
I'm still testing my Fossil GUI.
First, I turn off autosync: fossil settings autosync 0
For both local and remote repo.
For remote repo, I execute fossil ui at port 8080.
Then for local repo in my Fossil GUI commit form, click commit automatically do
these:
- fossil add/delete (for selected
On Tue, Apr 8, 2014 at 7:37 AM, Andy Bradford amb-fos...@bradfords.orgwrote:
As for breaking something that used to work (though not very well or
consistently), we could certainly put it to a vote.
AFAIR the point of collisions with Events has never been mentioned/pointed
out before. i,
Hello,
assuming I deleted some or all files within a directory of an open
repo, can I somehow revert that directory (only), recursively or not?
I think there was something for this, but I forgot.
This is fossil version 1.28 [d35d075328] 2014-03-19 12:33:15 UTC
Michai
On 8 April 2014 17:35, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Apr 8, 2014 at 5:31 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
assuming I deleted some or all files within a directory of an open
repo, can I somehow revert that directory (only), recursively or not?
I think there
On Tue, Apr 8, 2014 at 5:38 PM, Michai Ramakers m.ramak...@gmail.comwrote:
fossil revert thedir/*.c
thx. But the files are... missing :)
(i.e. *.c yields nothing.)
Ah, right, so *.c won't work there. How about:
fossil revert $(fossil ls | grep src/)
?
--
- stephan beal
On 8 April 2014 17:41, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Apr 8, 2014 at 5:38 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
fossil revert thedir/*.c
thx. But the files are... missing :)
(i.e. *.c yields nothing.)
Ah, right, so *.c won't work there. How about:
fossil
Hi all,
Before I get to the problem I noticed, a little ‘complaint’: I find the fact
that many commands work on all branches by default (and without possibility of
overriding that default) problematic. If I’m inside a certain branch then I
logically (most of the time, at least) only care to
And of course I mean FINFO (not FIND), but I always type it as F and in my mind
it got memorized as FIND.
From: Tony Papadimitriou
Sent: Tuesday, April 08, 2014 6:43 PM
To: Fossil SCM user's discussion
Subject: [fossil-users] FIND command inconsistency [69974aaa19]
Hi all,
Before I get to the
On Mon, Apr 7, 2014 at 11:43 PM, Andy Goth andrew.m.g...@gmail.com wrote:
On 4/7/2014 8:59 PM, Andy Bradford wrote:
To be fair, there is still one type of UUID that will work at a
shorter length than 4; events currently do not go through collision
detection, so it's possible to view an event
Thus said Stephan Beal on Tue, 08 Apr 2014 16:58:00 +0200:
AFAIR the point of collisions with Events has never been
mentioned/pointed out before. i, for one, would be all for the UUID
resolution treating events equally, _but_ that opens up potential new
UUID ambiguities
13 matches
Mail list logo
