On 28/09/15 23:43, Richard Hipp wrote:
[...]
> I built a test repository with a timewarp (using the --override-date
> on a check-in) and it would not import into git. Then I fixed the
> check-in time so that was chronological and tried again, and that time
> the import worked great.
Unfortunately
On 28/09/15 21:14, Richard Hipp wrote:
[...]
> Perhaps this following change will help. Please try and let us know:
Thanks! Unfortunately:
> -"SELECT strftime('%%s',mtime), objid, coalesce(ecomment,comment),"
> +"SELECT strftime('%%s',coalesce(emtime,mtime),"
There's a missing close pa
Somehow I've ended up in this situation, where the parent of a commit
has a newer timestamp than the child:
http://cowlark.com/cgi-bin/fossil.cgi/flooded-moon/timeline?f=905a301d7d28267ee35c41e9dd080d1ce7bcec1d
Exporting this leads to the parent commit being emitted before the child
commit which
On 20/09/15 21:16, David Given wrote:
[...]
> How do I do this? fossil merge won't touch it because my two branches
> don't share an ancestor. If I force it using --baseline with any of the
> obvious revisions it just does crazy things.
As an addendum: fossil merge --cherrypick
So I've just imported a git fast-export file into my repository; it's
created a completely independent branch which does not share ancestry
with my original branch.
I now want to (small-m) merge this in with my main branch --- just
adding the files, so that the new commit ends up having the union
On 05/03/15 21:23, Andy Goth wrote:
[...]
> One thing that repeatedly surprised me when learning Fossil was that the open
> command opens the repository into the current working directory. This left me
> either confused at there being no apparent effect (except a hidden file
> called .fslckout,
On 04/03/15 00:56, Richard Hipp wrote:
[...]
> Try this: /doc/trunk/README?mimetype=text/plain
That's awesome --- thanks!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
signature.asc
D
I'd like to link to my project's README from my doc/index.wiki (via a
.../doc/tip/README URL). Unfortunately, the README, not having an
extension, is being sent as a application/octet-stream, which causes web
browsers to treat it as binary rather than displaying it.
Is there a way I can persuade F
On 18/02/15 00:43, Richard Hipp wrote:
[...]
> will likely have a modified DOM for
> the web interface and thus may break any new skins you come up with
> today.
This might be a good time to mention that I've been playing with a
Material Design skin for Fossil, using the Polymer engine. There'
On 03/02/15 05:50, Joe Mistachkin wrote:
[...]
> Agreed. I'm also of the opinion that this is a good change and I have no
> objections to it.
Awesome. I merged it as [6fedb84abb] and closed the branch. Let me know
if there are any problems.
...BTW, while testing I noticed the new file viewer wit
On 28/01/15 23:33, David Given wrote:
> It seems that doing 'fossil config reset skin' *also* resets the index
> path to the default.
Does anyone have an opinion on this? I'm not going to do a merge without
a sign-off...
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.co
On 02/02/15 15:18, Stephan Beal wrote:
[...]
> Not sure what kind of watch - seems to be one of those new-fangled
> e-watches.
Judging by the buttons, it's a Pebble:
https://getpebble.com/
It's actually an *old* fashioned e-watch --- 128kB RAM, 7 day battery
life. My LG G is lucky to get 18 hour
It seems that doing 'fossil config reset skin' *also* resets the index
path to the default. This is because index-page is set as
CONFIGSET_SKIN. I think that it should be CONFIGSET_PROJ, as SKIN is for
look-and-feel settings only and the home page setting is a semantic change.
I did the world's mo
On 02.09.2014 23:49, David Given wrote:
> Given the discussion in the other thread(s), I have been thinking about
> pull requests. (I've also had a beer. You Have Been Warned.)
So the paperwork's finally come through and I'm able to work on this.
Hurray! Same disclaimer abo
Given the discussion in the other thread(s), I have been thinking about
pull requests. (I've also had a beer. You Have Been Warned.)
I rather like the pull request workflow from github and Bazaar, and it's
something that I rather miss from Fossil. However, given Fossil's
different philosophy, I th
On 9/2/14, 8:02 PM, Ron W wrote:
[...]
> I think that the only way this will happen would be to fork Fossil into a
> new project. This would be because of the overall underlying goals of the
> Fossil project vs a "Fossil-saurus" project.
It may be plausible to simply implement a RDBMS wrapper libr
On 8/3/14, 11:01 PM, Sean Woods wrote:
> What is the latest version of Fossil that will run on the 2.6.x line of
> Linux kernels? I need this in order to run Fossil on my shared host.
> See yesterday's conversation about filenames with a question mark in
> them. Can't compile off trunk and I don
On 1 May 2014 21:13, "Ingo Struck" wrote:
[...]
> author Foo Bar 1398953212 +0200
>
> The timestamp is given in seconds since the Unix epoch,
> (unix time) which is a value already in UTC. The timezone
> information is informative. It may be used to change
> fossil's timezone information during i
On 1 May 2014 15:25, "Jan Nijtmans" wrote:
[...]
> This work was done by David Given in
> the dg-timestamps branch:
Are you sure that get merged? I remember asking for a sign-off a couple of
times, but never got a response, and eventually abandoned it.
--David (aw
On 4/14/14, 9:31 PM, B Harder wrote:
[...]
> Our users shouldn't need CVS, SVN, etc experience to know this. I
> added documentation to clarify.
It might also be useful to add:
# (To abort the commit, leave this file unchanged)
...to the commit message, too.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http:/
On 4/2/14, 7:21 PM, Stephan Beal wrote:
[...]
> i didn't even know RCS could do branches. My RCS phase was short-lived
> before "upgrading" to CVS.
As a totally off-topic comment, one of my other hats is the part-time
maintainer of the Amsterdam Compiler Kit, the ancient compiler toolchain
written
On 2/17/14, 10:26 PM, Stephan Beal wrote:
[...]
> Can you recommend one in C? i'm self-imposed bound to C here. i "might" be
> convinced to write it in C++.
Unfortunately, no --- it's not something I'd really want to do in C, as
C's strengths do not really match the kind of wholesale string shuffl
On 2/17/14, 5:33 PM, Stephan Beal wrote:
[...]
> - rather than think in terms of pages i'd like to think in terms of "apps"
> or "applets." There's no reason that a "page" should not be able to turn
> around and embed 4 other smaller "pagelets." There's also no reason those
> pagelets can't load Ja
On 12/22/13, 8:41 PM, David Given wrote:
> On 22/12/13 20:18, Richard Hipp wrote:
> [...]
>> No. Look at the diff. The indentation is wrong.
>
> Oops, sorry. This one should fix it:
>
> http://www.fossil-scm.org/index.html/info/70b82e8cc5
Was there ever a decision on
On 04/01/14 18:52, Srikumar K. S. wrote:
[...]
> This has come up a few times in the past iirc, but I'm not
> sure whether there is any resolution on whether fossil will
> ever accept to support this and if so in what form it might
> take.
I believe that currently most people do this the other wa
On 03/01/14 21:54, j. van den hoff wrote:
[...]
> as a physicist I've never seen `data' used in its singluar form and I'm
> sure you are not completely (although mostly) right here. but
> as a non-native speaker I rather resort to the "Oxford Dictionary of
> English" which says (citing it verbatim
On 22/12/13 20:56, Martin Gagnon wrote:
[...]
> You can use this vim plugin:
>
>
> https://code.google.com/p/lh-vim/source/browse/misc/trunk/plugin/local_vimrc.vim
Ah! I didn't know such a thing existed. Thanks, very useful.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "There
On 22/12/13 20:18, Richard Hipp wrote:
[...]
> No. Look at the diff. The indentation is wrong.
Oops, sorry. This one should fix it:
http://www.fossil-scm.org/index.html/info/70b82e8cc5
(Incidentally, at some future point when I have time, would a patch to
add vim modelines to all the sourcefil
On 20/12/13 17:07, David Given wrote:
[...]
> http://www.fossil-scm.org/index.html/info/10f9673a25
Does that patch look good enough to merge to trunk? If I don't do it
today I will forget about it completely...
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "There does
This isn't really baked yet, but I'm off on holiday tomorrow and when I
get back I start a (highly prestigious!) new job, so I won't be able to
touch this for a while.
fhg is a bidirectional, incremental Mercural/fossil synchroniser. It'll
push changes in both directions between a Mercurial reposi
On 21/12/13 22:00, Richard Hipp wrote:
[...]
> For a large repo with many files, mtime-changes "off" means that many
> operations are slow, because running SHA1 hashes on thousands of files
> takes significant time. Hence mtime-changes is "off" by default. Normally
> this does not cause problems,
On 21/12/13 21:24, Joerg Sonnenberger wrote:
[...]
> Yes, it certainly uses mtime by default to skip the much more expensive
> hashing step. You can disable that from the settings.
You mean it's *supposed* not to do the SHA1 hash by default? Isn't this
horribly unsafe (because you'll miss changes,
(Why yes, I am doing something moderately evil with Fossil...)
I have found a rather unpleasant-looking bug where if a file's content
changes too quickly, and its size does not change, it's not considered
to have changed. It smells as if Fossil is using a combination of the
file length and timesta
On 21/12/13 09:30, Stephan Beal wrote:
> select uuid from blob order by
> rid limit 1;
Oh, hadn't thought of that. Very nice.
I'm writing a script to manipulate someone else's repository, so tagging
it myself isn't an option --- I have to work with default functionality
only.
Right now I'm using
On 21/12/13 00:05, Richard Hipp wrote:
> Every repository as an initial check-in which is empty. But it always has
> a different SHA1 hash, since it also includes the timestamp from when the
> repository was created.
Is it guaranteed that this will only ever be only checkin with no
parents? And t
hg has a concept of the changeset with uuid
. This is the empty changeset,
and is equivalent to the parent of the very first checkin. Checking out
this changeset will give you an empty repository; checking in with this
as the parent will give you a new tree,
On 20/12/13 22:41, Jan Nijtmans wrote:
[...]
> In fossil that's not a problem: You can always move the commit to
> another branch, even after you already committed it.
Oh, yeah, I'd forgotten you could do that. Admittedly, I only noticed
after I'd done the sync, and wanted to fix things as quickly
On 20/12/13 16:15, Ron Wilson wrote:
[...]
> Interesting. I would have thought all time stamps in git would, like
> Fossil, be seconds from the epoch. (It was originally developed
> by the Linux kernel core team.)
So would I. I suppose it *is* seconds since epoch... but they don't
define which epo
fossil import --git ignores the timezone field on timestamps. I have
this in the fast import dump:
mark :4
author David Given 1309983972 +0100
committer David Given 1309983972 +0100
data 17
Initial checkin.
...but in the fossil repo it actually ends up being:
{
"type"
This change:
http://www.fossil-scm.org/index.html/info/e6cada8219
...has broken some of my wiki pages. In particular, if we assume this
post is wiki formatted, then if I do this:
...then previously the tag was emitted in its own paragraph. Now
it's emitted at the end of the last paragraph, wh
Stephan Beal wrote:
[...]
> i don't know that i can be of any help, but at some point i've got to
> dive into the sync code in the scope of libfossil and (as of about 30
> minutes ago) got tomorrow off of work. If you can post a copy of the
> repo which exhibits the problem, i will take a look over
Remote repo has an artifact, local one won't pull it, a fresh clone Just
Works. This is the classic symptom of the silent sync bug, right? Would
copies of my repositories be useful to anyone?
Both the local and remote are running tip (although the remote version
has some patches). Using --verily o
On 05/09/13 22:41, David Given wrote:
[...]
> I think, without a mathematical proof, that maintaining the ability to
> take prefixes of an encoded name will require us to use a dictionary
> that fits into a precise number of bits. Truncating the dictionary to
> 2^10 entries would be
On 05/09/13 15:21, David Given wrote:
> Richard Hipp wrote:
[...]
>> HHH -> WORD -> HH
>> HH ->WORD-WORD -> H
>> -> WORD-WORD-WORD ->
[...]
> I'll have a go tonight and see what happens --- the encod
Richard Hipp wrote:
[...]
> I think the above doesn't really work for an application like Fossil. I
> think that a prefix of the SHA1 hash should encode to a prefix of the
> mnemonic, and the other way arround too - a prefix of the mnemonic
> should decode back to a prefix of the original hash.
[.
Ross Berteig wrote:
> On 9/4/2013 2:40 PM, Stephan Beal wrote:
[...]
>> As before, i find it really cool, if even if only for its conversational
>> value. i can actually imagine that i'd use it (but won't really know
>> that until trying it out). i will certainly be forking this into
>> libfossil i
Based on various conversations in the past I have been working on a
semi-interesting features: using mnemonic encoding to turn ticket hashes
into something that humans can remember.
This uses a built-in dictionary to convert a hex hash (e.g. '74a95e62')
into a series of words ('TOAST MOZART TULIP'
On 29/08/13 23:19, David Given wrote:
[...]
> I enclose a patch which I think fixes it; please comment...
A little bit more investigation shows that there's actually several ways
in which the code initialises the database connection, and they all very
slightly, and I'm now a bit
I've found a minor bug in the way the patched sqlite3 shell handles
opening the db. In particular, this code from shell.c:
if( data.zDbFilename==0 ){
#ifndef SQLITE_OMIT_MEMORYDB
data.zDbFilename = ":memory:";
#else
fprintf(stderr,"%s: Error: no database filename specified\n", Argv0);
This is head-scratchingly weird:
dg@hilfy:/tmp$ fossil clone
https://dg%40cowlark.com:@fossil-scm.org fossil.fossil
Bytes Cards Artifacts Deltas
Sent: 53 1 0 0
Received: 4000570 12097 1288 4774
Sent:
I've finally gotten around to tracking down a problem I ran across a while
back but never, er, tracked down.
What happens is that if I export a config from a repo with a customised
ticket schema, then when the config is imported into another repo, the
schema does not take effect. (But any ticket r
John Long wrote:
[...]
> That's what I have been doing. But it seems very wrong to have to play games
> with this.
If you know the names of the binaries in advance, it should be possible
to add each one to the ignore list individually --- e.g. fossil's own
looks like this:
compat/openssl*
compat/
but all my changes should be in the dg-misc branch.
(Although it's quite possible that other people have done the same fixes
since I made my changes, and I simply haven't noticed. I haven't looked at
this stuff for a while.)
--
David Given
d...@cowlark.com
Sean Woods wrote:
[...]
> Has anybody tried using "fcgiwrap" with Fossil in order to run it on Nginx?
> (I haven't, but thought the pointer might be useful.)
I was using it for cowlark.com, but gave up in favour of running fossil
in inetd (and then having nginx proxy to the inetd session). I can
Stephan Beal wrote:
[...]
> - lib
I really want to suggest 'archeoraptor', being a famously fake fossil,
but it's a bit of a mouthful. 'Piltdown', perhaps?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "USER'S MANUAL VERSION 1.0: The information presented in this
│ publication has
Stephan Beal wrote:
[...]
> Alternate suggestion: we simply print the SHAs in decimal form ;).
> They're not sequential but at least they're human-readable ;).
A while back I did come up with an astoundingly stupid idea for making
SHAs more readable; fortunately I never got around to implementing
Richard Hipp wrote:
[...]
> How do you actually use Fossil on an Android device, since it is a shell
> application? Is there a shell I can use on Android? I mean something
> other than "adb shell" - some way to use Fossil directly on the device
> without hooking it up to a workstation?
There's
Richard Hipp wrote:
[...]
> I think this is a very useful feature. But I'm guessing that not many
> people know it exists. Please confirm or refute my guess.
I only found this out by asking whether such a feature existed, and
being told about it. It would never have occurred to me to try it myse
On 18/02/13 21:43, Richard Hipp wrote:
[...]
> This is by design. The ticket setup is a per-repository feature. Some
> repositories owners may want a different setup from others.
>
> To sync the ticket setup use "fossil config sync" instead of "fossil sync".
Sorry, I wasn't making myself clear
On 18/02/13 21:33, Stephan Beal wrote:
[...]
> Just seen while tweaking the ticket-specific timeline.rss... maybe this
> behaviour has been around a while, but i've never noticed it...
I have noticed an oddity in the past, which I haven't gotten around to
nailing down enough to make a bug report,
David Given wrote:
[...]
> To merge from trunk to the branch, check out the branch and do 'svn
> merge trunk && svn commit'; to merge from the branch to the trunk, check
> out the trunk and do 'svn merge && svn commit'.
I do, of course, mean fossil
Tommaso D'Argenio wrote:
[...]
> My guess is that I've to create another branch for testing, and work on
> that one instead of the production code. Then once I'm satisfied I shall
> run a merge somehow.
Yes, that's how it works.
To create a branch, check something in with 'fossil commit --branch
Stephan Beal wrote:
[...]
> @David/Martijn: is there any reason not to merge this with the trunk?
> i.e. is it working as everyone would like it to?
>
> Still todo (but can be done later): add a link in the ticket view page
> which points back to the ticket-specific RSS feed.
I can't think of any
Stephan Beal wrote:
[...]
> @David: if you have made modifications since your original patch, those
> are not included here - please feel free to patch this further.
Yes, I have --- fixed some bugs, actually. I've patched the changes in.
Is it possible to do a merge of only one file, in order to
Martijn Coppoolse wrote:
> On 9-2-2013 10:58, Stephan Beal wrote:
[...]
> The Firefox extension that does the same thing is here:
> https://addons.mozilla.org/en-us/firefox/addon/rss-icon-in-awesombar/
>
> In IE, the feed icon sitting in the Command Bar (which is off by default).
>
> In Opera, it
On 09/02/13 00:07, Stephan Beal wrote:
[...]
> Please forgive my ignorance of lua, but what am i missing here?
>
> [stephan@host:~/cvs/fossil/ticketer/reporter]$ lua reporter.lua
> lua: reporter.lua:62: module 'pl.path' not found:
[...]
> i can't seem to find any "pl" module in my package db (Ubu
Stephan Beal wrote:
[...]
> This seems to not _quite_ do it:
>
> http://localhost:8080/timeline?y=t&tkt=cd201d69bb
timeline.rss, surely?
In fact, it hadn't occurred to me to look at the timeline code, which I
have now done, and have fixed my performance issues by copying what it did.
Checkin:
David Given wrote:
[...]
> I think I can do better than that, anyway. What I'd really like is to be
> able to specify a particular Thing (is 'artifact' the right word here?)
> and get an RSS feed for that Thing --- be it a file, wiki page, ticket,
> branch etc. I'll
Stephan Beal wrote:
> On Wed, Feb 6, 2013 at 1:03 AM, David Given <mailto:d...@cowlark.com>> wrote:
[...]
> https://cowlark.com/calculon/tktview?name=9e114e9de0
> https://cowlark.com/calculon/timeline.rss?tkt=9e114e9de0
[...]
> "The webpage
> at *https://cowl
Stephan Beal wrote:
[...]
> "The webpage
> at *https://cowlark.com/calculon/timeline.rss?tkt=9e114e9de0* might be
> temporarily down or it may have moved permanently to a new web address."
Grr. The entire server seems to have gone down. I don't believe that's
fossil-related. (It's a very small ARM
On 05/02/13 16:51, Stephan Beal wrote:
[...]
> LOL - i know that problem all too well ;). And my boss can unfortunately
> tell the difference between C and Java code :/.
It lives!
https://cowlark.com/calculon/tktview?name=9e114e9de0
https://cowlark.com/calculon/timeline.rss?tkt=9e114e9de0
It's n
Martijn Coppoolse wrote:
[...]
> Not *completely*. The fields starting with `tkt_` are mandatory, and
> can’t be removed. The ticket-ID being one of them, adding it as a
> filtering parameter to the "timeline.rss" feed shouldn’t be problematic.
>
> Filtering on the non-mandatory fields would prob
Martijn Coppoolse wrote:
[...]
> I too have added a set of auto-discovery links to my headers. That way,
> most (desktop) browsers will display a feed icon, which when clicked
> pops up a menu of the different RSS feeds available.
Gosh, I'd forgotten about that... would some more explicit RSS feed
I know there's an unpublicised mechanism for getting the RSS feed of a
timeline --- I'm using it to get notifications of new ticket activity
for my project.
Is there a similar mechanism for getting the RSS feed *for a specific
ticket*? I'd like to be able to point users at it so they can get
updat
Joerg Sonnenberger wrote:
[...]
> The only real improvement GNU TLS provides over OpenSSL is GPL
> compatibility for Linux distributions. Otherwise it is just as messy as
> OpenSSL.
Having used it in a project, I would agree with that last statement, but
I should point out that GNUTLS does provide
David Given wrote:
[...]
> // is a rather obscure but incredibly handy feature of URLs that a lot
> of people don't know about. It's an *absolute* URL using the same schema
> as the currently loaded page.
Hmm. There's a bit more to making this work than the wiki formatter
Hey, look, it's another one...
This prevents the wiki formatter from adding the base URL to URLs
starting with //.
// is a rather obscure but incredibly handy feature of URLs that a lot
of people don't know about. It's an *absolute* URL using the same schema
as the currently loaded page. For exam
A while back I ran into an issue where baseurl wasn't being handled
properly for the case where a single fossil server was handling multiple
repositories. For example, with:
fossil server /home/fossil --baseurl https://cowlark.com/
...then when $baseurl was being expanded in the templates, it w
I'm trying to change the section of the header for one of the
repositories on my server.
Because it's wrong, the web UI is unusable. So I can't go that route.
Instead I'm trying to use fossil config, and am having absolutely no
luck --- 'fossil config import' seems to be doing nothing.
What I'm
Michai Ramakers wrote:
[...]
> Thank you for the suggestion, however:
>
> $ /tmp/fossil clone http://michai@10.1.1.11:8080/ copy.fossil
>
> (same result - slow)
N! My precious credibility!
Well, it's good to be able to rule that out. I have no more ideas,
unfortunately.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ
Michai Ramakers wrote:
[...]
> ...resulting in about 70 kB/s traffic with very rare (a minute or more
> in between - didn't time exactly) single bursts. According to top(1),
> neither server- nor client-fossils seem to be doing anything
> CPU-intensive at that time.
[...]
> Both 'local to local' cl
Richard Hipp wrote:
[...]
> But, should there be an opt-in option to also make the disk changes?
> Perhaps "fossil rm abc.txt" just removes abc.txt from configuration
> management, but "fossil rm -f abc.txt" also removes it from disk?
Yes, please. (Particularly with fossil mv; refactoring large n
Richard Hipp wrote:
[...]
> fossil configuration export skin somefile.txt
> # edit somefile.txt to fix your problem
> fossil configuration import somefile.txt
Brilliant --- thanks.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "There is nothing in the world so dangerous --- and I m
I've managed to bugger up the base URL in one of my fossil repos.
Unfortunately I now can't fix this because the 'update' button on the
web page is pointing at the wrong URL...
Is there a way I check out / check in the header text from the command
line so that I can fix this without using the web
Richard Hipp wrote:
[...]
> CVS did not couple the actions, and I copied CVS in this regard. I
> agree with you now, that coupling them is the right thing to do. But I
> fear to change it because that might cause problems for existing scripts.
Add a -p for physical option to actually change the
On 28/10/12 19:02, Nolan Darilek wrote:
[...]
> Read about SNI, which allows multiple SSL certs on a single IP and is
> supported in all modern browsers.
That's totally new to me --- glad they finally sorted that out. Thanks!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Of course
On 28/10/12 16:52, Chad Perrin wrote:
> Are there some tips
> and caveats that anyone can offer me for how to handle Bluehost in
> particular to get Fossil running?
The magic phrase to look for is 'custom CGI script'. Fossil as a server
works via CGI, so if Bluehost let you write your own CGI scri
On 26/10/12 23:06, Bernd Paysan wrote:
[...]
> If you have the incomplete repository, try a "fossil pull", which then will
> fail with an error message.
Yep, you're right, that dies:
$ fossil pull -R out.fossil
Server:http://fossil.forth-ev.de/vd-2012-03
Bytes Cards Art
On 26/10/12 22:42, Bernd Paysan wrote:
[...]
> or try cloning it (will fail!)
Cloning worked successfully for me, on:
This is fossil version 1.22 [ab461f39af] 2012-03-29 08:48:38 UTC
(standard Debian version on amd64), and also on:
This is fossil version 1.24 [21f8161e8e] 2012-10-23 18:20:03 UT
On 21/10/12 19:54, Richard Hipp wrote:
[...]
> I'm not going to include that change in the upcoming 1.24 release since
> I want to give more time to "bake". It will appear in version 1.25.
> In the meantime, you can download the code and build your own Fossil
> executable that includes this enha
On 19/10/12 21:48, Richard Hipp wrote:
[...]
> It tells you about the conflict when you do the "update" or "merge".
> That's the only warning you have.
>
> Do you think we should enhance Fossil to keep track of conflicts and
> issue warnings if you try commit with unresolved conflicts?
Definitel
So I've just had my first merge conflict (in a small private project); I
updated, but had a local change to a file which collided with an
incoming change. (The file had also been moved, which made things more
complicated.)
In other VCSes, I'm used to using the following workflow:
- do update, get
Richard Hipp wrote:
[...]
> Worked ok here. What version of fossil do you have? What does "fossil
> version" tell you?
I'm on Debian, and am seeing it both the current release:
This is fossil version 1.22 [ab461f39af] 2012-03-29 08:48:38 UTC
...and from the upcoming release:
This is fossil ve
So I tried this:
fossil http /home/fossil --baseurl http://cowlark.com/fossil
Now, I know now that the version of Fossil I was testing with doesn't
support --baseurl, but I surprised to get this in response:
Segmentation fault
Brief experimentation shows that any unrecognised option after the
r
Bill Burdick wrote:
[...]
> I think if you pull a rebased branch, you can get an error if the commit
> your branch is no longer in the branch history, at which point you have to
> decide what to do -- I think you can force the pull, if you want to. If
> you made changes on the branch, you'd probab
Bill Burdick wrote:
[...]
> Who would want to have that? I think the Git community answers that.
> Anyone who wants to have a cleaner presentation of history than what
> actually happened. Being able to have a clean view without losing the
> actual history sounds like a good trick, to me, and it
Richard Hipp wrote:
> You assume correctly.
Good to know --- just checking!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dang
On 13/09/12 21:08, Richard Hipp wrote:
[...]
> Basically, we need a routine that converts an in-memory buffer from
> UTF16 to UTF8, and leaves anything that isn't UTF16 unchanged. Then we
> need to call that routine in a few strategic places inside of Fossil
Could you clarify what you mean by 'le
Stuart Rackham wrote:
[...]
> Here's another of my replies that was dropped:
I've received both your replies, directly. The one you repeat here was
received at 0542 local time, while your repeat was received 0628. I
don't think they're being dropped, just delayed.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ ht
On 22/08/12 21:06, Tomek Kott wrote:
[...]
> fossil.exe: SQLITE_ERROR: near "s": syntax error
> fossil.exe: near "s": syntax error
> UPDATE vfile SET pathname=' ** @ T's.eps' WHERE pathname=' *** @
> T's.eps' AND vid=347
From add.c:
db_multi_exec(
"UPDATE vfile SET pathname='%s' WHE
1 - 100 of 113 matches
Mail list logo
