On Sat, Jul 14, 2018 at 05:24:26PM -0600, Warren Young wrote:
> On Jul 14, 2018, at 2:18 PM, Joerg Sonnenberger wrote:
> >
> > On Fri, Jul 13, 2018 at 03:27:14PM -0600, Warren Young wrote:
> >>
> >> For example, 100 a’s requires a 7-bit run-length plus zero
On Fri, Jul 13, 2018 at 02:49:52PM -0700, Jungle Boogie wrote:
> On Fri 13 Jul 2018 4:22 PM, David Mason wrote:
> > So I guess this is what Warren had in mind. Posting this in case it helps
> > somebody on the list.
> >
>
> Taking this offtopic a little bit more...let's talk about VPNs.
>
> Do
On Fri, Jul 13, 2018 at 03:27:14PM -0600, Warren Young wrote:
> On Jul 13, 2018, at 3:13 PM, Warren Young wrote:
> >
> > Now paste in an equivalent number of ‘a’ characters, and you get 0 bits of
> > entropy. Strictly speaking, you get 1 bit of entropy for the whole
> > message, but it shows 0
On Thu, Jul 12, 2018 at 06:06:31PM -0400, Richard Hipp wrote:
> On 7/12/18, Jungle Boogie wrote:
> >
> > openBSD -current x64
>
> I don't have access to such a system for debugging purposes. Can you
> suggest a patch?
-ldl should really only be used on Linux and Darwin. None of the BSDs
needs o
On Fri, Jun 22, 2018 at 02:18:35PM -0400, Richard Hipp wrote:
> Shown below is what I have at the moment. It is more succinct than
> other examples I've seen, but you can easily follow the link for
> details.
BTW, the main mercurial list uses the following mail format for "batch"
changes:
https:
On Fri, Jun 22, 2018 at 09:09:11AM -0400, Richard Hipp wrote:
> When an event occurs (such as a check-in, or wiki-page edit) and a
> user wants a notification of that event, what should the email look
> like?
What I am using for the Mercurial tests is the following:
https://mail-index.netbsd.org/
On Thu, Jun 14, 2018 at 10:44:24PM +0100, Thomas wrote:
> On 2018-06-14 22:37, Joerg Sonnenberger wrote:
> > How do I develop a patch locally and send it to someone for review? The
> > pull request model is kind of stupid and works only for a centralized
> > system (the irony
On Thu, Jun 14, 2018 at 04:51:08PM -0400, Ron W wrote:
> In another forum I follow,a commented claims that Fossil is designed for
> "cathedral development" not "bazaar development", so would be of little
> interest to anyone. Unfortunately, the poster did not elaborate on why.
>
> Except maybe pos
On Thu, Jun 14, 2018 at 09:23:14PM +0100, Thomas wrote:
> On 2018-06-14 20:59, Warren Young wrote:
> > On Jun 14, 2018, at 1:36 PM, Thomas wrote:
> > >
> > > no one wants to see all those in their inbox.
> >
> > Mailing list messages are easily filtered.
> >
> > I have one mailbox for each mail
On Wed, Jun 13, 2018 at 09:10:48AM -0400, Richard Hipp wrote:
> Other issues with GNU MailMan:
>
> (1) Only works with Apache. Or, at least, I have only been able to
> get it to work with apache. That means I have to run a separate
> apache server just to operation MailMan, whereas the rest of S
On Wed, Jun 13, 2018 at 07:28:02AM -0400, Richard Hipp wrote:
> Unfortunately, I'm going to need to shut down this mailing list due to
> robot harassment. I am working to come up with a fix or an
> alternative now. Your suggestions are welcomed.
Does the patch from
https://www.dragonsreach.it/20
On Fri, Jun 08, 2018 at 05:06:23PM +0300, Petr Ovtchenkov wrote:
> During attempt to export fossil's repo (tcl, http://core.tcl.tk/tcl) to git I
> face with
> fast-import (fossil export --git --export-marks ../tcl-fossil/fossil.marks
> ../tcl.fossil | git
> fast-import --export-marks=../tcl-fossi
On Fri, May 18, 2018 at 08:39:15AM +0200, Florian Balmer wrote:
> Also, with "Vary: Cookie", there may be issues with caching proxies,
> depending on whether they receive and evaluate all the cookies, but this
> may not be a problem for Fossil.
Such a proxy would be pretty broken. It has to parse
On Thu, May 17, 2018 at 04:08:18PM -0400, Richard Hipp wrote:
> On 5/17/18, Joerg Sonnenberger wrote:
> > On Thu, May 17, 2018 at 07:02:17PM +0200, Florian Balmer wrote:
> >> So I tried to to generate a "login-time-sensitive" ETag. This worked well
> >> wi
On Thu, May 17, 2018 at 07:02:17PM +0200, Florian Balmer wrote:
> So I tried to to generate a "login-time-sensitive" ETag. This worked well
> with the "cexpire" field from the "user" table (which is actually the login
> time, shifted to the future by one unit of the "cookie-expire" setting).
Would
On Mon, Mar 26, 2018 at 09:50:22AM -0600, Warren Young wrote:
> On Mar 24, 2018, at 5:11 PM, Svyatoslav Mishyn
> wrote:
> >
> > just noticed that page generation of many of my repos is 0.001s.
>
> The calculation for that is in the skin’s Footer code:
>
> [expr {([utime]+[stime]+1000)/1000
On Wed, Dec 27, 2017 at 11:56:31PM +0100, Olivier Mascia wrote:
> > Le 27 déc. 2017 à 23:24, Joerg Sonnenberger a écrit :
> >
> > On Wed, Dec 27, 2017 at 10:10:21PM +, bch wrote:
> >> On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia wrote:
> >>
&
On Wed, Dec 27, 2017 at 10:10:21PM +, bch wrote:
> On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia wrote:
>
> > Hello,
> >
> > Coming from subversion where there is a revision number, incremented by
> > one by each commit,
>
>
>
> Let me be the first of many to say that those centrally cont
On Wed, Nov 29, 2017 at 03:36:07PM -0700, Warren Young wrote:
> On Nov 29, 2017, at 3:10 PM, Joerg Sonnenberger wrote:
> >
> > On Wed, Nov 29, 2017 at 12:02:11PM -0500, Richard Hipp wrote:
> >> On 11/29/17, Jacob MacDonald wrote:
> >>> Ah, I see. It seems
On Wed, Nov 29, 2017 at 12:02:11PM -0500, Richard Hipp wrote:
> On 11/29/17, Jacob MacDonald wrote:
> > Ah, I see. It seems strange to me that the policy didn't get set when I
> > cloned. How can I avoid the same thing in the future and is there any way
> > to change the artifacts in the local rep
On Mon, Nov 27, 2017 at 08:53:06PM -0500, David Mason wrote:
> Does it stay that size with moderate activity, or does it start growing
> significantly?
Incremental fastimport isn't that bad, but occassional repacks would
still help. Of course, github doesn't allow triggering those remotely
and the
On Mon, Nov 27, 2017 at 03:28:37PM -0500, Richard Hipp wrote:
> I didn't try any repacking. I merely ran "git clone" then looked at
> the packfile in .git/objects/pack. You would think that the server
> would want to do an aggressive repack before sending the packfile
> across a clone, to save ba
On Mon, Nov 27, 2017 at 02:28:37PM -0500, Richard Hipp wrote:
> TL;DR: A Git packfile for SQLite is about 52% larger than the
> equivalent content in a Fossil repository.
Did you run repack with aggresive settings? I.e. with -A -d -f and large
--depth and --window-size settings? Especially if the
On Wed, Nov 22, 2017 at 07:01:31PM -0500, Richard Hipp wrote:
> > (2) Store true differential manifests.
>
> I'm thinking that Fossil-NG will probably do like Git and store
> separate artifacts holding the content of each directory. (Git calls
> these "Tree Objects"). I need to do more research,
On Mon, Nov 20, 2017 at 01:33:11PM -0700, Warren Young wrote:
> I see a new wiki article:
>
> https://www.fossil-scm.org/index.html/wiki?name=Fossil-NG
There are two central design flaws in Fossil that affect larger
repositories and those are the repos that primarily benefit from
narrow/shall
On Fri, Sep 08, 2017 at 02:49:16PM +0100, Thomas wrote:
> On 2017-09-08 09:48, Joerg Sonnenberger wrote:
> > On Thu, Sep 07, 2017 at 11:39:39PM +0100, Thomas wrote:
> > > What I mean is, someone who's got that file within the checkout folder
> > > automatically
On Thu, Sep 07, 2017 at 11:39:39PM +0100, Thomas wrote:
> What I mean is, someone who's got that file within the checkout folder
> automatically causes it to be checked in again, independent of what the
> ignore-glob says.
You have to mark it as deleted. Then it will only be checked in (again),
if
On Tue, Aug 15, 2017 at 08:18:08PM +0200, Stephan Beal wrote:
> On Tue, Aug 15, 2017 at 8:09 PM, Steve Schow wrote:
>
> > well I’m hoping to have a version that is stamped into the comments of the
> > actual file as well.
>
>
> Stamping that version would change the hash. To the best of my know
On Tue, Jun 13, 2017 at 02:44:31PM -0500, The Tick wrote:
> Thanks, that is what I was looking for. I've set up a test respository and
> things look good until I get to the final "merge" step:
>
> $ f init F.fossil
> $ f open F.fossil
> $ f add project
> $ f commit --tag 1.5 --branch Official
> $
On Tue, Jun 13, 2017 at 12:17:46PM -0500, The Tick wrote:
> Given a repository based on a previously fetched version of some software
> package and having been modified with local changes, what is the best way to
> update to a more recent version of the upstream package?
The best approach is still
On Sun, Jun 11, 2017 at 08:49:24PM +0100, John Pateman wrote:
> Yes, but its not sourcecode that I am wanting to manage so that won’t wash.
make doesn't care.
Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.
On Sun, Jun 11, 2017 at 08:02:08PM +0100, John Pateman wrote:
> I want to try to find an alternative way with fossil if at all possible.
Use a Makefile and recreate the checked in copy based on the in-progress
copy by filtering?
Joerg
___
fossil-users m
On Mon, May 15, 2017 at 09:15:02AM -0500, Roy Keene wrote:
> Maybe it should open /dev/null and /dev/urandom before chroot()'ing ?
At /dev/urandom doesn't need to be used on newer Linux systems,
getentropy/getrandom provide the same service as system call.
Joerg
__
On Sat, Apr 29, 2017 at 04:23:50PM -0400, Richard Hipp wrote:
> You can further allow users to see hyperlinks without first logging in
> as anonymous by going to Admin/Users and editing the "anonymous" user
> to give that user "hyperlink" privilege. If you do that, though, your
> site will become
On Wed, Apr 19, 2017 at 08:20:00PM -0700, Richard Hipp wrote:
> On 4/19/17, Martin Irvine wrote:
> > I would prefer that Fossil preserved the date and time stamp that the file
> > had when it was most recently committed.
> >
>
> That is an unusual preference, because most people when they do
>
>
On Thu, Apr 13, 2017 at 09:48:59AM -0700, Ryan Dingman wrote:
> While building statically linked binaries on macOS is possible, Apple doesn’t
> officially support it.
You don't need statically linked binaries for this purpose. You only
need to statically link OpenSSL.
Joerg
_
On Thu, Mar 30, 2017 at 04:34:57PM +0200, Stephan Beal wrote:
> On Thu, Mar 30, 2017 at 4:30 PM, Warren Young wrote:
>
> > I don’t think it’s fair to notable Fossil users like Jörg Sonnenberger
> > that we misspell their names simply because we refuse to give up
> > ASCII-centrism.
> >
>
> OTOH,
On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote:
> For someone with a different background, there is *nothing* nice about
> fossil dumping thousands of lines to the terminal. In fact, I think it
> scares off newbies who only used git before.
I quite disagree. Terminal output is C&
On Tue, Mar 21, 2017 at 08:05:33PM -0400, Richard Hipp wrote:
> Those servers are all hosed by OVH at https://www.ovh.com/us/ - to
> whom I have written multiple time and who seem utterly unconcerned.
> Be sure to say bad things about OVH on all your social media posts.
I've filled a complain with
On Fri, Mar 10, 2017 at 12:40:34PM +, Pietro Cerutti wrote:
> On 2017-Mar-10, 12:35, Joerg Sonnenberger wrote:
> > On Fri, Mar 10, 2017 at 11:30:15AM +, Pietro Cerutti wrote:
> > > I would like to change the user associated with commits from
> > > g...@gahr.ch to
On Fri, Mar 10, 2017 at 11:30:15AM +, Pietro Cerutti wrote:
> I would like to change the user associated with commits from
> g...@gahr.ch to simply gahr. Do to that, I updated the 'user' column of
> the 'event' table.
That's not enough. You have to actually "amend" the commit.
Joerg
_
On Thu, Mar 09, 2017 at 01:37:35PM -0700, Warren Young wrote:
> On Mar 9, 2017, at 1:03 PM, Richard Hipp wrote:
> >
> > If a new artifact Y' which has the
> > same SHA1 hash as Y comes along, it will be discarded, since an
> > artifact with that same hash is already in the repository.
>
> That c
On Fri, Feb 24, 2017 at 03:54:56PM -0700, Warren Young wrote:
> On Feb 24, 2017, at 10:37 AM, Joerg Sonnenberger wrote:
> >
> > On Thu, Feb 23, 2017 at 05:01:56PM -0700, Warren Young wrote:
> >> But now we have new data.
> >> Before, this sort of attack was the
On Fri, Feb 24, 2017 at 10:32:20AM -0800, bch wrote:
> Are you saing:
>
> contenthash = sha256(content);
> identifier = sha256 (contenthash . blobtype . conentsize . content);
>
> "blobtype" == cardtype ?
Yes.
Joerg
___
fossil-users mailing list
fossi
On Fri, Feb 24, 2017 at 10:27:11AM -0700, Warren Young wrote:
> What table did I miss updating? Where is “fossil clone” getting the old user
> names from?
From the blob table :)
Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
htt
On Thu, Feb 23, 2017 at 05:01:56PM -0700, Warren Young wrote:
> Second, there will be those who say we’ve covered all of this already,
> multiple times. I know, I was there. But now we have new data.
> Before, this sort of attack was theoretical only. Now it’s not only
> proven possible, it is a
On Thu, Feb 23, 2017 at 06:12:18PM -0500, Martin Gagnon wrote:
> Seems that Git can store both of them, I beleive it calculate the sha1
> on a combination of the filename and the content or something like that.
No, it stores the object type first, which effectively creates a
different block struct
On Thu, Feb 16, 2017 at 02:15:25PM -0800, Ross Berteig wrote:
> I'd argue the problem here is with Git.
Actually, git is not at fault here. We do the export chronologically as
it is much easier to do than computing a topologically sorted output.
Joerg
_
On Thu, Feb 09, 2017 at 10:13:21AM -0500, Richard Hipp wrote:
> On 2/9/17, Joerg Sonnenberger wrote:
> >
> > I disagree. The problem is not on the fossil side and I am not even sure
> > the "specification" of fastexport disallows it. It's really a git issue.
&g
On Thu, Feb 09, 2017 at 01:47:43PM +, Roy Marples wrote:
> Hi List!
>
> In fossil I have this: branch-1.7, tag-1.2
> But when I export I get this: branch_1_7, tag_1_2
>
> Why is the name mangled like so? Surely the original names should be
> preserved.
It's currently preserving only alphanum
On Thu, Feb 09, 2017 at 01:15:51PM +, Roy Marples wrote:
> Hi List!
>
> I have a few repos which I sync to git. However, one of them I noticed
> is no longer syncing tags. The fossil repo is here:
> https://roy.marples.name/projects/dhcpcd
>
> Using fossil-1.37
>
> fossil export --git dhcpcd
On Tue, Dec 20, 2016 at 08:48:27PM +0200, John Found wrote:
> What makes the binary files different from the text files? The presence or
> absence of
> 0 bytes does not seems to make serious difference for processing by the same
> algorithms.
Many text formats allow merging changes from one vers
On Sun, Dec 04, 2016 at 09:23:37PM +0100, Karel Gardas wrote:
> On Sun, Dec 4, 2016 at 8:57 PM, Joerg Sonnenberger wrote:
> > On Sun, Dec 04, 2016 at 08:50:44PM +0100, Karel Gardas wrote:
> >> Otherwise as Nikita recommended, switching off repo checksums helps a
> >>
On Sun, Dec 04, 2016 at 08:50:44PM +0100, Karel Gardas wrote:
> Otherwise as Nikita recommended, switching off repo checksums helps a
> lot, but then make sure you are on the filesystem like ZFS/btrfs which
> does that for you transparently and you do not need to do that on the
> fossil side.
Eh,
On Sun, Nov 20, 2016 at 05:13:56PM +0200, Emil Totev wrote:
> Furthermore, even the old 1.35 binary does not completely work on
> CentOS 7 - 'fossil clone' returns "bad hostname lookup" for otherwise
> perfectly resolvable and pingable hosts.
This part is moderately easy to explain. "Statically"
Dear "K. Fossil user",
it's been said before. Please keep your aggressive attitude and
platitudes to yourself. You are just annoying and distracting people.
Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org
On Mon, Oct 24, 2016 at 02:36:23PM -0600, Warren Young wrote:
> On Oct 24, 2016, at 2:16 PM, Joerg Sonnenberger wrote:
> >
> > On Mon, Oct 24, 2016 at 09:56:45AM -0600, Warren Young wrote:
> >> The only common exception is this recent trend of replacing old,
> &g
On Mon, Oct 24, 2016 at 10:35:46AM -0600, Warren Young wrote:
> As far as I can tell, syncing to a remote repository locks the entire
> remote repository, making it *worse* than Fossil, not better. (SQLite
> concurrency locks only single tables, not the whole database, and then
> only for writes,
On Mon, Oct 24, 2016 at 09:56:45AM -0600, Warren Young wrote:
> The only common exception is this recent trend of replacing old,
> bloated software that grew organically over decades with well-focused
> fresh alternatives. (e.g. BIND vs nsd/unbound, LibreSSL vs OpenSSL,
> Postfix vs Sendmail, etc.
On Sun, Oct 23, 2016 at 07:00:25PM -0400, Ron W wrote:
> I think what K meant was that it has been more than 4 years since the last
> new release of xinetd. I also noticed it was about 7 years to the previous
> release.
>
> I do agree that assuming too much from a project being long time since the
On Sun, Oct 16, 2016 at 03:27:02AM +, K. Fossil user wrote:
> Try to convince people to use Fossil after that : very hard.
Can you please take your negative and hostile attitude somewhere else?
It seems clear now that you have a number of problems on your side.
From a mail server that doesn't
On Sat, Oct 15, 2016 at 01:01:17PM +0900, Osamu Aoki wrote:
> As I see output of "./configure --help" on autoconf/automake based code,
> I see the following:
>
> --enable-silent-rules less verbose build output (undo: "make V=1")
> --disable-silent-rules verbose build output (undo: "make V=0
On Sat, Oct 15, 2016 at 05:59:50AM +0900, Osamu Aoki wrote:
> These 2 files should be the same ... I hoped but reality is a bit
> complicated. They are very similar but the mark field is strange.
No, the marks are derived from the rid and those again depend on the
order in which blobs are added.
On Tue, Oct 04, 2016 at 12:15:58PM -0400, Richard Hipp wrote:
> See https://www.fossil-scm.org/aux-test/doc/trunk/aux.md
>
> Apparently if a Fossil repository contains a file whose basename is
> "aux", then an attempt to open or check-out that repo fails with an
> error. Only the basename needs t
On Wed, Jun 15, 2016 at 09:02:54PM -0500, lvh wrote:
> I’m interested in exploring the possibilities of moving to a Fossil
> monorepo at $dayjob. One of the things I’m not sure how to deal with
> appropriately is dealing with projects managed upstream in some other
> VCS (which, de facto, appears t
On Wed, Jun 01, 2016 at 10:26:17PM -0700, David Simmons wrote:
> 1. The fossil website information on using nginx with fossil is not
> "helpful" in that scgi had numerous problems, and ultimately serving via
> proxy configuration was straightforward and reliable.
This is absolutely not my experien
On Tue, May 31, 2016 at 01:50:01PM +0200, Luca Ferrari wrote:
> So the branch 'feature-installazioni' is closed, and is merged.
> I'm a little confused.
A merge doesn't automatically close a branch, it must be instructed so.
Joerg
___
fossil-users maili
On Mon, May 30, 2016 at 11:49:47AM -0400, Richard Hipp wrote:
> On 5/30/16, Luca Ferrari wrote:
> > Hi all,
> > I suspect I did not get right the multiple open leaf warning:
> >
>
> Maybe the LEAF table in the database file is somehow out of sync.
> Have you tried running "fossil rebuild" to see
On Tue, May 24, 2016 at 07:06:18AM -0600, Warren Young wrote:
> On May 22, 2016, at 2:49 PM, Andy Goth wrote:
> >
> > On 5/22/2016 3:22 PM, Ron W wrote:
> >> The build
> >> systems "knows" how to clean up files it creates. Any other files not
> >> managed by the VCS are the responsibility of the
On Thu, May 12, 2016 at 09:43:34AM +0200, Joerg Sonnenberger wrote:
> On Thu, May 12, 2016 at 12:24:20AM +0200, Marko Käning wrote:
> > How to achieve a git'ish squash when merging a (private) branch into trunk?
>
> You can use update+commit to get the effect.
checkout+comm
On Thu, May 12, 2016 at 12:24:20AM +0200, Marko Käning wrote:
> How to achieve a git'ish squash when merging a (private) branch into trunk?
You can use update+commit to get the effect.
Joerg
___
fossil-users mailing list
fossil-users@lists.fossil-scm.or
On Tue, May 10, 2016 at 10:34:29AM -0700, Christopher M. Fuhrman wrote:
> I've noticed that the .fslckout file can grow exceptionally large,
> especially for larger repositories such as pkgsrc[1].
I think the real problem is that update is rewriting the mtime table,
isn't it?
Joerg
__
On Sat, Apr 30, 2016 at 11:30:08PM -0600, Scott Robison wrote:
> Note that you have to merge mybranch back to trunk, otherwise all the
> changes made in mybranch will live happily over there forever. Once you
> updated to trunk, you abandoned all committed work from the other branch.
You can also
On Mon, Apr 25, 2016 at 05:22:54PM +0200, Stephan Beal wrote:
> Yes, colorization is commonly-request feature, but is also not trivial to
> do portably, which is probably why relatively few people are interested in
> implementing it.
Uses terminfo is not that difficult and there are even separate
Hi all,
while working on an update for my cvs2fossil tool, I was doing some
mistakes ^W^W^W fuzzing the output and able to reliably crash fossil.
In rebuild_step, blob_delta_apply is called without checking the return
value. If the delta is for some reason valid compressed data, but not a
valid del
On Thu, Apr 14, 2016 at 03:32:48PM -0600, Warren Young wrote:
> STEP 1: Split your “server” configurations
I don't think this is necessary at all.
> STEP 2: Prepare for the Let’s Encrypt challenge/response sequence
This part can just statically go into the same server block, no need for
a separa
On Thu, Dec 17, 2015 at 08:39:03PM -0300, Richie Adler wrote:
> El 17/12/2015 a las 17:28, Ross Berteig escribió:
>
> > On 12/16/2015 6:42 PM, Ron W wrote:
>
> >> Would be nice if there was a "fossil ticket export" command that would
> >> produce a "proper" CSV file. While "proper" is still some
On Thu, Dec 17, 2015 at 06:57:06PM +0300, Konstantin Khomoutov wrote:
> On Thu, 17 Dec 2015 13:16:43 +0100
> Joerg Sonnenberger wrote:
>
> > Now the tricky part is this can be done *without rewriting history*.
> > Essentially, you can (semi-automatically) reapply all chan
On Thu, Dec 17, 2015 at 02:43:56PM +0300, Konstantin Khomoutov wrote:
> On Wed, 16 Dec 2015 14:28:39 -0700
> Scott Robison wrote:
>
> [...]
> > I realize that 'get rebase -i' gives a lot more tools, but couldn't
> > 99% of rebase use cases be handled with private branches?
>
> `git rebase` is ab
On Sun, Dec 13, 2015 at 09:57:44PM +0100, Piotr Orzechowski wrote:
> I guess it would be better to change help message about rebuild then.
> As of now, it says "Run this command after updating the fossil
> executable in a way that changes the database schema." So I would
> expect to see some inform
On Fri, Dec 11, 2015 at 01:54:21PM -0700, Warren Young wrote:
> On Dec 11, 2015, at 1:38 PM, jungle Boogie wrote:
> >
> > Man page for tar:
> > http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/tar.1?query=tar
>
> Scroll down to AUTHORS and HISTORY: it’s not bsdtar.
>
> Pity.
>
> Net
On Thu, Dec 10, 2015 at 03:59:29PM +0100, Daniel Dumitriu wrote:
> Still there seems to be another problem with fossil: it does not pass
> the password to plink when it was given on the command line as in
> user:pass@host:port. Maybe something along these lines ("-p pass")?
I would call that a sec
On Wed, Dec 02, 2015 at 05:54:06AM -0500, Richard Hipp wrote:
> On 12/2/15, j. van den hoff wrote:
> >
> > thank you. sorry if this has been discussed/explained before: this means,
> > there still is demand for that option? why? is there still a bug out
> > there? because if not, it seems whatever
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 Darcs had quite a bit of write up when I looked a dec
On Tue, Oct 27, 2015 at 05:01:09PM -0400, Ron W wrote:
> On Tue, Oct 27, 2015 at 4:29 PM, Abilio Marques wrote:
> ...
>
> > As far as I can see, binary files get uploaded into a web server using
> > PUT, and then a reference is made into the repo. That way git doesn't deal
> > with useless DIFFs
On Sat, Oct 03, 2015 at 03:36:03PM +0200, Eduardo Morras wrote:
> When I go to http://www.sqlite.org//src/doc/trunk/README.md instead of
> http://www.sqlite.org/src/doc/trunk/README.md, the page loads without
> css and link I follow don't load it neither and the additional '/' is
> not corrected.
On Mon, Sep 28, 2015 at 10:12:25PM +0200, David Given wrote:
> There ought to be a cleverer way to do this than just relying on the
> timestamp (which can be wrong). Isn't there an SQL example which uses a
> recursive query to walk the commit tree? That way we'd be guaranteed to
> get a correct ord
On Fri, Sep 11, 2015 at 04:57:46PM -0600, Warren Young wrote:
> I wonder if this is an implementation detail leaking through into the
> UI, though. Under what conditions, except for Noam’s contrived example
> with hardcoded dates, is there a useful distinction between “hash” —
> implying a number
On Sun, Jul 19, 2015 at 10:45:29AM +0300, Alexey V Gorshkov wrote:
> sorry, missformatted command sequence text
>
> mkdir fos
> cd fos
> fossil init
> test.fossil
> mkdir t
> cd t fossil
> open ../test.fossil
> fossil pull
> ../test.fossil
Assuming this is "fossil open ../test.fossil; fossil pull
On Tue, Jul 14, 2015 at 09:51:20AM +0200, j. van den hoff wrote:
> incidentally I'm using nearly exactly the same approach including the call
> to `status' (as I was under the same misconception that it should be the
> "most efficient" way to get at the sha1 hash). so I have just switched to
> `inf
On Tue, Jun 23, 2015 at 01:40:04PM -0700, bch wrote:
> Ugh. Again, include fossil-users@
Right, that's the situation I meant. fossil should be retrying with the
next set of missing changes and not stop when it can no longer make
progress on the current set.
Joerg
_
On Tue, Jun 23, 2015 at 12:31:20PM -0700, bch wrote:
> I tried that (and sent response that only went to Andy (which I think
> is not first time has happened between Andy, fossil-users, and
> myself)).
>
>
> kamloops$ fossil pull --httptrace
> Pull from http://netbsd.sonnenberger.org
> Round-trip
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 --httptrace which will reveal the HTTP transactions
> during the pull operation (e.g. what was sent/received).
On Tue, Jun 23, 2015 at 11:33:31AM -0700, bch wrote:
> Still no dice:
>
> kamloops$ fossil pull --verbose
> Pull from http://netbsd.sonnenberger.org
> Bytes Cards Artifacts Deltas
> Sent:9546202 0 0
> Received: 78 2
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)?
Likely. As I said, I don't really know why it sometimes creates those :(
Joerg
___
On Mon, Jun 22, 2015 at 01:44:12PM -0700, bch wrote:
> W/ latest fossil from tip of [trunk], a pull now looks roughly like
> this (note, no reported errors or warnings, no looping like before,
> but still not actually working properly):
Well, I've rebuild the repository, so it should have no artif
On Thu, Jun 18, 2015 at 01:45:24PM -0400, Ron W wrote:
> On Wed, Jun 17, 2015 at 3:17 PM, Joerg Sonnenberger > wrote:
>
> > On Wed, Jun 17, 2015 at 12:10:36PM -0400, Richard Hipp wrote:
> > > On 6/17/15, Jan Danielsson wrote:
> > > >Out of curiosity; wh
On Wed, Jun 17, 2015 at 12:10:36PM -0400, Richard Hipp wrote:
> On 6/17/15, Jan Danielsson wrote:
> > On 17/06/15 11:38, Joerg Sonnenberger wrote:
> > [---]
> >> Sadly, a plain pull is not 100% read-only, so WAL doesn't help avoiding
> >> such problems.
&
On Tue, Jun 16, 2015 at 11:04:07PM -0700, Matt Welland wrote:
> We see these (or similar) occasionally when the filesystem gets slow. The
> problem is exacerbated with large repos.
It's possible to hit one of the hidden master -> public repo pushes,
they can take a bit as the disks are generally b
On Mon, Jun 08, 2015 at 02:07:36PM -0700, bch wrote:
> unclear what I should check -- you mean measure blob sizes in the
> sqlite db, or tcpdump or some fossil option w/ another "pull" attempt
Right, the entry in the blob table.
Joerg
___
fossil-users m
1 - 100 of 281 matches
Mail list logo
