I'm seeing "database locked" (with failure to load timeline via web)
and "panic: multiple calls to backoffice_run()" from
$ fossil server
which is a recent phenomenon for me.
-bch
___
fossil-users mailing list
fossil-users@
hows I'm still
> in the new branch.
>
> So I have two problems to solve:
> 1) how do I properly move commits between branches (and to trunk, in my
> case)?
> 2) how do I unfudge my current condition and get back to trunk?
>
This would be a candidate for “pop la
On Wed, Jun 13, 2018 at 9:30 AM JH wrote:
> On 06/13/2018 08:11 AM, Warren Young wrote:
> > On Jun 13, 2018, at 8:05 AM, Richard Hipp wrote:
> >> My current tthinking is to use a hybrid approach where subscribers get
> >> emails just like ordinary mailing lists, but posting and replying is
> >>
On Wed, Dec 27, 2017 at 2:23 PM Olivier Mascia wrote:
> > Le 27 déc. 2017 à 23:10, bch a écrit :
> >
> > On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia wrote:
> > Hello,
> >
> > Coming from subversion where there is a revision number, incremented by
> on
urce control system. Maybe
a “feature branch” and your own heuristics would fit the bill?
Cheers,
-bch
which is very easy to capture in automated builds to be injected as part of
> the version number of binaries built...
>
> Revision 8745 -> version x.y.z.8745
> Revision 8789 -> ve
On Mon, Nov 6, 2017 at 9:19 AM Warren Young wrote:
> On Nov 3, 2017, at 12:08 PM, Richard Hipp wrote:
> >
> > On 11/3/17, Olivier R. wrote:
> >>
> >>
> >> Sorry. My knowledge of the C toolchain is null.
> >
> > The next step will be to figure out
> > how to attach the debugger to a hung process
On Sun, Dec 17, 2017 at 8:40 PM bch wrote:
> I'm using recent fossil:
> kamloops$ fossil version
> This is fossil version 2.5 [5419e7fcec] 2017-12-15 18:27:08 UTC
>
>
> trying to view annotate/blame for a file, and on Firefox (Build
> identifier: Mozilla/5.0 (X11; Ne
n was reset
The connection to the server was reset while the page was loading.
Has anybody else seen something like this?
Cheers,
-bch
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/lis
luttered” mode, though.
-bch
> On Sat, Nov 25, 2017 at 8:47 AM, Richard Hipp wrote:
>
>> In the latest code on https://www.fossil-scm.org/fossil/timeline and
>> at https://sqlite.org/srcx/timeline has a "Declutter" button on the
>> sub-menu bar to simplify the scr
On Fri, Nov 24, 2017 at 8:12 AM Richard Hipp wrote:
> On 11/24/17, Richard Hipp wrote:
> > On 11/24/17, Andy Bradford wrote:
> >> I still miss the Leaf, which I do find useful.
> >
> > Ugh. I didn't intend to omit the "Leaf" and "Closed-Leaf" marks,
> > though I did want to move them to the en
On Wed, Nov 22, 2017 at 3:11 PM bch wrote:
>
> On Wed, Nov 22, 2017 at 3:10 PM wrote:
>
>> On Wed, 22 Nov 2017 17:30:10 +
>> Javier Guerra Giraldez wrote:
>> > why not? fossil makes for a neat deployment client! yes, it can also
>> > be done with j
On Wed, Nov 22, 2017 at 3:10 PM wrote:
> On Wed, 22 Nov 2017 17:30:10 +
> Javier Guerra Giraldez wrote:
> > why not? fossil makes for a neat deployment client! yes, it can also
> > be done with just an http client, but still is a nice option to have.
>
> Because people do not use compilers
On Aug 16, 2017 12:54, "Stephan Beal" wrote:
On Wed, Aug 16, 2017 at 9:19 PM, bch wrote:
>
>
> On Aug 16, 2017 12:10, "Stephan Beal" wrote:
>
> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/
7;s true, but still not entirely useless depending on
context. Depending on project, one may simply redistribute the new
("popped") repo out to remotes and pick up from there.
-bch
You should be able to pop any number of consecutive heads up until that
point, though.
- stephan
Se
We really should have (and it's not against philosophy) ability to
pop commits off top, though. I've miscommited to a branch, and I think
I'd just like to redo it, to say nothing of accidentally committing
something sensitive like a credit card number or password.
-bch
On 8/16/1
opy modification checks.
>
You're to blame when that feature request arrives ;).
I'm not following the process. Fossil guarantees hash fidelity - explain
differently how this would work and be coherent w/i fossil?
-bch
--
- stephan beal
http://wanderinghorse.net/home/s
On Jul 26, 2017 21:20, "Richard Hipp" wrote:
I don't know what the cause of the problem is.
The message you are getting is a result of defenses against database
corruption described here:
https://www.sqlite.org/howtocorrupt.html#_multiple_
links_to_the_same_file
Somehow you have set up yo
On Mar 30, 2017 12:35, "The Tick" wrote:
Goodness! All I wanted was to have a comment contain a copyright character.
Thanks to the people who were kind enough to take the time to respond to my
questions. Now my commit messages are no longer a big blob of text, my
.vimrc is modified, I've gotten f
te that "fossil info" gives information about the current checkout,
including the branch name.
-bch
please find an attached patch which implements a new "current" subcommand
for "branch".
This is now the default subcommand if one executes "fossil branch" without
to Git hasn’t been tampered
> with is that the hashes are consistent.
This is a long-standing peeve of mine, which is: a repository is not a
release. If this is how CentOS does distribution, I'd argue they have
more of a systemic problem than a technical one.
-bch
>
> (I randomly in
Are you saing:
contenthash = sha256(content);
identifier = sha256 (contenthash . blobtype . conentsize . content);
"blobtype" == cardtype ?
-bch
On 2/24/17, Joerg Sonnenberger wrote:
> On Thu, Feb 23, 2017 at 05:01:56PM -0700, Warren Young wrote:
>> Second, there wi
On Feb 23, 2017 15:12, "Martin Gagnon" wrote:
On Thu, Feb 23, 2017 at 09:50:12AM -0800, Marc Simpson wrote:
> This may be of interest to some here, especially in light of previous
> SHA-1 related discussions on list:
>
> https://security.googleblog.com/2017/02/announcing-first-
sha1-collision.h
I haven't ever run into this issue, but what you're wondering about sounds
reasonable on the surface. "Principle of least surprise", and all...
-bch
On Feb 6, 2017 08:18, "Richard Hipp" wrote:
> On 2/6/17, Richard Hipp wrote:
> >
> > That is cor
On Dec 24, 2016 10:05, "Stephan Beal" wrote:
On Sat, Dec 24, 2016 at 6:42 PM, Chad Perrin wrote:
> I hope the lack of responses to my questions was because of the holiday
> season
Or maybe interest in git is slowly dying off ;).
Ever hopeful...
--
- stephan beal
http://wanderinghorse.
On Dec 7, 2016 09:13, "Will Parsons" wrote:
On Tuesday, 6 Dec 2016 5:46 PM -0500, bch wrote:
> I've got a collection of files who's apparently only change is the
> EXECUTABLE bit set, but after a commit, they're still showing up in "f
> chan"; I re
On Dec 6, 2016 19:18, "Andy Bradford" wrote:
Thus said bch on Tue, 06 Dec 2016 14:46:23 -0800:
> I've got a collection of files who's apparently only change is the
> EXECUTABLE bit set, but after a commit, they're still showing up in "f
> chan";
h(1) all the
affected files to bump the timestamp, re-commit, STILL listed as
changed (but an entry in the timeline for that commit is listed).
Haven't dug further into whats going on, but it looks like an error,
or at least non-intuitive.
-bch
__
https://news.ycombinator.com/item?id=12737535
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
kamloops$ fossil unver revert
assertion "uvStatus==2" failed: file "./src/xfer.c", line 1893,
function "client_sync"
[1] Abort trap (core dumped) fossil unver revert
kamloops$
On 8/30/16, bch wrote:
> On 8/30/16, sky5w...@gmail.com wrote:
>> This is a w
On 8/30/16, sky5w...@gmail.com wrote:
> This is a welcome addition to house nuisance files like bitmaps, icons,
> etc.
> But, I am confused by the in-out nomenclature?
>
> Push to remote: fossil unversioned sync
> Pull from remote: fossil unversioned revert
> Checkout unv files: fossil unver
On Aug 1, 2016 8:02 PM, "Ron W" wrote:
>
> On Mon, Aug 1, 2016 at 8:22 PM, Adam Jensen wrote:
>>
>> On 08/01/2016 07:40 PM, bch wrote:
>>
>> > in a controlling file. Something like a purpose-built makefile or
>> > script that handles this
a purpose-built makefile or
script that handles this layout, so that -it- can be versioned in
fossil; fossil wasn't/isn't currently designed to handle that sort of
metadata - which *arguably* should be handled in a script as described
above. Fossil can then handle that script as an artif
integrity check, what kind of
horrible network are you on where Ethernet + TCP checksums are insufficient?
Given all this then, why are the checksums (incompletely) provided?
Obviously somewhat confusing.
-bch
___
> fossil-users mailing list
> fossil
Interesting discussion going on at Hacker News currently.
https://news.ycombinator.com/item?id=11667494
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 2/13/16, jungle Boogie wrote:
> On 13 February 2016 at 11:25, Stephan Beal wrote:
>> On Sat, Feb 13, 2016 at 7:47 PM, Andy Bradford
>> wrote:
>>>
>>> I use an old IBM Thinkpad 240. It has 256MB of RAM and a 300Mhz Celeron
>>> and a 6GB hard drive. It's running OpenBSD 5.8 and it took a lon
ully-integrated, cross-referencing ticket
system like we do.
-bch
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On Feb 7, 2016 5:12 AM, "David Macek" wrote:
>
> On 7. 2. 2016 2:53, Joe Mistachkin wrote:
> >
> > I'm unable to test with MingW64; however, I think Jan Nijtmans uses it.
>
> Hmm. So hopefully he's watching the list.
>
> One of my problems is with the linenoise library. It requires
and possibly o
trace indicated a read on fd 5, and many multiple writes on fd
10, and what look like 3 writes on fd5.
On 1/8/16, bch wrote:
> strathcona$ grep 16892b33c7166eb3 http-re*
> http-reply-1.txt:igot 16892b33c7166eb3198844eac4ba5a7a6e395520
>
>
> On 1/8/16, bch wrote:
>> Running
>&
strathcona$ grep 16892b33c7166eb3 http-re*
http-reply-1.txt:igot 16892b33c7166eb3198844eac4ba5a7a6e395520
On 1/8/16, bch wrote:
> Running
>
> $ fossil pull -verily -httptrace
>
> to find out...
>
> -bch
>
>
> On 1/8/16, Jan Danielsson wrote:
>> On 09/01/16 0
Running
$ fossil pull -verily -httptrace
to find out...
-bch
On 1/8/16, Jan Danielsson wrote:
> On 09/01/16 01:15, bch wrote:
>> Just talked to Joerg off-list (who indicated that he updated fossil
>> to latest on his server), and:
>>
>> $ fossil pull -verily
: jmcneill tags: trunk)
13:47:17 [3c49d42557] enable hdaudio (user: jmcneill tags: trunk)
...
still 7 months out of date.
On 1/3/16, Jan Danielsson wrote:
> On 04/01/16 02:02, Richard Hipp wrote:
>> On 1/3/16, bch wrote:
>>> Indeed. I thought maybe the \n of the checkin-card
Ref: https://news.ycombinator.com/item?id=10864176
On Jan 8, 2016 5:27 AM, "Sean Woods" wrote:
> This article was recently posted to Hacker News:
>
> https://matt.sh/howto-c
>
> I'd love to get thoughts/reactions from this community on this set of
> best practices for C programming.
>
> I'm alway
n 1/5/16, Richard Hipp wrote:
> On 1/5/16, bch wrote:
>> I just did another pull, and the branch tags showed up, so @drh, I
>> think your rebuild helped somewhat. Now to find out how the repo got
>> into it's "broken" state in the first place.
>>
>
>
I just did another pull, and the branch tags showed up, so @drh, I
think your rebuild helped somewhat. Now to find out how the repo got
into it's "broken" state in the first place.
On 1/5/16, bch wrote:
> On 1/5/16, Richard Hipp wrote:
>> On 1/5/16, Richard Hipp wro
On 1/5/16, Richard Hipp wrote:
> On 1/5/16, Richard Hipp wrote:
>> On 1/5/16, David Vines wrote:
>>>
>>> One curious aspect I do see is that the web ui has the annotation of
>>> "unpublished" against the creation of the branch. I did start by have a
>>> private branch which I then published - I
list of potentially
reserved names and decouple manifest and manifest.uuid from each
other. (user: jan tags: jan-manifest-tags)
22:46:00 [226e7c2842] Fix; second argument of db_get_versioned() is
not that of db_get(). (user: jan tags: jan-manifest-tags)
--- line limit (20) reached ---
On 1/5/16, bc
Hi Dave.
Don't fret! I'm not attributing this to malice or blaming -you-, but
something does look strange to me (on my local copy of the repo).
Cheers,
-bch
On 1/5/16, David Vines wrote:
> On 05/01/2016 18:53, bch wrote:
>> How did we end up w/ dave.vines' comple
How did we end up w/ dave.vines' completely untagged (no branch)
commits in the repository (or am I misreading what these are?) ?
ref:
/info/b208bf75777604dc
/timeline?u=dave.vines&c=2016-01-05+10%3A12%3A56&nd&n=200
___
fossil-users mailing list
foss
Indeed. I thought maybe the \n of the checkin-card (is this the right
characterization ?) bug/fix might fix what I've been experiencing, so
I updated to the latest. I'm nearly always running the tip of TRUNK.
On 1/3/16, Richard Hipp wrote:
> On 1/3/16, bch wrote:
>> The
x27;s only
emitting:
1510 1 fossil sendto(0xa, 0x7f55319f97c0, 0x2aad782313, 0, 0,
0) Err#32 EPIPE
The last entry in my local copy of the repo is [0bb26b5ab6] from 30 May.
Does anybody have any further ideas for troubleshooting this ?
-bch
On 12/3/15, Andy Bradford wrote:
> Thus sa
Richard, this reminds me of my out standing (and still in "problem"
state) NetBSD repo that exhibits the same problems. It's not mission
critical (which is why I'm fine enough to keep it around for so long
in a broken state), but here for poking when time allows and
inspiration
So, for the default short display, it *could* conceivably be fine to format
for width (by wrapping), since it's not multi-line anyway - you're not
breaking user-provided multi-line formatting here because we're only
dealing w one line.
-bch
>>
>> Yeah, I tried the css trick
On 11/20/15, Joerg Sonnenberger wrote:
> On Thu, Nov 19, 2015 at 11:51:41AM -0800, Scott Doctor wrote:
>> I am looking for information about the theory of VCS that is being used
>> for
>> systems such as Fossil, Git... Not so much the how-to-use, but the
>> concepts
>> and issues.
>
> Both TLA and
On 11/16/15, Ron W wrote:
> On Mon, Nov 16, 2015 at 2:20 PM, bch wrote:
>
>> This is roughly what I'm doing, but it's not 100% accurate, and for
>> the case of 100s of files, still tedious. I guess the point is that
>> there's not any special secret method
On 11/16/15, Ron W wrote:
> On Mon, Nov 16, 2015 at 12:38 PM, bch wrote:
>
>> In the immediate case, it's me tracking 3rd party vendor code which I
>> depend on. I untar, add, commit. On upstream updates, I nuke the
>> 3rd-party
>> code, lay down the new rele
:
>
>
> On Mon, Nov 16, 2015 at 3:02 AM, bch wrote:
>
>> I've got some work where I've got some files whose names change between
>> commits, but are the same logical entity. For example, if I have a file:
>> libxyz-1.2.txt, which might be a description of
l
continuity is preserved, but I can't think of a nice easy automated way for
achieving this for the case of many affected files, or (semi-)complex name
transforms.
Are other people affected by this too? Does anybody have any tricks to
share?
Regards,
-bch
__
On 11/2/15, Ron W wrote:
> On Mon, Nov 2, 2015 at 1:16 PM, bch wrote:
>>
>> Philosophically, I think of links as build artifacts, which are rarely
>> stored in an scm. I do avoid them as much as possible, but I've
>> occasionally wondered: does anybody manage the
On Nov 2, 2015 9:32 AM, "Eric Rubin-Smith" wrote:
>
>
My problem is not the decision itself, but that, in terms of how
fossil should behave, it's a philosophical question. Those have no
right/wrong answer, and i dislike seeing software pretend to know the
answer to such questions.
>>>
>>>
>>>
describe this to you years (6?) ago (without
success), but now I see I can get an effect of my original wish this
way... I'll see if I can dig out my original problem/paradigm, in case
it's enlightening.
-bch
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
Hi. I pushed http://fossil-scm.org/index.html/info/533f8b6aeacb554f on its
own branch for review (philosophical/ui, or errors/updates); otherwise,
it's ready for integration.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fos
do with
git) than the developer. Just a sad story, really.
-bch
On 9/2/15, Scott Robison wrote:
> On Sep 2, 2015 2:43 AM, "Stephan Beal" wrote:
>>
>> Management summary:
>>
>> the bug was that the MSVC integration tool checked in to a public repo
> in
$ fossil info
On Aug 21, 2015 1:34 AM, "Arnel Legaspi" wrote:
> Hello,
>
> The current way I've been using to get the location of the current
> working directory's '.fossil' file is to open the _FOSSIL_ file inside
> the directory with the sqlite3 CLI app and run the following query:
>
> sqli
On Aug 12, 2015 1:19 AM, "Stephan Beal" wrote:
>
> On Wed, Aug 12, 2015 at 10:13 AM, Jacek Cała wrote:
>>
>> Thanks for the suggestion... no luck in finding '<'. It matches only
_FOSSIL_ and a few binary files. It could be the line endings because I
work primarily on Windows and whenever foss
*valuable TAG. (Mobile keyboards
..)
On Jul 27, 2015 7:10 PM, "bch" wrote:
> "Current" might be a pretty valuable yeah to throw away as a sentinel.
> What about "." (dot, period)?
> On Jul 27, 2015 4:46 PM, "Andy Bradford" wrote:
>
>>
"Current" might be a pretty valuable yeah to throw away as a sentinel. What
about "." (dot, period)?
On Jul 27, 2015 4:46 PM, "Andy Bradford" wrote:
> Thus said Luca Ferrari on Mon, 27 Jul 2015 13:58:42 +0200:
>
> > this can be goofy, but is there a way to instrument fossil to create a
> > new br
Tcpwrappers or some reverse name lookup issues? Running ktrace, ptrace, or
whatever your system provides might be telling.
On Jul 15, 2015 3:06 PM, "Philip Bennefall" wrote:
> Hi there,
>
> Thanks to all who responded! I decided to try running Fossil through
> xinetd instead, and am now seeing al
In the meantime would it be feasible to "throw an error" briefly
explaining the issue, and offering links both mutually exclusive dp=
and r= displays ?
-bch
On 7/14/15, Richard Hipp wrote:
> On 7/13/15, Andy Bradford wrote:
>> Thus said Andy Goth on Mon, 13 Jul 2015 14:34
Ugh. Again, include fossil-users@
-bch
-- Forwarded message --
From: bch
Date: Tue, 23 Jun 2015 13:38:39 -0700
Subject: Re: [fossil-users] DB corruption and error msg string mis-handling.
To: Andy Bradford
Very good. Thanks Andy.
See attached.
-bch
On 6/23/15, Andy
$
What am I missing ?
-bch
On 6/23/15, Joerg Sonnenberger wrote:
> On Tue, Jun 23, 2015 at 01:05:00PM -0600, Andy Bradford wrote:
>> Thus said bch on Tue, 23 Jun 2015 11:58:35 -0700:
>>
>> > Good idea (I presume you mean sqltrace):
>>
>> More likely he meant --
Good idea (I presume you mean sqltrace):
kamloops$ fossil pull --sqltrace
-- sqlite3_open: [/home/bch/work/netbsd_src/.fslckout]
PRAGMA foreign_keys=OFF;
SELECT sql FROM main.sqlite_master WHERE name=='vfile';
-- sqlite3_open: [/home/bch/.fossil]
PRAGMA foreign_keys=OFF;
SELECT value
: 135.28.13.11
kamloops$
On 6/23/15, Joerg Sonnenberger wrote:
> On Tue, Jun 23, 2015 at 08:32:13AM -0700, bch wrote:
>> Thanks Joerg. I'll re-sync shortly. Did you happen to test if it had any
>> of
>> the "0" byte blobs I had before (and the 1 I still have)?
&
Thanks Joerg. I'll re-sync shortly. Did you happen to test if it had any of
the "0" byte blobs I had before (and the 1 I still have)?
-bch
On Jun 23, 2015 2:43 AM, "Joerg Sonnenberger"
wrote:
> On Mon, Jun 22, 2015 at 01:44:12PM -0700, bch wrote:
> > W/ latest
tech-kern and
tech-net. (user: ozaki-r tags: trunk)
[...]
On 6/19/15, bch wrote:
> include fossil-users@ ...
>
> -- Forwarded message ------
> From: bch
> Date: Fri, 19 Jun 2015 12:05:13 -0700
> Subject: Re: [fossil-users] DB corruption and error msg string
> mi
include fossil-users@ ...
-- Forwarded message --
From: bch
Date: Fri, 19 Jun 2015 12:05:13 -0700
Subject: Re: [fossil-users] DB corruption and error msg string mis-handling.
To: Andy Bradford
Hi.
I got around to reviewing this, and found a couple interesting things:
1) some
You're ignoring that ssh has extensive configuration options and could be
configured to use an alias. Stephan is probably trying to get a more
definitive test to help.
On Jun 17, 2015 6:06 AM, "Jacek Cała" wrote:
> As stated in the original question 'ssh SERVERNAME' works fine, which
> means 'pin
I've occasionally (rarely) seen errors like the following -- anybody
have an idea what might be going on ? Anything I can do to help
troubleshoot ?
===
(syncing NetBSD pkgsrc (http://pkgsrc.sonnenberger.org)):
[...]
SHA1 (test-unit-3.1.2.gem) = be7ec72f81bbfeebeaf757de3295cd2f282d4ee6
RMD1
So... what do these 0-byte blobs _mean_ ?
I just took the time and rebuilt the repo and retried a pull, but same
problem (content does not match sha1 hash). Does anybody know what a
next step ought to be ?
-bch
On 6/8/15, bch wrote:
> rid: size
> ==
>
> 1355: 0
> 2090601:
: 0
2091128: 0
2091240: 0
2091264: 0
2091288: 0
2091297: 0
2091333: 0
2091339: 0
2091361: 0
2091411: 0
2091427: 0
2091429: 0
2091432: 0
2091463: 0
On 6/8/15, Joerg Sonnenberger wrote:
> On Mon, Jun 08, 2015 at 02:07:36PM -0700, bch wrote:
>> unclear what I should check -- you mean mea
unclear what I should check -- you mean measure blob sizes in the
sqlite db, or tcpdump or some fossil option w/ another "pull" attempt
?
-bch
On 6/8/15, Joerg Sonnenberger wrote:
> On Mon, Jun 08, 2015 at 11:52:20AM -0700, bch wrote:
>> There's either a corrupt
ref: line 196 ./src/xfer.c
...
sha1sum_blob(&content, &hash);
if( !blob_eq_str(&pXfer->aToken[1], blob_str(&hash), -1) ){
blob_appendf(&pXfer->err, "content does not match sha1 hash");
}
...
On 6/8/15, bch wrote:
> There's either a corrupte
sha1
hashcontent does not match sha1 hashcontent does not match sha1 hash
-bch
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I don't understand what you mean when you say "tag". Could you elaborate or
rephrase your problem?
On May 18, 2015 10:49 PM, "Michai Ramakers" wrote:
> Hello,
>
> is there a way to list added tags w.r.t. the last check-in?
>
> What I do now is 'fossil changes' and 'fossil extras' to view
> change
I applied this.
Thanks.
-bch
On 5/13/15, Warren Young wrote:
> On May 13, 2015, at 3:20 PM, Richard Hipp wrote:
>>
>> On 5/13/15, Warren Young wrote:
>>> On May 13, 2015, at 2:29 PM, Richard Hipp wrote:
>>>>
>>>> On 5/13/15, Warren Young
On May 11, 2015 8:40 AM, "Andy Goth" wrote:
>
> On 5/11/2015 9:10 AM, Richard Hipp wrote:
> > On 5/11/15, Abilio Marques wrote:
> >> I recall seeing no way of detecting a "push" to a specific
> >> branch. All I saw were deltas and stuff like that.
> >
> > To change Fossil to have the ability to p
ention that
the pkgsrc had no index on it only because... it had no index on it.
Re: Andy's change -- I think it's at least occasionally (very) useful
and maybe always useful. It's a good one.
Thanks Andy, drh.
Regards,
-bch
On 4/28/15, Richard Hipp wrote:
> On 4/28/15, bch w
user 0.04 sys
kamloops$ time fossil pull
Pull from http://pkgsrc.sonnenberger.org
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 335 received: 386 ip: 135.28.13.11
3.21 real 0.00 user 0.04 sys
kamloops$
On 4/28/15, bch wrote:
> On 4/27/
On 4/27/15, Andy Bradford wrote:
> Thus said bch on Mon, 27 Apr 2015 18:33:28 -0700:
>
>> kamloops$ time fossil pull
>> Pull from http://netbsd.sonnenberger.org
>> Round-trips: 1 Artifacts sent: 0 received: 0
>> Pull done, sent: 338 received: 1368 ip: 135
68 ip: 135.28.13.11
* WARNING: a fork has occurred *
use "fossil leaves -multiple" for more details.
5.92 real 3.95 user 0.26 sys
kamloops$
I think an interesting test will be tomorrow w/ the update to the
fossil mirror of the inevitable work that will happe
Apparently the "automatic fork check" is in trunk.
1) On a large repo, this takes an inordinate amount of time. On a
sync (with no updates necessary), the runtime is ~45s (on the first
attempt, I stopped it after ~10 mins of running in order to re-run it
with a time(1) command to collect info) on
On Apr 26, 2015 1:00 PM, "j. van den hoff"
wrote:
>
> On Sun, 26 Apr 2015 19:51:44 +0200, Matt Welland
wrote:
>
>> I like this idea. I will test this branch Monday.
>>
>> +1
>>
>> On Sun, Apr 26, 2015 at 10:16 AM, Jan Nijtmans
>> wrote:
>>
>>> 2015-04-26 12:54 GMT+02:00 Richard Hipp :
>>> > Yes,
For what it's worth, I agree with this. Loading the protocol and/or
"in-band" processing sounds like a horrible error to me. I'd suggest some
"offline" local processing, if anything. Something like:
$ fossil show-forks
That (if this doesn't exist already) will report potential forks that one
can
Note also that you can tailor your diff output w/ "fossil set diff-command"
eg: fossil set diff-command "diff -bu"
On 4/17/15, Warren Young wrote:
> On Apr 17, 2015, at 2:23 PM, to...@acm.org wrote:
>>
>> Can fossil be used to apply a diff patch (such as that created by the diff
>> command)?
>
>
On 4/8/15, Andy Goth wrote:
> On 4/8/2015 1:33 AM, bch wrote:
>> I don't know if it's just me, or if there's a school of thought
>> regarding this, but if this is a case of maintaining symlinks to publish
>> as part of a distribution, I usually relegate their
I don't know if it's just me, or if there's a school of thought regarding
this, but if this is a case of maintaining symlinks to publish as part of a
distribution, I usually relegate their management to a script that will be
part of a release generation process (with "repository != release" in
mind
g dirs. This is dependent on naming convention (ie: naming all
checkouts *kewl* of some sort). (drh -- if you've got different ways
of keeping track of projects' checkouts, I'd love to hear).
Anyway -- I thought this was sufficiently interesting to s
On Mar 31, 2015 8:26 PM, "Matt Welland" wrote:
>
>
>
> On Tue, Mar 31, 2015 at 5:48 PM, bch wrote:
>>
>> Hi Matt.
>>
>> Would picking the branch you care about (like this:
>>
http://fossil-scm.org/index.html/timeline?r=skin-xekri&nd
Hi Matt.
Would picking the branch you care about (like this:
http://fossil-scm.org/index.html/timeline?r=skin-xekri&nd&c=2015-03-25+21%3A52%3A07&n=200)
suit your workflow ?
-bch
On 3/31/15, Matt Welland wrote:
> On Tue, Mar 31, 2015 at 9:20 AM, Andy Bradford
> wrote:
&
+1 circular "nodes", -1 colored lines, as a matter of style, imo.
Really nice work, though!
-bch
On 3/30/15, Richard Hipp wrote:
> James Moger's circular timeline nodes and colored timeline graphs are
> easily selectable "skin" options available to skin
Are you certain you're pointing the same repositories at each other? I.e.:
not trying to sync "Cool Project XYZ" with "Sourdough Bread Recipes"?
On Mar 28, 2015 8:54 AM, "Joe Knapka" wrote:
> And I should have mentioned the Fossil versions:
>
> Laptop A: 1.32 [5811ecd7cc]
> Laptop B: 1.27 [ccdefa
1 - 100 of 162 matches
Mail list logo
