Hi,
I ran into a snag today after a week away on vacation.
This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC
I performed a pull.
c:\myrepo> fossil pull t:\myrepo\myrepo1.fossil
...lots of changes came down the network...
Bytes Cards Artifacts Deltas
Sent:
Hello,
I never understood enough the difference between the 'checkout' and the 'clone'
user permissions in fossil.
Can someone explain why would someone have the cases of "checkout and not clone"
or "clone and not checkout"?
Thank you,
Lluís.
___
fossi
Hello,
I've a repository with a file changed often (specifically, in 3276 checkins).
The file has around 8000 lines (I think that none beyond 80 columns), and
annotating it takes around 700MB of RAM.
I was having lots of troubles trying to do this annotate in a system with 512MB
of RAM, and I co
On Tue, Aug 30, 2011 at 8:52 PM, ron georgia wrote:
> DUDE! That was it. One leading directory had the wrong permission.
>
Been there, done that! (More than once!)
> Thanks a lot. Should have my new Fossil db ready for production by
> next week! Thanks again.
>
Have fun!
--
- stephan be
DUDE! That was it. One leading directory had the wrong permission.
Thanks a lot. Should have my new Fossil db ready for production by
next week! Thanks again.
On Tue, Aug 30, 2011 at 2:42 PM, Stephan Beal wrote:
> On Tue, Aug 30, 2011 at 8:33 PM, ron georgia wrote:
>>
>> SQLITE_CANTOPEN: cannot
On Tue, Aug 30, 2011 at 8:33 PM, ron georgia wrote:
> SQLITE_CANTOPEN: cannot open file at line 27669 of [b0888047bb]
> SQLITE_CANTOPEN: statement aborts at 31: [REPLACE INTO
> config(name,value) VALUES('captcha-secret',
> lower(hex(randomblob(20;]
>
Make sure the CGI-running process can re
I am sure this is a simple fix,
I set up fossil on an OpenBSD box. Configured Apache to respond to cgi
scripts. In my cgi-bin i have the following cgi file(s)
n_repo.cgi:
#!/usr/local/bin/fossil
directory: /var/www/htdocs/FOSSIL/
ntracker.cgi
#!/usr/local/bin/fossil
# Put the project on the
On Tue, Aug 30, 2011 at 1:25 PM, Marty Backe wrote:
> Is there a way to format the Last Modified field in the View Ticket
> template so that the local time is display instead of UTC?
>
> I was able to use datetime(tkt_mtime,'localtime') in the Report Template,
> but only $ works in the View Ticke
We probably need another flag. A dryrun shouldn't change any files on
the local store.
Maybe just create an alias for fossil sync; fossil update -n ?
I'm thinking of doing that in my emacs integration, but for
across-the-world clients it will make the emacs operations so much
slower.
- Venk
Is there a way to format the Last Modified field in the View Ticket
template so that the local time is display instead of UTC?
I was able to use datetime(tkt_mtime,'localtime') in the Report Template,
but only $ works in the View Ticket template.
Perhaps a useful Feature Request would be to have
On Tue, Aug 30, 2011 at 11:43 AM, Richard Hipp wrote:>
> Is there any reason to "dryrun" a pull? Maybe we should make the automatic
> pull happen even if the -n option is specified?
>
> Note that predicting what an "update" would do after a pull without actually
> doing the pull first would be ra
On Tue, Aug 30, 2011 at 11:43:20AM -0400, Richard Hipp wrote:
> On Tue, Aug 30, 2011 at 11:38 AM, Martin Gagnon wrote:
>
> > Hi,
> >
> > From my CVS background, I'm use to do dry run before every update or
> > commit I do. For CVS it's absolutely necessary, since there's no undo
> > command and f
The use case is obvious: inform the user about the state of the SVC.
Once the user is aknowledged that there are changes to update/merge he can:
1- Merge them automatically
2- Check file by file manually to review the differences
3- Start a branch with own changes
4- Do not update and wait for
On Tue, 30 Aug 2011 11:38:08 -0400
Martin Gagnon wrote:
> From my CVS background, I'm use to do dry run before every update or
> commit I do. For CVS it's absolutely necessary, since there's no undo
> command and for some operation, when there's conflict, it can produce
> a big mess on local file
On Tue, Aug 30, 2011 at 11:38 AM, Martin Gagnon wrote:
> Hi,
>
> From my CVS background, I'm use to do dry run before every update or
> commit I do. For CVS it's absolutely necessary, since there's no undo
> command and for some operation, when there's conflict, it can produce a
> big mess on loc
Hi,
>From my CVS background, I'm use to do dry run before every update or
commit I do. For CVS it's absolutely necessary, since there's no undo
command and for some operation, when there's conflict, it can produce a
big mess on local files.
When I start using fossil, I keep same habit with updat
The img tag was the first thing I tried, but yes, in a .wiki file. I just
tested it again and confirmed that it doesn't work, then I had the thought
to try on a different machine and sure enough, the browser was the problem
and img does work.
Thanks!
Matt
-=-
On Mon, Aug 29, 2011 at 10:00 PM, Ve
Hello,
as I still don't trust that anyone looks at the ticket list, I decided to
mention three new tickets I opened today about what I consider fossil problems:
- fossil commit -user stopped working
- merging a file change with an incoming file delete ends up in silent delete
- lack of warning w
18 matches
Mail list logo
