[fossil-users] service instability

[bch]

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@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] branch assistance needed

[bch]

On Tue, Jul 3, 2018 at 2:09 PM Dewey Hylton  wrote:

> I've used fossil for years now with lots of commits to trunk and very few
> very simple branches which tend to get merged right into trunk after only a
> few commits. I have managed to get myself in a confusing place with one of
> my projects.
>
> Essentially what I did was to commit a change to a new branch, forget I
> was in that branch and committed another unrelated change which should have
> gone back to trunk but went into the branch. I then attempted to change
> that latest commit by adding a 'trunk' tag and cancelling the new branch
> tag. I'm pretty sure that was wrong, but I'm unsure now where to go with
> this. I've tried a few other things to no avail, but now even after
> executing 'fossil update trunk' the 'fossil branch' command shows 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 latest commit (to stash??)”
functionality if the (apparently fiddly) touched pieces could all be
identified.

-bch



> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Mailing list shutting down...

[bch]

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
> >> via web-form only.
> > If you do this atop Fossil, then you end up inches away from being able
> to provide an oft-wanted feature: email notifications on checkins, wiki
> article changes, and other Fossil events.
> One way to implement that is to incorporate SMTP into Fossil directly.
> Recently, I started working on that using my smtp.h and smtp.c:
>

Attractive as that may sound, do we really want to be another (near)
instance of Zawinski’s Law?

https://en.wikipedia.org/wiki/Jamie_Zawinski?wprov=sfti1




> https://www.somnisoft.com/smtp-client/artifact/f820e6e88d9c3948
> https://www.somnisoft.com/smtp-client/artifact/12ee754f88640cb1
> https://www.somnisoft.com/smtp-client
>
> Git has a 'git-send-email' command so I add a 'fossil email' command as
> a starting point.
>
> https://git-scm.com/docs/git-send-email
>
> I can also add an 'Email Settings' link in the fossil admin settings
> menu which would allow the admin to set the mail server settings. I can
> provide diff for that later this week, if the fossil devs think this is
> heading in the right direction.
>
> Does this sound like a good idea for Fossil?
>
> -James
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[bch]

On Wed, Dec 27, 2017 at 2:23 PM Olivier Mascia <o...@integral.be> wrote:

> > Le 27 déc. 2017 à 23:10, bch <brad.har...@gmail.com> a écrit :
> >
> > On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia <o...@integral.be> 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 controlled
> increments are not possible in a *distributed* source control system. Maybe
> a “feature branch” and your own heuristics would fit the bill?
>
> Brad, I think I know that and wrote it in my message.


So you did, my apologies.

The chain-length method Joerg mentioned is roughly what I was thinking,
bounded to a single branch “namespace” to manage disambiguation. Mind, this
is off the top of my head, not a thing I’ve implemented.

Kind regards,

-bch



> The question was indeed about my proposed heuristic to use the count of
> check-ins:
>
> > Of course this characteristic (a sequential revision ID) is logical in a
> centrally managed system as subversion and is less trivial in distributed
> scm like fossil or git.
> >
> > I'm considering replacing the subversion revision ID, for the purpose of
> defining the file version ID (as above) at release-external build time, by
> the count of check-ins in the root repository.  That is the count returned
> by 'fossil info' in one of the multiple lines of output (for instance
> 'check-ins: 8801').
> >
> > The full version string (as "1.2.4.8801") would then be automatically
> added as a tag to the most recent check-in on trunk (from which the build
> is derived).
> >
> > How does that sound to those of you who might have had similar concerns?
> > Been there and rushed away? Or happy to stay?
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Replacing subversion revision number... by what?

[bch]

On Wed, Dec 27, 2017 at 2:06 PM Olivier Mascia <o...@integral.be> 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 controlled
increments are not possible in a *distributed* source 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 -> version x.y.z.8789
>
> The x.y.z is incremented by hand when it means something (release of some
> tested version). But for the lifetime of a version, there might be some
> newer builds (small fixes) and they will be auto-tagged with the revision
> ID as last part of the full version number.
>
> In real life this can lead to sequences of file version numbers as:
>
> 1.2.3.8745
> 1.2.3.8749
> 1.2.4.8801
> ...
>
> This has many advantages, not the least being to easily spot which among
> two binaries is more up to date (has simplifications in setup systems). The
> main limitation is that (on Windows) those 4 parts of a full file version
> id are each limited to 16 bits.  Limiting this model to about 65.000
> revisions.  After which some offset should be applied (which is easy to do
> every time the first 3 values are hand changed).
>
> Of course this characteristic (a sequential revision ID) is logical in a
> centrally managed system as subversion and is less trivial in distributed
> scm like fossil or git.
>
> I'm considering replacing the subversion revision ID, for the purpose of
> defining the file version ID (as above) at release-external build time, by
> the count of check-ins in the root repository.  That is the count returned
> by 'fossil info' in one of the multiple lines of output (for instance
> 'check-ins: 8801').
>
> The full version string (as "1.2.4.8801") would then be automatically
> added as a tag to the most recent check-in on trunk (from which the build
> is derived).
>
> How does that sound to those of you who might have had similar concerns?
> Been there and rushed away? Or happy to stay?
>
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten,
> Olivier Mascia
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [Bug?] [server] Processes of Fossil popping up unexpectedly

[bch]

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.
>
> Problem #1 could be fixed (in principle) without any more help from you,
> Oliver: PIDs 888 and 893 are zombies, meaning Fossil is forking off
> children without calling wait() on them.  That’s why their VIRT column
> shows as 0 in your screenshot: the kernel has stripped all resources from
> them it can, and is holding onto only the exit status and such for the
> parent’s benefit.  This is a bug in Fossil, plain and simple.
>
> That said, zombies are nearly harmless, merely adding noise to the process
> table.  They don’t explain your actual symptom.
>
> The remaining PIDs are all certainly a single parent with multiple
> children.  You’d have to run top in “tree” mode or show the PPID column to
> find out which one is the parent.  You can tell without doing that by the
> fact that all of the VIRT column values are identical, meaning that within
> the limits of top’s reporting resolution, the children are allocating no
> dynamic virtual memory of their own, which is what we’d expect from a
> forking HTTP child-per-conn model.
>
> Given all of that, I’d just pick one of the PIDs and attach to it:
>
> $ gdb -p 26819
>
> If that works, say “bt” when attached, then “quit” to detach again.  Post
> the backtrace output here, Oliver.
>
> If it doesn’t work, it’s probably due to lack of debugging permission on
> the target system, in which case you’ve got some sysadminning ahead of you,
> not on topic here.
>
> But, this does not look like a madly-spinning system.  The CPU is idle and
> the PIDs are pretty far apart.
>


Does contemporary Linux not randomize its PIDs?


> Basically, it’s looking like each one is the result of an HTTP transaction
> and the child just isn’t dying at transaction end as it should.  This
> should only be a serious problem when the children collectively hold so
> many resources that the system can’t run properly.
>
> Bottom line, I don’t think the top output explains the problem.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] blame/annotate webview not working for me.

[bch]

On Sun, Dec 17, 2017 at 8:40 PM bch <brad.har...@gmail.com> 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; NetBSD amd64; rv:57.0) Gecko/20100101
> Firefox/57.0) I get this:
>
>
> The connection was reset
>
> The connection to the server was reset while the page was loading.
>
>
> Has anybody else seen something like this?
>

I bisected and during the course of checkouts, must have ‘jiggled’ a src
file to trigger the right rebuild so the “problem” binary (now rebuilt)
works fine.

-bch


> Cheers,
>
> -bch
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] blame/annotate webview not working for me.

[bch]

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; NetBSD amd64; rv:57.0) Gecko/20100101
Firefox/57.0) I get this:


The connection 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/listinfo/fossil-users

Re: [fossil-users] More timeline changes

[bch]

On Sat, Nov 25, 2017 at 7:26 AM <sky5w...@gmail.com> wrote:

> "​(2) Decluttered should be the default."
> I agree clutter should not be default?​
> I would drop that term altogether.
>

Simplified vs detailed would probably be more appropriate words. I do like
the “files” toggle in the “cluttered” mode, though.


-bch



> On Sat, Nov 25, 2017 at 8:47 AM, Richard Hipp <d...@sqlite.org> 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 screen.  In the simplified timeline,
>> there is a "Details" button to get all the details back again.
>>
>> I'm not done with this interface improvement push.  Here are my
>> short-term plans:
>>
>> (1) Right now, pressing "Declutter" or "Details" is a server
>> round-trip.  I think it would better to handle this using javascript.
>>
>> (2) Decluttered should be the default.  Currently Details is the
>> default.  I spent a lot of time experimenting last night, and what I
>> found myself doing every time I encountered a timeline was immediately
>> pressing the "Declutter" button to get a high-level overview of the
>> graph, then clicking on "Details" if I wanted to see more.  From that
>> experience, I think coming up in Decluttered mode would be a much
>> better approach.
>>
>> (3) Details/Declutter for the entire graph is good and should be kept.
>> But it would be even better to be able to see the details of
>> individual timeline entries.  I'm thinking that timelines come up in
>> decluttered mode (showing only the check-in comment for each entry)
>> but with ellipses or some other small icon at the end of each comment
>> that you can click on to expand the details.
>>
>> You can help!  Send me your ideas of what you think timelines should
>> look like.  Even better:  send me mock-ups.  Static HTML pages that
>> you have hand-edited will be fine - just be sure to include the CSS,
>> or better, put all the CSS in-line on your hand-edited mockup.
>>
>> You can also keep experimenting with the code I have on-line and send
>> me your complaints and suggestions for improvement.
>>
>> Web developers - help me with this:  For item (3) above, how can I
>> make the ellipsis or icon to "show more detail" configurable using
>> CSS?  What's the best way to handle that so that people can customize
>> the look for various skins?
>>
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] A-B comparison of proposed timeline changes

[bch]

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 end, rather than before the
> > check-in comment.  The omission of that information is a bug.
>
> Now fixed.
>
> Other changes on https://www.fossil-scm.org/b/timeline since the
> original comparison request:
>
>   (1)  The "details" section is shown on a separate line below the
> check-in comment.
>   (2)  The "details" are in the same font-color as the comment-text
> but have a slightly reduced font size.
>

I don’t see that reflected on the link. Perhaps consider a .gif snapshot of
the effects so it’s not subject to code change on a live system, and
annotatable if necessary?



> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG Bloat?

[bch]

On Wed, Nov 22, 2017 at 3:11 PM bch <brad.har...@gmail.com> wrote:

>
> On Wed, Nov 22, 2017 at 3:10 PM <bytevolc...@safe-mail.net> wrote:
>
>> On Wed, 22 Nov 2017 17:30:10 +
>> Javier Guerra Giraldez <jav...@guerrag.com> 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 such systems, but rather, they
>> use other systems that can compile for the target system.
>>
>> > but i haven't seen any reason to promote a language switch.   nice as
>> > they are, C11 features make only easier development; not better code,
>> > much less any performance improvement or any user-visible advantage.
>>
>> I am not suggesting a language switch (C11 is still C) and I'm also
>> not suggesting just use C11 for the sake of it. Rather, I am suggesing
>> using modern C features to clean up the code and allow the compiler to
>> optimise it better. For example, postponed variable declarations,
>> inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
>> it's all basic C99 functionality which has been around for 18 years.
>>
>> > SQLite _is_ used on lots of weird targets, and there's much shared
>> > code, and most importantly, shared code style.  introducing an
>> > artificial split between them doesn't seem a good use of developer
>> > time.
>>
>> What sort of weird targets does SQLite run on which require the use of
>> a very old (or broken) compiler that can't handle any C99 features?
>
>
I don’t have access anymore, but I have supported “obscure” operating
systems on old hardware before for important production work. I wish I
could recall what the vintage of the required native compiler. Maybe it
*would* have passed C99 requirements. Some people will definitely know, but
for those that don’t, it’s important to know that all the Unix world is not
a modern Linux box.



>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Fossil-NG Bloat?

[bch]

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 such systems, but rather, they
> use other systems that can compile for the target system.
>
> > but i haven't seen any reason to promote a language switch.   nice as
> > they are, C11 features make only easier development; not better code,
> > much less any performance improvement or any user-visible advantage.
>
> I am not suggesting a language switch (C11 is still C) and I'm also
> not suggesting just use C11 for the sake of it. Rather, I am suggesing
> using modern C features to clean up the code and allow the compiler to
> optimise it better. For example, postponed variable declarations,
> inline functions, stdint.h definitions, etc. This isn't even C11 stuff,
> it's all basic C99 functionality which has been around for 18 years.
>
> > SQLite _is_ used on lots of weird targets, and there's much shared
> > code, and most importantly, shared code style.  introducing an
> > artificial split between them doesn't seem a good use of developer
> > time.
>
> What sort of weird targets does SQLite run on which require the use of
> a very old (or broken) compiler that can't handle any C99 features?
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[bch]

On Aug 16, 2017 12:54, "Stephan Beal" <sgb...@googlemail.com> wrote:

On Wed, Aug 16, 2017 at 9:19 PM, bch <brad.har...@gmail.com> wrote:

>
>
> On Aug 16, 2017 12:10, "Stephan Beal" <sgb...@googlemail.com> wrote:
>
> It's hypothetically possible, and i investigated it 3 or 4 years ago, but
> the devil is in the details :/. Not impossible, but you have to take care
> of details like properly undelta'ing anything which is deltad against the
> to-be-popped head.
>
>
>
> Oh - I didn't realize that's the direction the deltas worked...
>


Fossil tries to keep the undelta'd copy at the head, since it's the one
most likely to be accessed. That's not a guaranty, though - just a
preference/habit. Thus if you pop the head, you need to make sure and go
undelta all artifacts in that head which are not referenced by anything
else in the tree.


>
> At the time i wasn't confident enough in my knowhow of the internals to
> implement it. Also, it would only work up until you push to a remote, at
> which point all bets are off.
>
>
> Well... I suspect that'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.
>

Right. i believe there are certainly uses for it.

Another detail i forgot about earlier is the handling of branches: you can
only pop  from the tip of any given branch and only if no other branch
derives from that point in the branch. As soon as something derives from
what you want to pop, you have to go pop all that off first. When i
realized how ugly that gets, i stopped researching an implementation :/.


That doesn't sound unreasonable. Sort of doubly-constrained 1) from newest
to older, per branch 2) on conflict, retarget branch, go-to 1

Right?



-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[bch]

On Aug 16, 2017 12:10, "Stephan Beal" <sgb...@googlemail.com> wrote:

It's hypothetically possible, and i investigated it 3 or 4 years ago, but
the devil is in the details :/. Not impossible, but you have to take care
of details like properly undelta'ing anything which is deltad against the
to-be-popped head.



Oh - I didn't realize that's the direction the deltas worked...

At the time i wasn't confident enough in my knowhow of the internals to
implement it. Also, it would only work up until you push to a remote, at
which point all bets are off.


Well... I suspect that'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
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Aug 16, 2017 20:30, "bch" <brad.har...@gmail.com> wrote:

>   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/17, Stephan Beal <sgb...@googlemail.com> wrote:
> > On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal <sgb...@googlemail.com>
> > wrote:
> >
> >> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow <st...@bstage.com> wrote:
> >> > Is that possible at all or if not, what is the best way to handle that
> >> kind of situation with fossil?
> >>
> >> Fossil is designed to never forget anything, not even mistakes. It's
> >> possible to move a commit to a new branch, thereby "kind of hiding it",
> >> but
> >> not to remove it.
> >>
> >
> > Lol - seems we were all typing at the same time.
> >
> > --
> > - stephan beal
> > http://wanderinghorse.net/home/stephan/
> > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> > those who insist on a perfect world, freedom will have to do." -- Bigby
> > Wolf
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] backing out an incorrect commit?

[bch]

  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/17, Stephan Beal <sgb...@googlemail.com> wrote:
> On Wed, Aug 16, 2017 at 8:15 PM, Stephan Beal <sgb...@googlemail.com>
> wrote:
>
>> On Wed, Aug 16, 2017 at 7:59 PM, Steve Schow <st...@bstage.com> wrote:
>> > Is that possible at all or if not, what is the best way to handle that
>> kind of situation with fossil?
>>
>> Fossil is designed to never forget anything, not even mistakes. It's
>> possible to move a commit to a new branch, thereby "kind of hiding it",
>> but
>> not to remove it.
>>
>
> Lol - seems we were all typing at the same time.
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
> those who insist on a perfect world, freedom will have to do." -- Bigby
> Wolf
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two easy questions

[bch]

On Aug 15, 2017 11:49, "Stephan Beal" <sgb...@googlemail.com> wrote:

On Tue, Aug 15, 2017 at 8:47 PM, Joerg Sonnenberger <jo...@bec.de> wrote:

> On Tue, Aug 15, 2017 at 08:18:08PM +0200, Stephan Beal wrote:
> > Stamping that version would change the hash. To the best of my knowledge
> > that feature cannot be implemented with DVCS (which requires hashing
> > (non-serial IDs) for versioning).
>
> It can be done, just replace the keyword expansion with a canonical form
> whenever hashing the content. Keeping the original hash and the hash of
> the expanded form allows faster working copy 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/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Using fossil across OSes

[bch]

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 your system so that you have multiple hard
lines to the same repository database file.


Do you mean hardlinks, or something else?

I'm not sure how you've
done that.  But it can lead to repository database corruption if you
attempt to write to database.  For that reason, Fossil does not allow
you to write.

On 7/27/17, jerson  wrote:
> No.
>
> Each project is in its own folder.  In the project folder is the project
> fossil.  With Windows, the config database (_fossil) is located at
> "Documents and settings\User\Application Data" on the C: drive.   With
> Linux, the config database (.fossil) is located in the $HOME folder.   I
> am not sure if the error relates to the config database (global
> repository in OP) or something else.
>
>
> To check, I created a new fossil under Linux.  I was able to do
> everything it is supposed to do.  Now, trying to open this file under
> Windows, It gives me an error.
>
>
> On Wednesday 26 July 2017 03:20 PM, Richard Hipp wrote:
>> On 7/25/17, jerson  wrote:
>>> Greetings,  fossil newbie here.
>>>
>>> I have used fossil on WinXP for quite sometime now and have many
>>> separate fossils project wise.  Now, I have switched my os to Linux
>>> Mint.  Fossil is able to open the existing fossils created under
>>> windows, but I am unable to make any changes to them.  The typical error
>>> I get is
>>>
>>> SQLITE_WARNING: multiple links to file: /media/path/to/project.fossil
>> Do you have the repository file on a network filesystem of some kind?
>>
>
> --
> Regards
> Jerson Fernandes
> Embedded Systems Designer
> http://jerson.co.in
>
>


--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Couple of beginner questions

[bch]

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 fossil to stop complaining about my file,
and I've learned some more about the intricacies of language support.

I never meant to start another editor war -- I thought that was over when
the vi vs. emacs debate finally died years ago.

Now its been suggested that I not only change my editor, but my keyboard,
my programming language, my OS, and even to buy a new computer from a
different manufacturer. While I suppose that might move the world closer to
perfection, but I've been around long enough to know that will never happen.

If I knew Mr. Sonnenberger personally, I might, out of consideration for an
acquaintance, reach out and ask how I might be able to spell his name
correctly. I would hope that his response would not be to insist that I
change editors, keyboard, etc. I also strongly suspect that he would feel
the same were the situation reversed.

Anyway, thanks again to those people who helped me. At this point I don't
find this thread going anywhere productive and I'm sort of sorry for
starting it.


It's interesting, and that's reason enough for it.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PROPOSED FEATURE] Fossil 'branch' command displays only current branch by default

[bch]

On Mar 27, 2017 10:40, "Christophe Gouiran" <bechris13...@gmail.com> wrote:

Hello everybody,

Amount of branches may be quite important (in Fossil code itself, there are
now about 100 branches).
In this case, executing "fossil branch" to get the current branch is not
very convenient to me.


Note 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
any subcommand.

All other subcommands (info, list|ls, info) are left unmodified.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Google Security Blog: Announcing the first SHA1 collision

[bch]

On 2/27/17, Warren Young <war...@etr-usa.com> wrote:
> On Feb 26, 2017, at 2:58 PM, Stephan Beal <sgb...@googlemail.com> wrote:
>>
>> just FYI, Linus' own words on the topic, posted yesterday:
>>
>> https://plus.google.com/u/0/+LinusTorvalds/posts/7tp2gYWQugL
>
> Point #1 misses the fact that people *do* rely on Git hashes for security.
> Maybe they’re not “supposed” to, but they do.
>
> For example, the CentOS sources are published through Git these days, rather
> than as a pile of potentially-signed SRPM files.  This means the only
> assurance you have that the content checked into 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 inspected one of their repos, and it doesn’t use GPG signed
> commits, so the hashes are all you’ve got.)
>
> This is adequate security today, but once bad actors can do these SHA1
> attacks inexpensively, it’ll be a problem if git.centos.org is still relying
> on SHA1 hashes.
>
>
> Point #2 is also questionable.  Torvalds is assuming that any collision
> attack on a Git checkin will be detectable because of the random noise you
> have to insert into both instances to make them match.
>
> Except that you don’t have to do it with random noise.
>
> Thought experiment time: Given that it is now mature technology to be able
> to react to a useful subset of the spoken English language either over a
> crappy cell phone connection or via shouting at a microphone in a canister
> in the next room, complete with query chaining (e.g. Google Now, Amazon
> Echo, etc.) how much more difficult is it to write an “AI” that can
> automatically generate sane-looking but harmless C code in the middle of a
> pile of other C code to fuzz its data bits?
>
> I have no training in AI type stuff, but I think I could do a pretty decent
> job just by feeding a large subset of GitHub into a Markov chain model.  Now
> imagine what someone with training, motivation, and resources could do.
>
> Or, don't imagine.  Just go read the Microsoft Research paper on DeepCoder:
>
>https://news.ycombinator.com/item?id=13720580
>
> I suspect there are parts of the Linux kernel sources that are
> indistinguishable from the output of a Markov chain model. :)  *Someone*
> allowed those patches to be checked in.
>
>
> As for his point #3, he just offers it without support.  He says there’s a
> plan.  Well, we have a plan, too.  Plans are easy.  Execution is the hard
> part.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Google Security Blog: Announcing the first SHA1 collision

[bch]

Are you saing:

contenthash = sha256(content);
identifier = sha256 (contenthash . blobtype . conentsize . content);


"blobtype" == cardtype ?

-bch



On 2/24/17, Joerg Sonnenberger <jo...@bec.de> wrote:
> 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 already within the ROI budget for certain
>> specialized attacks; attacks only get cheaper over time.
>
> Actually, the only thing that changed is that the attack now has a
> decent price tag. That's really not all that much, contrary to all the
> ranting going on right now.
>
> Fossil had "hash collissions" issues for a long time and I'm not even
> talking about this kind of issues. It might be a good idea to change the
> storage format for new blobs and optionally provide a one time
> conversion option. But I don't have the time to implement that.
>
> The new stored blob should be:
> - hash of the rest of the blob
> - blob type
> - content size
> - content
>
> The idea is that object id is the hash of everything. This should be
> much more resilient to preimage attacks based on the block structure of
> the hash function. I haven't had a chance to talk with a real
> cryptographer about this yet, though. Including the blob type makes it
> more robust and can significantly cut down in the parsing time on
> rebuilds. Including the content size is just another way of making
> meaningful preimage attacks somewhat harder.
>
> Joerg
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Google Security Blog: Announcing the first SHA1 collision

[bch]

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.html
>

Also, Here's a related discussion from git mailing list:
  https://marc.info/?t=14878688461=1=2

Somebody tried those 2 colliding pdf's on a git repository:
  https://github.com/joeyh/supercollider

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.

So I was curious and I tried to put them on a fossil repository.


  Here what I got (with repo-cksum enabled):
  --
$ ls
bad.pdf  good.pdf

$ sha1sum bad.pdf good.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf

$ fossil add bad.pdf
ADDED  bad.pdf

$ fossil add good.pdf
ADDED  good.pdf

$ fossil commit
[***] Current default user: mgagnon
vim "./ci-comment-A70B84D400D2.txt"
./bad.pdf contains binary data. Use --no-warnings or the
"binary-glob" setting to disable this warning.
Commit anyhow (a=all/y/N)? a
New_Version: 510b26ef49be508003304840a9ea18894007ad51
ERROR: [good.pdf] is different on disk compared to the repository
NOTICE: Repository version of [good.pdf] stored in
[file-3a8b62456795ffdb]
working checkout does not match what would have ended up in the
repository:  2106b982989e5604ec91523ddd81c879 versus
a388ff244a318ee5904ba276b754d84a
  -

Seems that repo-cksum give an extra protection against this kind of
collision. (but don't let the file goes in...)

Then, I tried with repo-cksum disabled.

  1- I add good.pdf and commit.
  2- I add bad.pdf and commit (it succeed)
  3- I check with "fossil ui" and both files share the same content
 (good.pdf)

At least, if a file with a certain sha1 hash exist on a repo, a
malicious file with the same sha1 hash should never goes in.


Or more correctly, "a *subsequent* file with the same sha1 hash..." If you
happened to commit the Trojan file first, the "good" commit would have been
the one to fail.


I'm not an expert in encryption and security: I agree that the
possibility of sha1 collision is not a good thing, but it's probably not
the end of the world and it doesn't make fossil un-usable.

  side note: A collision is a lot easier to produce on a file like a pdf
 than on a source file.

"That's why pdf's are the classic model for showing
these attacks: it's easy to insert garbage in the
middle of a pdf that is invisible."

-- git mailing list citation

Regards,

--
Martin G.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bug in "fossil branch new"

[bch]

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" <d...@sqlite.org> wrote:

> On 2/6/17, Richard Hipp <d...@sqlite.org> wrote:
> >
> > That is correct, and it is by design.  Fossil allows any number of
> > branches to share the same name.
>
> On second thought, perhaps it would be worthwhile to enhance Fossil so
> that it issued a warning if you include a --branch argument on "fossil
> commit" with the same name as an existing open branch, and actually
> fail the commit unless the --force flag is also present.  Perhaps such
> a change would make Fossil easier to transition to from other systems.
> Does anybody else having any feelings one way or another about this?
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] incorrect user info in export --git

[bch]

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.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] EXECUTABLE, and not really being added to updated repo

[bch]

On Dec 7, 2016 09:13, "Will Parsons" <varro@nodomain.invalid> 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 retried w/ a --sha1sum switch; still listed as changed
> (despite the new commit showing up in the "f timel"). touch(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.

What kind of filesystem?  Apparent dicrepancies in the executable bit
can show up if the filesystem doesn't support proper permissions.



NetBSD is a fully fledged UNIX... I'm using FFS (fast file system), which
is a traditional *BSD filesystem. For completeness' sake, it's FFSv2 with
wapbl journaling enabled, but that shouldn't be a factor.

I've been using fossil for years in this sort of environment, so curious to
find this sort of atypical sticky situation... Happens to not be that
serious in this case, but i haven't kludged through it yet, hoping to find
out the reason and a fix if applicable.


--
Will

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] EXECUTABLE, and not really being added to updated repo

[bch]

On Dec 6, 2016 19:18, "Andy Bradford" <amb-fos...@bradfords.org> 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";  I retried  w/  a  --sha1sum switch;  still  listed as  changed
> (despite the new commit showing up in the "f timel"). touch(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).

I haven't been able to reproduce this. What version of Fossil?




Hey Andy. Tip of trunk, then jumped back in time to May 2014 in a few
different steps...

I'll have to dig in a bit more. Given the revisions I've tried (going to
find a regression by bisecting), it really does seem pretty curious now.
Will have to properly characterize what's going on. On NetBSD (amd64),
-current, fwiw.

-bch




Here's what I did:

$ fossil new test.fossil
project-id: 8763c2afcfc0adca5366be5f53225459f15c63b4
server-id:  0f0cb472cf82d3dd772996a526a5d69072ffb726
admin-user: amb (initial password is "19e0e7")
$ fossil open test.fossil
project-name: 
repository:   /tmp/test.fossil
local-root:   /tmp/
config-db:/home/amb/.fossil
project-code: 8763c2afcfc0adca5366be5f53225459f15c63b4
checkout: 01f3812d6588d5dc8a1f396d1698336009f36bde 2016-12-07 03:16:02
UTC
tags: trunk
comment:  initial empty check-in (user: amb)
check-ins:1
$ echo $RANDOM > file
$ ls -l file
-rw-r--r--  1 amb  wheel  6 Dec  6 20:16 file
$ fossil add file
ADDED  file
$ fossil ci -m no-execute
New_Version: 1fc3e40325e5fa0e91f7f634f021e2ce840ef9c2
$ chmod 755 file
$ fossil changes
EXECUTABLE file
$ fossil ci -m execute
New_Version: db9e561227ae4431b5eff542ac3cea278bb48817
$ fossil time
=== 2016-12-07 ===
03:16:40 [db9e561227] *CURRENT* execute (user: amb tags: trunk)
03:16:28 [1fc3e40325] no-execute (user: amb tags: trunk)
03:16:02 [01f3812d65] initial empty check-in (user: amb tags: trunk)
+++ no more data (3) +++
$ ls -l file
-rwxr-xr-x  1 amb  wheel  6 Dec  6 20:16 file*

Andy
--
TAI64 timestamp: 400058477fc4
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] EXECUTABLE, and not really being added to updated repo

[bch]

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 retried w/ a --sha1sum switch; still listed as changed
(despite the new commit showing up in the "f timel"). touch(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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] on sha1 as a hash

[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

Re: [fossil-users] Unversioned files.

[bch]

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 <brad.har...@gmail.com> wrote:
> On 8/30/16, sky5w...@gmail.com <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 unversioned export FILE  //1 at a time?
>>
>> If we have the prefix "fossil unversioned", why not allow Push and Pull
>> for
>> familiarity?
>
> My initial reaction is: "seconded".
>
>> And I'd prefer "fossil checkout" to have an unversioned switch to extract
>> unv files to disk instead of individual calls/file?
>>
>> Thanks for Fossil!
>>
>> On Tue, Aug 30, 2016 at 5:15 PM, Ross Berteig <r...@cheshireeng.com>
>> wrote:
>>
>>> On 8/30/2016 1:55 PM, Ron W wrote:
>>>
>>>> Why only "sync -u" ?
>>>>
>>>
>>> Probably to give an easy way to distinguish developer's clones from full
>>> mirrors. If the unversioned files are built releases, then I don't need
>>> them on my dev machine, so no reason to sync them.
>>>
>>> If unversioned files are used for something else, syncing them might
>>> make
>>> more sense.
>>>
>>> It might also make more sense for that to be controlled by a setting
>>> rather than a command line option to fossil sync. I'm not sure about
>>> that,
>>> without thinking through other use cases.
>>>
>>> On Tue, Aug 30, 2016 at 2:31 PM, Richard Hipp <d...@sqlite.org
>>>> <mailto:d...@sqlite.org>> wrote:
>>>>
>>>> A new feature of Fossil (currently unreleased and only available to
>>>> people who are willing to recompile the code on trunk) is
>>>> "unversioned
>>>> files".
>>>> 
>>>>
>>>
>>> --
>>> Ross Berteig   r...@cheshireeng.com
>>> Cheshire Engineering Corp.   http://www.CheshireEng.com/
>>> +1 626 303 1602
>>>
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unversioned files.

[bch]

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 unversioned export FILE  //1 at a time?
>
> If we have the prefix "fossil unversioned", why not allow Push and Pull for
> familiarity?

My initial reaction is: "seconded".

> And I'd prefer "fossil checkout" to have an unversioned switch to extract
> unv files to disk instead of individual calls/file?
>
> Thanks for Fossil!
>
> On Tue, Aug 30, 2016 at 5:15 PM, Ross Berteig  wrote:
>
>> On 8/30/2016 1:55 PM, Ron W wrote:
>>
>>> Why only "sync -u" ?
>>>
>>
>> Probably to give an easy way to distinguish developer's clones from full
>> mirrors. If the unversioned files are built releases, then I don't need
>> them on my dev machine, so no reason to sync them.
>>
>> If unversioned files are used for something else, syncing them might make
>> more sense.
>>
>> It might also make more sense for that to be controlled by a setting
>> rather than a command line option to fossil sync. I'm not sure about
>> that,
>> without thinking through other use cases.
>>
>> On Tue, Aug 30, 2016 at 2:31 PM, Richard Hipp >> > wrote:
>>>
>>> A new feature of Fossil (currently unreleased and only available to
>>> people who are willing to recompile the code on trunk) is
>>> "unversioned
>>> files".
>>> 
>>>
>>
>> --
>> Ross Berteig   r...@cheshireeng.com
>> Cheshire Engineering Corp.   http://www.CheshireEng.com/
>> +1 626 303 1602
>>
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] basic usage question - empty directories

[bch]

On Aug 1, 2016 8:02 PM, "Ron W" <ronw.m...@gmail.com> wrote:
>
> On Mon, Aug 1, 2016 at 8:22 PM, Adam Jensen <han...@riseup.net> 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 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 artifact.
>> >
>>
>> Is there a way to run these scripts automatically after each checkout?
>
>
> My team and I do this as part of the build procedure. Basically, we treat
those as part of the "product" being built, so when we do a "clean check
out", the first run of make will create those directories. We don't need
them before that.
>

This is indeed the process I would have described. Fossil isn't doing any
*work* with respect to your project - it's just laying out tools +
resources. It's unfortunate that empty directories are a cause for
confusion, but if you accept that and work as Ron's team does, think of
fossil as managing the *content* of files (and limited meta data), and
consider that things like ownership, permissions, empty directories (and
perhaps more) are the responsibility of the project and it's tooling
(build/setup). And to clear what I think might be a small amount of
confusion, when I was talking about executable bits and --x, I was using
those 3 characters ("--x") to stand in for UNIX permissions like rwx - not
as a double-dash switch.

Regards,

-bch

> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] basic usage question - empty directories

[bch]

There has been lots of discussion about this over the years
(https://www.google.ca/search?q=fossil-users+empty+directory).

I personally handle this (and other metadata things like user:group
ownership or permissions (though we now handle --x (executable bit))
in a controlling file. Something like 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 artifact.

-bch


On 8/1/16, Adam Jensen <han...@riseup.net> wrote:
> Hi,
>
> I haven't before used fossil to manage a project. Is there a way to
> commit empty directories to the repository so the project's directory
> structure can be preserved and reconstructed?
>
> Actually, some of the directories aren't empty but rather their contents
> are ignored:
>
> fsl add --ignore '*.db,*.fossil,*.log,*.mp3' *
> fsl commit -m "Initial checkin"
>
> Is this something simple that I haven't yet discovered in the
> documentation or am I doing something terribly wrong?
>
> Thanks!
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Release 1.35 checksums?

[bch]

On Jul 1, 2016 9:39 AM, "Warren Young" <w...@etr-usa.com> wrote:
>
> On Jun 30, 2016, at 7:21 PM, Todd C. Olson <t...@cornell.edu> wrote:
> >
> > The checksum file on the down load page only has values for up to v1.34
> > Where do we get the values for v1.35
>
> Why do you trust such things in the first case?
>
> If you’re looking to checksums to protect you against MITM malware
injection, the same MITM can modify the checksum, too.
>
> If you’re expecting the checksum to protect you against someone hacking
the web site and uploading malware, they can modify the checksums on the
web site at the same time.
>
> If you’re expecting to copy the checksums somewhere secure for verifying
EXEs later, downloading the current EXE and doing your own checksum gets
you the same benefit with no useful drop in security.
>
> If you’re looking to these checksums for an 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-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] bitkeeper open sourced, and DSCM discussion and history

[bch]

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

Re: [fossil-users] Compiling and running Fossil on old hardware

[bch]

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 long time
>>> to  clone the  Fossil  repository on  it.  Most of  the  time was  spent
>>> rebuilding, but even receiving the artifacts took some time.
>>
>>
>> If you're that hard-up for a machine, i've got a Raspberry Pi you can
>> have
>> ;). Even that's faster than that old Thinkpad (and cost only a small
>> fraction of what the Thinkpad did back in its day).
>>
>
> Sadly openbsd won't run on any version of the raspberry pi.


NetBSD has you covered ;)


https://wiki.netbsd.org/ports/evbarm/raspberry_pi/

>> --
>> - stephan beal
>> http://wanderinghorse.net/home/stephan/
>> http://gplus.to/sgbeal
>> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
>> those who insist on a perfect world, freedom will have to do." -- Bigby
>> Wolf
>>
>
>
>
> --
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> xmpp: jungle-boo...@jit.si
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] We strongly feel that the code and issue tracker...

[bch]

https://github.com/eslint/eslint/issues/5205

I can't speak to whether fossil is suitable for everything they might
need, but interesting to hear that they're looking for something we
fossil users (may) take for granted. In case you weren't aware, not
everybody gets to enjoy a fully-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

Re: [fossil-users] Fossil build improvements...

[bch]

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 other POSIX-only stuff. Is there a way to override it to use
editline/readline?

A worthwhile experiment, but remember readline is GPL. Editline is,
however, BSD.

> Is f5f81a2a583bd45a going into trunk at some point? My builds are linked
dynamically and I think this change would break that.
>
> Slightly off-topic: Is there a chance that some of the `#if
defined(_WIN32) || defined(__CYGWIN__)` stuff can be put under an
additional condition? I disable a bunch of these using a patch, but using a
define instead would be nicer.
>
> Is FOSSIL_ENABLE_MINIZ in Makefile used at all? I get
`FOSSIL_ENABLE_MINIZ = @FOSSIL_ENABLE_MINIZ@` in my Makefile.
>
> Is BROKEN_MINGW_CMDLINE supposed to be defined on mingw-w64? It seems to
build and work regardless (both globbing and non-ASCII characters in
filenames), but maybe I'm missing something.
>
> Cheers.
>
> --
> David Macek
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

I did a full I/O / syscall trace, and the only reference to
"16892b33c7..." I see in that output is fossil reading it in on fd 5.

For reference, I pulled libfossil (I was a couple commits behind (at
"feb9f"; first ancestor I did not already have: "51baf").

This 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 <brad.har...@gmail.com> wrote:
> strathcona$ grep 16892b33c7166eb3 http-re*
> http-reply-1.txt:igot 16892b33c7166eb3198844eac4ba5a7a6e395520
>
>
> On 1/8/16, bch <brad.har...@gmail.com> wrote:
>> Running
>>
>> $ fossil pull -verily -httptrace
>>
>> to find out...
>>
>> -bch
>>
>>
>> On 1/8/16, Jan Danielsson <jan.m.daniels...@gmail.com> 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
>>>>
>>>> Pull done, sent: 5064  received: 49107978  ip: 85.214.214.108
>>>>
>>>> $ fossil timeline
>>>> === 2015-05-30 ===
>>>> 14:42:26 [0bb26b5ab6] *CURRENT* Thanks rump for not letting us use
>>>> even mmap during initialization. (user: christos tags: trunk)
>>>> 14:13:12 [2ece07a9d3] add HDAUDIOVERBOSE (user: jmcneill tags: trunk)
>>>> 14:12:57 [625f16d4d3] regen (user: jmcneill tags: trunk)
>>>> 14:12:42 [a16403f046] add Tegra124 HDMI (user: jmcneill tags: trunk)
>>>> 14:10:01 [70b393fddb] fix path to devlist2h (user: jmcneill tags:
>>>> trunk)
>>>> 13:47:17 [3c49d42557] enable hdaudio (user: jmcneill tags: trunk)
>>>>
>>>> ...
>>>>
>>>>
>>>> still 7 months out of date.
>>>
>>>That's odd; my central repository has been keeping up for a long time
>>> now (it has been working so well for the past few months that I stopped
>>> regularly checking if it was working).
>>>
>>>It would be interesting to know if 16892b33c7166eb3 (the first, and
>>> only, descendant of 0bb26b5ab6) is ever mentioned, in any form, on the
>>> wire.
>>>
>>> --
>>> Kind Regards,
>>> Jan
>>> ___
>>> fossil-users mailing list
>>> fossil-users@lists.fossil-scm.org
>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>>
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] How to C in 2016

[bch]

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 always trying to improve my C programming skills and I think Fossil
> does a good job of using C in a very pragmatic way.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

Just talked  to Joerg off-list (who indicated that he updated fossil
to latest on his server), and:

$ fossil pull -verily

Pull done, sent: 5064  received: 49107978  ip: 85.214.214.108

$ fossil timeline
=== 2015-05-30 ===
14:42:26 [0bb26b5ab6] *CURRENT* Thanks rump for not letting us use
even mmap during initialization. (user: christos tags: trunk)
14:13:12 [2ece07a9d3] add HDAUDIOVERBOSE (user: jmcneill tags: trunk)
14:12:57 [625f16d4d3] regen (user: jmcneill tags: trunk)
14:12:42 [a16403f046] add Tegra124 HDMI (user: jmcneill tags: trunk)
14:10:01 [70b393fddb] fix path to devlist2h (user: 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 <jan.m.daniels...@gmail.com> wrote:
> On 04/01/16 02:02, Richard Hipp wrote:
>> On 1/3/16, bch <brad.har...@gmail.com> wrote:
>>> 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.
>>
>> Any idea what version Joerg is running on his server?
>
>Looks like http://fossil-scm.org/index.html/info/6c40678e91
>
>
> --
> Kind Regards,
> Jan
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

strathcona$ grep 16892b33c7166eb3 http-re*
http-reply-1.txt:igot 16892b33c7166eb3198844eac4ba5a7a6e395520


On 1/8/16, bch <brad.har...@gmail.com> wrote:
> Running
>
> $ fossil pull -verily -httptrace
>
> to find out...
>
> -bch
>
>
> On 1/8/16, Jan Danielsson <jan.m.daniels...@gmail.com> 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
>>>
>>> Pull done, sent: 5064  received: 49107978  ip: 85.214.214.108
>>>
>>> $ fossil timeline
>>> === 2015-05-30 ===
>>> 14:42:26 [0bb26b5ab6] *CURRENT* Thanks rump for not letting us use
>>> even mmap during initialization. (user: christos tags: trunk)
>>> 14:13:12 [2ece07a9d3] add HDAUDIOVERBOSE (user: jmcneill tags: trunk)
>>> 14:12:57 [625f16d4d3] regen (user: jmcneill tags: trunk)
>>> 14:12:42 [a16403f046] add Tegra124 HDMI (user: jmcneill tags: trunk)
>>> 14:10:01 [70b393fddb] fix path to devlist2h (user: jmcneill tags: trunk)
>>> 13:47:17 [3c49d42557] enable hdaudio (user: jmcneill tags: trunk)
>>>
>>> ...
>>>
>>>
>>> still 7 months out of date.
>>
>>That's odd; my central repository has been keeping up for a long time
>> now (it has been working so well for the past few months that I stopped
>> regularly checking if it was working).
>>
>>It would be interesting to know if 16892b33c7166eb3 (the first, and
>> only, descendant of 0bb26b5ab6) is ever mentioned, in any form, on the
>> wire.
>>
>> --
>> Kind Regards,
>> Jan
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

Running

$ fossil pull -verily -httptrace

to find out...

-bch


On 1/8/16, Jan Danielsson <jan.m.daniels...@gmail.com> 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
>>
>> Pull done, sent: 5064  received: 49107978  ip: 85.214.214.108
>>
>> $ fossil timeline
>> === 2015-05-30 ===
>> 14:42:26 [0bb26b5ab6] *CURRENT* Thanks rump for not letting us use
>> even mmap during initialization. (user: christos tags: trunk)
>> 14:13:12 [2ece07a9d3] add HDAUDIOVERBOSE (user: jmcneill tags: trunk)
>> 14:12:57 [625f16d4d3] regen (user: jmcneill tags: trunk)
>> 14:12:42 [a16403f046] add Tegra124 HDMI (user: jmcneill tags: trunk)
>> 14:10:01 [70b393fddb] fix path to devlist2h (user: jmcneill tags: trunk)
>> 13:47:17 [3c49d42557] enable hdaudio (user: jmcneill tags: trunk)
>>
>> ...
>>
>>
>> still 7 months out of date.
>
>That's odd; my central repository has been keeping up for a long time
> now (it has been working so well for the past few months that I stopped
> regularly checking if it was working).
>
>It would be interesting to know if 16892b33c7166eb3 (the first, and
> only, descendant of 0bb26b5ab6) is ever mentioned, in any form, on the
> wire.
>
> --
> Kind Regards,
> Jan
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Completely untagged commits ?

[bch]

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 <d...@zombi.eclipse.co.uk> wrote:
> On 05/01/2016 18:53, bch wrote:
>> 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=2016-01-05+10%3A12%3A56=200
>
> If I've messed this up, I do most humbly apologise and want to fix it
> ASAP - but I see this as tagged as "technoteattachcli", at least in the
> fossil-scm.org web ui.
>
> 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 do wonder if this might be
> part of the problem.
>
> David
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Completely untagged commits ?

[bch]

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 do wonder if this might be
>>> part of the problem.
>>>
>>
>> There was a "private" tag on that initial check-in.  I have cancelled
>> that tag.  But the check-in is still showing as "unpublished".  Must
>> be a bug somewhere.  A "fossil rebuild" will likely clear the problem.
>> I'll try that next...
>
> Even after rebuilding, the check-in shows up as "unpublished".
> There's a bug somewhere in the "private" tag handling.  Who can be the
> first to find it!

I think we've got a few hours until Stephan Beal wakes up...


> I went into the repository and manually did a "DELETE FROM private
> WHERE rid=(SELECT rid FROM blob WHERE uuid LIKE '5712fa8f133228f%')".
> That got the repo working again.  But that entry in the private table
> will probably reappear the next time the repo is rebuilt.
>
> But in the meantime, you can all sync the public repo and try to
> figure out what is the problem.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Completely untagged commits ?

[bch]

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=2016-01-05+10%3A12%3A56=200
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Completely untagged commits ?

[bch]

Here's what I see on my *local* machine (see also attached ffox screenshot):

strathcona$ fossil timel
=== 2016-01-05 ===
10:12:56 [d4dc7ad8dc] [c541b6e734] Remove unintended white space
change in wiki.c (user: dave.vines)
08:40:09 [64a5ef28e5] [c541b6e734] Move attachment command from wiki.c
to attach.c (user: dave.vines)
08:34:24 [16f864af8f] [c541b6e734] Move attachment from wiki
subcommand to top level command (user: dave.vines)
04:52:59 [cd58f59a47] Update the built-in SQLite to the next 3.10.0
beta. (user: drh tags: trunk)
=== 2016-01-04 ===
23:29:36 [c3430c1a67] Edit [2c5a5e82be8c30d7|2c5a5e82be]: Edit
check-in comment. (user: aku)
03:41:15 [6f8f8667c9] Update manifests on tag change. (user: jan tags:
jan-manifest-tags)
03:10:27 [53f2e7c540] Filter tags. (user: jan tags: jan-manifest-tags)
02:54:39 [dacecc79aa] Handle the three manifest files separately so
manifest generation reconfigurations can be handled properly. (user:
jan tags: jan-manifest-tags)
02:16:47 [46b9adb70f] Conditionally save manifests on commit. (user:
jan tags: jan-manifest-tags)
00:36:40 [de30eec201] Code normalization; tabs->spaces. (user: jan
tags: jan-manifest-tags)
00:29:24 [c6f3eba715] Edit [e5b250959ad4ec15|e5b250959a]: Edit
check-in comment. (user: jan)
00:28:40 [aed6fe5308] Add manifest.tags to generated zips, and
decouple manifest and manifest.uuid. (user: jan tags:
jan-manifest-tags)
00:22:03 [185669ce21] Fix: Extract filename for manifest.tags. (user:
jan tags: jan-manifest-tags)
00:19:00 [6a56db89f6] Added a missing finalize. (user: jan tags:
jan-manifest-tags)
=== 2016-01-03 ===
23:55:15 [80ceedbdea] Add manifest.tags to tarballs when appropriate,
and decouple manifest and manifest.uuid. (user: jan tags:
jan-manifest-tags)
22:54:15 [142cb7aabd] Add manifest.tags to the 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, bch <brad.har...@gmail.com> wrote:
> 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 <d...@zombi.eclipse.co.uk> wrote:
>> On 05/01/2016 18:53, bch wrote:
>>> 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=2016-01-05+10%3A12%3A56=200
>>
>> If I've messed this up, I do most humbly apologise and want to fix it
>> ASAP - but I see this as tagged as "technoteattachcli", at least in the
>> fossil-scm.org web ui.
>>
>> 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 do wonder if this might be
>> part of the problem.
>>
>> David
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Completely untagged commits ?

[bch]

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 <brad.har...@gmail.com> wrote:
> On 1/5/16, Richard Hipp <d...@sqlite.org> wrote:
>> On 1/5/16, Richard Hipp <d...@sqlite.org> wrote:
>>> On 1/5/16, David Vines <d...@zombi.eclipse.co.uk> 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 do wonder if this might be
>>>> part of the problem.
>>>>
>>>
>>> There was a "private" tag on that initial check-in.  I have cancelled
>>> that tag.  But the check-in is still showing as "unpublished".  Must
>>> be a bug somewhere.  A "fossil rebuild" will likely clear the problem.
>>> I'll try that next...
>>
>> Even after rebuilding, the check-in shows up as "unpublished".
>> There's a bug somewhere in the "private" tag handling.  Who can be the
>> first to find it!
>
> I think we've got a few hours until Stephan Beal wakes up...
>
>
>> I went into the repository and manually did a "DELETE FROM private
>> WHERE rid=(SELECT rid FROM blob WHERE uuid LIKE '5712fa8f133228f%')".
>> That got the repo working again.  But that entry in the private table
>> will probably reappear the next time the repo is rebuilt.
>>
>> But in the meantime, you can all sync the public repo and try to
>> figure out what is the problem.
>> --
>> D. Richard Hipp
>> d...@sqlite.org
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Completely untagged commits ?

[bch]

What's incorrect, the documentation, or the implementation ?

>From private.wiki:

After additional work, one might desire to publish the changes associated
with a private branch.  The usual way to do this is to merge those
changes into a public branch.  For example:


fossil update trunk
fossil merge private
fossil commit


The private branch remains private.  (There is no way to convert a private
branch into a public branch.)  But all of the changes associated with
the private branch are now folded into the public branch and are hence
visible to other users of the project.


On 1/5/16, Richard Hipp <d...@sqlite.org> wrote:
> On 1/5/16, bch <brad.har...@gmail.com> 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.
>>
>
> The rebuild didn't help.  It was my manual DELETE of the offending
> entry in the PRIVATE table of the database that fixed it.  But that
> entry will reappear at the next rebuild, I suspect.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

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 <d...@sqlite.org> wrote:
> On 1/3/16, bch <brad.har...@gmail.com> wrote:
>> The continuing saga of syncing netbsd-src:
>>
>> I've got a fossil processing kicked off by: fossil sync --verily
>> (against: http://netbsd.sonnenberger.org/timeline)
>>
>> that has now consumed 594 minutes of CPU time, and produced no network
>> traffic (as measured by tcpdump)... when I ktruss(1) it, it'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 ?
>>
>
> Are you using the latest trunk version of Fossil?
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

The continuing saga of syncing netbsd-src:

I've got a fossil processing kicked off by: fossil sync --verily
(against: http://netbsd.sonnenberger.org/timeline)

that has now consumed 594 minutes of CPU time, and produced no network
traffic (as measured by tcpdump)... when I ktruss(1) it, it'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 <amb-fos...@bradfords.org> wrote:
> Thus said Andy Gibbs on Thu, 03 Dec 2015 10:58:52 +0100:
>
>> "round-trips" being  during the push  (i.e. post commit). Sorry  I was
>> using  the terminology  of  what  was being  shown  on  screen --  not
>> combining the pre and post commit numbers.
>
> That's alright,  I was just trying  to be certain I  understood what you
> were  seeing. It  sounds like  the 100  round-trips is  during the  push
> portion  of the  sync operation,  which  means you  must have  a lot  of
> artifacts in the commit.
>
>> Hooray!  However... doing  then a  sync on  my clone,  then doing  the
>> fossil test-clusters again on the server results in:
>
> Yes, this was recently fixed here:
>
> http://www.fossil-scm.org/index.html/info/24606598a72eeaaa
>
> Also, I've found that when you  run ``fossil rebuild'' on the repository
> that has errors about artifacts not found in clusters, it places all the
> artifacts not in clusters back into the unclustered table. And, not only
> that, but after running rebuild, the next  sync they will get put into a
> cluster and the  clients begin again to pull them  down (without needing
> --verily at all).
>
> At  any rate,  I'll  see  if I  can  reproduce the  issue  as  far as  I
> understand it from your description.
>
> Thanks,
>
> Andy
> --
> TAI64 timestamp: 40005661240e
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil sync doesn't sync

[bch]

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 strikes.

-bch


On 12/1/15, Richard Hipp <d...@sqlite.org> wrote:
> On 12/1/15, Andy Gibbs <andyg1...@hotmail.co.uk> wrote:
>> Hi,
>>
>> I'm having an issue which recurs from time to time which is that "fossil
>> sync" doesn't actually do anything,
>> deleting the cloned repository and cloning again "fixes" the problem
>>
>
> Next time this happens, try running:
>
> fossil sync --verily
>
> And then let us know if that clears the problem.
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Timeline questions

[bch]

On Nov 26, 2015 5:11 AM, "Stephan Beal" <sgb...@googlemail.com> wrote:
>
> On Thu, Nov 26, 2015 at 1:47 PM, Abilio Marques <abili...@gmail.com>
wrote:
>>>
>>> ​​
>>> ...​
>>> ​
>>>  i believe fossil should always display (in CLI mode) exactly what was
input, without any sort of reformatting.)
>>
>>
>> But actually that's not the case. Fossil doesn't show at least newlines
(making a long comment a huge blob).
>> ​
>
>
> My phrasing was unfortunately ambiguous. You're correct: fossil does
reformat. My intended meaning was, "if i had my way, fossil would not do
that." (But i believe i'm in the minority on that opinion. ;)

I *think* git reads first content to newline for display of short synopsis
by default, and will print the long form by demanding it. *I* think that
would be ideal. Example:

"Fixes [cafebabe] formatting error for timeline. Shows by default (keep
this short).

This is the long form, and not displayed by default in listing (CLI or
web). Here we describe the challenges and steps, maybe appropriate hints
for this, etc. Examples or code samples would be appropriate here."

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
>> ​ early yesterday​
>> , but then I learned the hard way that span items can't take many
properties as a
>> ​block element can
>> , so I wasn't able to get any hide and show when hover trick to work
>> ​. That's why I ended up doing it in javascript, so it shows only the
title, and when you hover with the mouse, it shows the rest (see the
example at
>> http://abiliojr.homenet.org:20003/cleantimeline/timeline)
>
>
> A SPAN is not a block element, but perhaps we should consider making the
comment lines DIVs instead (since DIVs are block elements)?
>
> Another option: you can convert a timelineComment span to a block element
with CSS:
>
> span.timelineComment {
>   display: block
> }
>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
> "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] VCS Theory

[bch]

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 Darcs had quite a bit of write up when I looked a decade
> ago.

+1 for the Darcs literature.

> Joerg
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Slight file renames

[bch]

On 11/16/15, Ron W <ronw.m...@gmail.com> wrote:
> On Mon, Nov 16, 2015 at 12:38 PM, bch <brad.har...@gmail.com> 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 release and this is where we might find renaming
>> issues as I described.
>>
> If the file names are the same other than the version, you could strip off
> the version. For example, in a script you could include:
> perl -e 'my $n = $ARGV[0]; $n =~ s/-\d+[.]\d+//; rename($ARGV[0], $n);'
> $file

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 available with-in or outside
fossil (outside of trying to tease-out the "root" of a filename and
pair-up ea. MISSING w/ it's EXTRA counterpart.

In this sense, the behavour of git (iiuc) would be roughly what I want
where it tracks bytes, not files (this is what I think I undertand; it
allows git to track a function being moved from one file to another --
I don't understand how it works, but it sounds like what I want --
keep track of collections of bytes regardless of the name of their
container (the filename).

> If all the such files share a common naming pattern, the following should
> be able to find and strip off the version string from the names of all such
> files (all on one line):
> find . -iregex '[a-z]+[-][0-9]+[.][0-9]+[.]txt' -type f -exec
> perl -e 'my $n = $ARGV[0]; $n =~ s/-\d+[.]\d+//; rename($ARGV[0], $n);'
> '{}' ';'
>
> You may need to modify the pattern after -iregex to match your files.
> FYI, the i in -iregex means case insensitive matching. -regex will do case
> sensitive matching.
>
> If you have trouble modifying my find command, above, to work for you, I
> can create create an equivalent Perl script that should work on MS Windows,
> Mac OSX, Linux and other Unix-like systems.
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Slight file renames

[bch]

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 release and this is where we might find renaming
issues as I described.
On Nov 16, 2015 9:24 AM, "Ron W" <ronw.m...@gmail.com> wrote:

>
>
> On Mon, Nov 16, 2015 at 3:02 AM, bch <brad.har...@gmail.com> 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 libxyz (for version 1.2 in
>> particular), if the name changes to libxyz-1.3.txt for the next commit,
>> what I'll see on [fossil changes] is a missing libxyz-1.2.txt and an extra
>> libxyz-1.3.txt. One simple way to keep all the files tracked is to [fossil
>> rm] the 1.2 file and [fossil add] the 1.3 file, but then the logical
>> continuity of the files is lost. If one does a [fossil mv], the logical
>> 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.
>>
> How are these xyz-m.n.txt files being created? Are they generated? Is
> someone renaming the files then editing them?
>
> Our API and low level design/code documents are generated from comments in
> the source files. We don't commit these documents, though I suppose it
> would make it easier to view the evolution of the APIs and designs. If we
> were to commit them, we could any needed Fossil commands at the end of our
> generating scripts, including a "fossil mv" before the "fossil com".
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Slight file renames

[bch]

On 11/16/15, Ron W <ronw.m...@gmail.com> wrote:
> On Mon, Nov 16, 2015 at 2:20 PM, bch <brad.har...@gmail.com> 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 available with-in or outside
>> fossil (outside of trying to tease-out the "root" of a filename and
>> pair-up ea. MISSING w/ it's EXTRA counterpart.
>>
>
> Other than figuring out all the needed patterns to find and "normalize" the
> names of the files, I don't know of any "special sauce" you can use.
>
>
>> In this sense, the behavour of git (iiuc) would be roughly what I want
>> where it tracks bytes, not files (this is what I think I undertand; it
>> allows git to track a function being moved from one file to another --
>> I don't understand how it works, but it sounds like what I want --
>> keep track of collections of bytes regardless of the name of their
>> container (the filename).
>>
>
> I didn't know git could do that.

Further to that:
http://stackoverflow.com/questions/4908336/can-git-really-track-the-movement-of-a-single-function-from-1-file-to-another-i

To be clear, I don't fully understand what the git model is (I
repeatedly hear "it doesn't track files", but I haven't had a
"Eureka!" moment of understanding yet.


> Ignoring function renames and polymorphism, I can see using something like
> ctags to virtually subdivide files into functions for tracking at that
> level.

That's an interesting thought. A ctags(-like) db would indeed be
interesting, so long  as the target-language is supported.

>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Slight file renames

[bch]

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 libxyz (for version 1.2 in
particular), if the name changes to libxyz-1.3.txt for the next commit,
what I'll see on [fossil changes] is a missing libxyz-1.2.txt and an extra
libxyz-1.3.txt. One simple way to keep all the files tracked is to [fossil
rm] the 1.2 file and [fossil add] the 1.3 file, but then the logical
continuity of the files is lost. If one does a [fossil mv], the logical
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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] symlinks (was Re: xkcd on git)

[bch]

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.
>>>
>>>
>>> Isn't that essentially confirming my point? Fossil merely stores the
pointer. It need not waste time analysing the link to make a judgement call
in any way. Just store it and move on.
>>
>>
>> But if it only stores a pointer, and requires the user to reconstruct
the link, it's not terribly useful/friendly. The user would potentially
have to replace fossil's placeholder pseudosymlink file with a link of his
own (which he could point somewhere else than fossil thinks it "should"
be). He might has well simply have a "post-checkout" script which sets up
his symlinks for him. To me, that's the "proper"/"safest" way to handle
symlinks in a repo (but i'm willing to accept being in the minority on that
point).
>
>
> Fossil's poor handling of symlinks is a severe knock against it, both in
my opinion and in my experience with proselytizing it to people who are not
already on the fossil kool-aid.

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 links as the build artifacts
of a script, and keep the script itself under version control?

So, if you need: foo -> bar, do this:

#!/bin/sh
ln -sf bar foo

... and store that script under VC?

> Every time a user opens our repo on unix, the symlinks are initially
populated as regular files whose contents are the link target.  This is
causes me significant embarrassment for recommending fossil when others on
my project have to deal with it.  (I tried pushing through a code patch a
year or so ago to fix this, but I detected some bug or another with it and
I don't think the devs ever accepted the patch (not sure).)
>
> Note that this a Fossil-specific quirk.  Not all cross-platform programs
are equally awkward in their symlink handling -- in fact, most are better.
>
> Stephan: I think that you are overcomplicating the matter, in the sense
that the complications you note can (and should) be passed on to the user
-- in the same way that the program tar(1) might pass on such complications
to the user when trying to move a tarball from one OS to another.  In other
words, I believe that you perceive a dichotomy that is false (between (a)
not implementing symlinks at all and (b) implementing them while having
fossil perfectly and automatically solve all complications that may arise).
>
> A user who only ever uses fossil on unix should get unix symlink
semantics on unix, without quirks or surprises.  Surely you and DRH would
agree with that?
>
> The cases you are worried about:
>
> * absolute paths -- fossil can preserve the absolute path, it's the
user's fault if that's the wrong thing to do.
> * broken links -- fossil preserves the original link, it's the user's
fault if the link is incorrectly broken.
> * cross-platform semantics -- implement the proper semantics where you
can, and don't where you can't.  A user who only ever uses fossil on unix
should get unix symlink semantics on unix.  If the fossil devs are able to
implement proper symlink handling on next year's Windows, then awesome.  If
not, then degrade to whatever and document it for the user (emitting
warning messages as appropriate or so on).
>
> Stated yet another way: we don't expect the SCM to solve all problems
that users create.  An example is naming branches incorrectly.  If the user
names a branch "" when the project has a rule that branch names should
be descriptive, we don't expect Fossil to flag it and deal with it -- we
expect the user's coworkers to yell at them til they fix it.  So it should
be with symlinks -- each project has its own rules, Fossil doesn't know
about those rules, Fossil just faithfully syncs the target around, and if a
link gets broken in violation of project rules then a user gets yelled at
by another user.  (Note that the project-local rules might be "never use
symlinks because our Windows doesn't handle them how we would like" or "we
think symlinks are always perverse".  Fossil should not IMO be constrained
by such subsets of the user base.)
>
> For context, my particular use case: we need the openssl source tree in
our project, and that tree contains internal symlinks.  Again, people have
to jump through silly hoops to get new repos set up properly, because
fossil breaks those symlinks by populating new repos with flat text files
(and this goes undiscovered til the openssl build fails in mysterious
ways).  So their first experience with Fossil winds up being a pretty big
"WTF".
>
> My $.02,
> Eric
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> 

Re: [fossil-users] symlinks (was Re: xkcd on git)

[bch]

On 11/2/15, Ron W <ronw.m...@gmail.com> wrote:
> On Mon, Nov 2, 2015 at 1:16 PM, bch <brad.har...@gmail.com> 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 links as the build
>> artifacts
>> of a script, and keep the script itself under version control?
>>
> We used to, but now use the vpath directive in GNU make, so longer need
> symlinks.

After I posted this, I thought a Makefile (still to manage actual
symlinks) would be an improvement over a shell script; you're punting
on symlinks completely (using VPATH). How has VPATH (or the previous
shell script) treated you as a symlink manager/replacement ?

-bch


>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about MERGE

[bch]

On 10/28/15, Richard Hipp <d...@sqlite.org> wrote:
> On 10/28/15, to...@acm.org <to...@acm.org> wrote:
>> OK, but doesn't cherry-pick work the same as a MERGE but only for single
>> version of the timeline?
>>
>> My intent was to get all changes from the branch (the whole history) but
>> for
>>
>
> Fossil does not currently support the ability to merge some files but
> not others.  That has never come up before.

I've certainly wished for the NOP operation that looks to be a side
effect of the [merge]/[revert] (and a cause of concern/confusion for
Tony). I tried to 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
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Stash-cat

[bch]

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.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Bad press for GitHub

[bch]

> Still, I get irrationally pleased when I read bad press for git or its 
> cronies.

I don't see anything there that precludes one from s/github/chissel/;
s/git/fossil/ and having this same thing happen. I think Stephen is
on-point that this is less about git (read: has nothing to do with
git) than the developer. Just a sad story, really.

-bch

On 9/2/15, Scott Robison <sc...@casaderobison.com> wrote:
> On Sep 2, 2015 2:43 AM, "Stephan Beal" <sgb...@googlemail.com> wrote:
>>
>> Management summary:
>>
>> the bug was that the MSVC integration tool checked in to a public repo
> instead of a private one. The developer did something seriously... errr
> stupid which was amplified by that bug...
>>
>> -
>>
>> Within around ten minutes after publishing his code, he received a
> notification from Amazon Web Services telling him his account had been
> compromised. He had (somewhat foolishly) included an AWS access key in the
> code that he had committed to GitHub.
>>
>> That less applies to fossil as well: do not check in sensitive data.
>
> Right, it was not a git flaw. Still, I get irrationally pleased when I read
> bad press for git or its cronies. I do feel bad for the guy, though.
>
> I think another thing to take away is the utility in managing your own
> repo. I appreciate not everyone can afford it, but it really doesn't cost
> much. Project aggragation sites (GitHub & SourceForge & anything on the
> list at
> https://en.m.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities
> really) give bad guys one stop shopping for a lot of code. Self hosted
> repositories are arguably safer. Especially projects no one has ever heard
> of! ;)
>
> Perhaps the first time in history someone was sad that git didn't lose
> data. #zing
>
>>
>>
>> On Wed, Sep 2, 2015 at 10:39 AM, Stephan Beal <sgb...@googlemail.com>
> wrote:
>>>
>>> On Wed, Sep 2, 2015 at 8:34 AM, Scott Robison <sc...@casaderobison.com>
> wrote:
>>>>
>>>> Not really a flaw with git, but this jumped out at me tonight:
> http://www.theregister.co.uk/2015/09/01/github_bug_costs_man_thousands/
>>>
>>>
>>> Be careful to take anything The Register says with a big, fat grain of
> salt. i've seen so much bad/wrong "news" (or editorials sold as news) via
> them that i won't even knowingly click on links to them anymore :/.
>>>
>>> YMMV, of course.
>
> Interesting, thanks for the info. It is not a site I frequent, but I do see
> links there from time to time  (as should be obvious).
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Locating the repo file for any given working directory

[bch]

$ fossil info
On Aug 21, 2015 1:34 AM, Arnel Legaspi jalespr...@gmail.com 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:

 sqlite select * from vvar where name = 'repository';
 repository|../../fsl.fossil

 Is there a better way to get this information through the CLI commands
 already available? An absolute path would be preferred (similar to
 the one given by 'fossil all ls'), but if not, it's fine.

 Currently using version 1.33 [b9447b0ec6] 2015-07-08 17:16:55 UTC, if
 it helps.

 Thanks in advance,
 Arnel
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Conflicts during update

[bch]

On Aug 12, 2015 1:19 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Aug 12, 2015 at 10:13 AM, Jacek Cała jacek.c...@gmail.com 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 fossil complains about CR/LF I just
ignore it (saying 'a' during the commit).

 However, I guess, there is no way to list files that were reported as
conflicting during merge, is there?


 Not that i am aware of.

If there really are conflicts, [fossil changes] should report them.

Also, fiddling with your diff command might be illustrative, example:
[fossil set diff-command diff -bu] for producing unified diff that
ignores whitespace, and diff -u for acknowledging whitespace...

 i know svn requires one to manually tell it the conflict for this
specific file is resolved, but fossil does not do so, and it does not
remember that a file is conflicted. When a conflict occurs, the conflicting
part(s) of the file will be wrapped up in blocks which look like this
(copy/pasted from a recent mail by Richard):

  BEGIN MERGE CONFLICT: local copy shown first 
   === COMMON ANCESTOR content follows 
   === MERGED IN content follows ==
END MERGE CONFLICT 

 If you don't see any of those in your source-controlled files then fossil
does not know about a conflict. If it reports a conflict and yet does not
tag it with such a block, then something is wrong (in fossil), but we are
not currently aware of any such bugs.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] branch from current branch

[bch]

*valuable TAG. (Mobile keyboards
..)
On Jul 27, 2015 7:10 PM, bch brad.har...@gmail.com 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 amb-fos...@bradfords.org 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 branch from the current one instead of having to specify it?

 What about?

 $ fossil branch new MYBRANCH current

 Andy
 --
 TAI64 timestamp: 400055b6c311


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] branch from current branch

[bch]

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 amb-fos...@bradfords.org 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 branch from the current one instead of having to specify it?

 What about?

 $ fossil branch new MYBRANCH current

 Andy
 --
 TAI64 timestamp: 400055b6c311


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Strange timeline bug with dp parameter.

[bch]

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 d...@sqlite.org wrote:
 On 7/13/15, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said Andy Goth on Mon, 13 Jul 2015 14:34:11 -0500:

 I found the same bug and reported to the list.  There were no replies.

 https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20593.html

 Yep, that's it. In fact, as I sent the email I remember having a nagging
 feeling  of having  seen this  before; now  I realize  it's because  you
 reported it already.


 The dp= and r= query parameters on /timeline do not play well
 together.  And it is going to require some extensive changes to the
 timeline generator to fix that.

 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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 jo...@britannica.bec.de
wrote:

 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 artifacts like
 before.

 Joerg
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

Still no dice:

kamloops$ fossil pull --verbose
Pull from http://netbsd.sonnenberger.org
Bytes  Cards  Artifacts Deltas
Sent:9546202  0  0
Received:  78  2  0  0
Pull done, sent: 5082  received: 333  ip: 135.28.13.11
kamloops$

On 6/23/15, Joerg Sonnenberger jo...@britannica.bec.de 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)?

 Likely. As I said, I don't really know why it sometimes creates those :(

 Joerg
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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 FROM vvar WHERE name='repository';
ATTACH DATABASE '/home/bch/work/netbsd_src/../fossils/netbsd_src.fsl'
AS 'repository';
SELECT value FROM config WHERE name='allow-symlinks';
SELECT value FROM global_config WHERE name='allow-symlinks';
SELECT value FROM config WHERE name='aux-schema';
SELECT value FROM config WHERE name='auto-shun';
SELECT value FROM global_config WHERE name='auto-shun';
SELECT value FROM config WHERE name='last-sync-url';
SELECT value FROM config WHERE name='last-sync-pw';
SELECT value FROM global_config WHERE name='last-sync-pw';
SELECT value FROM config WHERE name='http-auth:http://netbsd.sonnenberger.org';
SELECT value FROM global_config WHERE
name='http-auth:http://netbsd.sonnenberger.org';
BEGIN;
REPLACE INTO config(name,value,mtime)
VALUES('last-sync-url','http://netbsd.sonnenberger.org',now());
COMMIT;
SELECT value FROM vvar WHERE name='default-user';
SELECT value FROM config WHERE name='default-user';
SELECT value FROM global_config WHERE name='default-user';
SELECT uid FROM user WHERE login='bch';
Pull from http://netbsd.sonnenberger.org

[...]

SELECT value FROM config WHERE name='server-code';
SELECT value FROM config WHERE name='project-code';
SELECT value FROM config WHERE name='dont-push';
SELECT value FROM global_config WHERE name='dont-push';
SELECT value FROM config WHERE name='max-upload';
SELECT value FROM global_config WHERE name='max-upload';
BEGIN;
SELECT value FROM config WHERE name='case-sensitive';
SELECT value FROM global_config WHERE name='case-sensitive';
DELETE FROM global_config WHERE name  =
'repo:/home/bch/work/fossils/netbsd_src.fsl';
INSERT OR IGNORE INTO
global_config(name,value)VALUES('repo:/home/bch/work/fossils/netbsd_src.fsl',1);
DELETE FROM global_config WHERE name  = 'ckout:/home/bch/work/netbsd_src/';
REPLACE INTO global_config(name,
value)VALUES('ckout:/home/bch/work/netbsd_src/','/home/bch/work/fossils/netbsd_src.fsl');
CREATE TEMP TABLE onremote(rid INTEGER PRIMARY KEY);
CREATE TEMP TABLE pending_tkt(uuid TEXT UNIQUE);
CREATE TEMP TABLE time_fudge(  mid INTEGER PRIMARY KEY,  m1 REAL,  cid
INTEGER,  m2 REAL);
SELECT value FROM config WHERE name='cookie';
SELECT value FROM global_config WHERE name='cookie';
SELECT uuid FROM phantom CROSS JOIN blob USING(rid) /*scan*/ WHERE NOT
EXISTS(SELECT 1 FROM shun WHERE uuid=blob.uuid)AND NOT
EXISTS(SELECT 1 FROM private WHERE rid=blob.rid);
SELECT hex(randomblob(20));
SELECT julianday('now');ts sent: 0  received: 0
SELECT rid FROM blob WHERE uuid='e3d2fefd88f1e0ce8f74fe79666e1cea4b54911e';
DELETE FROM private WHERE rid=2138325;
INSERT OR IGNORE INTO onremote VALUES(2138325);
SELECT julianday('2015-06-23T18:55:04') - 2457197.286120012;
DROP TABLE onremote;ifacts sent: 0  received: 0
SELECT value FROM config WHERE name='xfer-common-script';
SELECT value FROM global_config WHERE name='xfer-common-script';
SELECT value FROM config WHERE name='xfer-ticket-script';
SELECT value FROM global_config WHERE name='xfer-ticket-script';
SELECT uuid FROM pending_tkt;
DROP TABLE pending_tkt;
UPDATE time_fudge SET m1=m2-2.89351851851852e-07 WHERE m1=m2 AND
m1m2+2.31481481481481e-05;
SELECT 1 FROM time_fudge;
DROP TABLE time_fudge;
DELETE FROM config WHERE name  = 'ckout:/home/bch/work/netbsd_src/';
REPLACE INTO 
config(name,value,mtime)VALUES('ckout:/home/bch/work/netbsd_src/',1,now());
COMMIT;

Pull done, sent: 5081  received: 333  ip: 135.28.13.11
-- LOOKASIDE_USED 14 77
-- LOOKASIDE_HIT   1457
-- LOOKASIDE_MISS_SIZE  363
-- LOOKASIDE_MISS_FULL0
-- CACHE_USED1134608
-- SCHEMA_USED 34024
-- STMT_USED   0
-- MEMORY_USED   13990161415616
-- MALLOC_SIZE65784
-- MALLOC_COUNT  803846
-- PCACHE_OVFLOW 12154481215448
-- prepared statements59
PRAGMA main.freelist_count;
PRAGMA main.page_count;


On 6/23/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
 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  0  0
 Pull done, sent: 5082  received: 333  ip: 135.28.13.11
 kamloops$

 Hm. I wonder if the problem is that your system is asking for artefacts
 that no longer exist my public copy and doesn't loop when it doesn't get
 an answer for any of those. --trace would help for that.

 Joerg
 ___
 fossil-users mailing

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 9759  received: 331  ip: 135.28.13.11
kamloops$


But even on a repo that does pull artifacts, I get no extra output:

kamloops$ fossil pull --httptrace
Pull from http://pkgsrc.sonnenberger.org
Round-trips: 3   Artifacts sent: 0  received: 117
Pull done, sent: 6543  received: 65534  ip: 135.28.13.11
kamloops$


What am I missing ?

-bch


On 6/23/15, Joerg Sonnenberger jo...@britannica.bec.de 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 --httptrace which will reveal the HTTP transactions
 during the pull operation (e.g. what was sent/received).

 Yeah, --httptrace.

 Joerg
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fwd: DB corruption and error msg string mis-handling.

[bch]

Ugh. Again, include fossil-users@


-bch


-- Forwarded message --
From: bch brad.har...@gmail.com
Date: Tue, 23 Jun 2015 13:38:39 -0700
Subject: Re: [fossil-users] DB corruption and error msg string mis-handling.
To: Andy Bradford amb-fos...@bradfords.org

Very good. Thanks Andy.

See attached.

-bch


On 6/23/15, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said bch on Tue, 23 Jun 2015 12:06:25 -0700:

 kamloops$ fossil sync --httptrace
 Sync with http://netbsd.sonnenberger.org
 Round-trips: 1   Artifacts sent: 0  received: 0
 Sync done, sent: 11687  received: 381  ip: 135.28.13.11
 kamloops$

 Follow that with:

 kamloops$ ls http-re*.txt

 Those files should contiain the HTTP transactions.

 Andy
 --
 TAI64 timestamp: 40005589b8cc

POST http://netbsd.sonnenberger.org/xfer/xfer HTTP/1.0
Host: netbsd.sonnenberger.org
User-Agent: Fossil/1.33 (2015-06-22 04:37:21 [100ac83b64])
Content-Type: application/x-fossil-debug
Content-Length: 9546

pull d2db8f80e2265ad8bffd7cef2bd76ec70a9a5ddc 
f147779665278afdf4d91757d941046def2b6e5a
gimme 51234778a7eca8097e3cb99189b60bfc3d27121d
gimme 5126532b16081526762b3d01d7f216c5c53714c9
gimme 512df203cd9960839c8d917df608b656154170a9
gimme 51324b5ccc90280a488e4352584c93ff0b1333c6
gimme 5132a1397f6eb72d9212fcfa2b5ce3ee21c8c493
gimme 5132d9d227559161d78c908fd277d648c8310a0a
gimme 513383aeb8d08ecb91b63ca144ab4fd1f6501f25
gimme 513bf16de14b7d14c44a082587b4f1130668b920
gimme 513e218881529a5631f384418ba10d08223d9554
gimme 513f3a44a626def6f56de89b864f54582567cf43
gimme 513f985c5d163d5fa92f74ec6873fe85654ce90a
gimme 5142d9389bbce15d94193d3822624cc016bf9c85
gimme 514726dfb7d32c6907cfc0f53196bc44426e46d1
gimme 514ab1813187400b7a4d998403323919f2f66842
gimme 5156d023e146aa8b0a335d8190c7f7c9dc5d0722
gimme 5157d40514cb52325af126e1203867f6911fe99a
gimme 516290b79fdd56c9ef1760880429ec2c03226681
gimme 5165987afff53b6dbb2e0d72bff61b49a14e3adb
gimme 5169f311b3dfd92b0f05fba1a9e93d023647b152
gimme 516a35cab2580ad3defbcf96ce8eedcc4d7830c8
gimme 517155f1d715173727c94f0ef9348a8282e091b4
gimme 51751bc7d65bda39ca5dc3b5f5a75288b0cbf0f4
gimme 51766059f25b34a6743caa5d608e3c9d1a5d5292
gimme 51784b5a0339df14a9b0a4248861a60f86516ee4
gimme 517e1199143e0e76301fa9ced01ee006c263e352
gimme 518597bbe78226ba0644796892a86d7ee7dc6ba9
gimme 5188d70cff8cd49a04c14f4b2fc41b2dd29fc8dc
gimme 518c90316af7a92baf039bc8389016bfb1b63f95
gimme 518cbb35529a55baeca84977211d990a1e9155ec
gimme 519146f86a88efe0280bce8d6918759e3cafc339
gimme 5193991c53ac50fbf9dc7505ba4559468331315f
gimme 519cf32b1c17458f457495e88eaedfa0a855493d
gimme 51a3be6c9222ea81b6996249fdb48f1435bf9710
gimme 51a537603099bc9bdde889a74d333f0f47104996
gimme 51a7d3c9e0e304a370b0ab85dbf76486274cdeba
gimme 51aa590c18f98458e4c33cf6e90d432382e8e3f1
gimme 51b6365077458134e89dd665b99f1fa563130f3a
gimme 51bd70abc208fd5781a6afd2d067738169d81185
gimme 51bf9feb0ef580b0e826196dba58d07193ec687c
gimme 51c01148ca287580f91edcdf69ce814c087cba71
gimme 51c1df4451f41f80732393645bc57c5e51b25452
gimme 51c3a5a5ef5f7297f1ce6eaedc9de8adb9dac49f
gimme 51ce720c4808ffa348e83e2a32319b2c559b57ba
gimme 51db7daab5129d9a7c4ded68ac9670c960e5ed8d
gimme 51dcd8fff8a2f85c7fc64b1deafc21be18d35cba
gimme 51eb7af2fabc26b4812418d9dbda06e54d42fe0f
gimme 51ef7cfd4ae044b8eb4053bcc51d36708ba88b40
gimme 51f5cc3d072671a5d8bed282d8ff9375dbf0921f
gimme 51f7ac6d4befd5379b376ceea820b624a9765509
gimme 51f8fc0df02fb2c3215e54922749da083051cbd9
gimme 51fcda7eef0e16be045a698438c1a67d52e29ceb
gimme 51fe3e68ffcc129a9727e1fc3729ad4b391f04fa
gimme 520164abfa74fe59e8c14b63565008cc930c76cc
gimme 5208fc72724bab7028fe6703f23ec74c86260e2d
gimme 520c9f988820aaf6a895bf9d3690979901e95383
gimme 5216ba61434a4f05b02cdff6da1d647c04213c56
gimme 5218f0724790ba189a27d6fdd849bba82004c324
gimme 5221aea55e4a48797e1af4332e05944fda1a1348
gimme 522709fcd01809472c88202fbe7f987b3b4acc96
gimme 522b934af51eba23930ba9b129bbb9fb43ef44f7
gimme 522c4b6dd3e76af1cc01a787ae5bc60e4d490367
gimme 5231f6c020f12296d07f8d0115b74c6cf09abb2f
gimme 5237a934f39604755ab97a04f8bbb82fa0c9b512
gimme 52393708283f9fa61fd644f5811ee5831e220cb0
gimme 5239cfdceecc6e517c024339f7bcff376aa4ac82
gimme 5241d2725c171ddd28330772f944f2393ebc9cd3
gimme 5243a25e3945082813410a5daf902d78c370c6a5
gimme 5243ef19a04a3f71c33159baed286a73ed7aa2d5
gimme 524eaa4310adbc88f9dc9cd64dcfad9cc150c3cb
gimme 525002ce6eb9638c3153447e558b96845439bed2
gimme 52509a5485c624bc4d6ac4277c952f29da68d9e2
gimme 5255fc0b24915572f1c727118eb1b423fa5dd930
gimme 525de5788e0aa86ab36cffcc5ff5ef000ef8ffa8
gimme 52600c2d823d41400e315d66e5a3ea4e28537c57
gimme 5260c9920010490c59e2768fe3ae2dd0c1921aee
gimme 526566ed94c0a98cc3643cbe03d41b964399d3e8
gimme 5266daa3a4fcb68d92c137e118454fa4c8fda481
gimme 5269701bfdfa02b2c37354366520f755d1301c86
gimme 5269b579b86446b2df2de92d0e678c1730994a78
gimme 52732617e8e1ca905b27b9f481a766f7d9b634ad
gimme 5275a4e3116cac96a3151b02810b40fa14067d63
gimme 5283da29010825a0a5890936e9c7a5a8d8cc5639
gimme 5285d63815584dcdcd27b2fc167fa30547e91f39
gimme

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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):

kamloops$ fossil pull --verbose
Pull from http://netbsd.sonnenberger.org
Bytes  Cards  Artifacts Deltas
Sent:9546202  0  0
Received:1412 31  0  0
Pull done, sent: 5076  received: 1031  ip: 135.28.13.11
kamloops$ fossil timel
=== 2015-06-04 ===
16:11:48 [84f521116f] *CURRENT* Whitespace and macro fixes. (user: wiz
tags: trunk)
16:01:09 [ea0e467f7e] Document the options as a list instead of
embedded text. (user: christos tags: trunk)
09:45:43 [53ab9b8bbe] Ticket 822. (user: msaitoh tags: netbsd-7)
09:44:57 [04f6adcaf6] Pull up following revision(s) (requested by
hsuenaga in ticket #822): sys/net/if_gif.c: revision 1.85
sys/net/if_gif.c: revision 1.86 Obtain softnet_lock before entering IP
networking
 stack from gif software interrupt. Include sys/socketvar.h
for softnet_lock. (user: msaitoh tags: netbsd-7)
09:20:12 [e24f89baf3] Whitespace fixes. (user: wiz tags: trunk)
09:19:59 [6c6ebdc911] Pull out route lookups from L2 output routines
Route lookups for routes of RTF_GATEWAY were done in L2 output
routines such as ether_output, but they should be done in L3 i.e.,
before
 L2 output routines. This change places the lookups between L3
output routines (say ip_output) and the L2 output routines. The change
is based on dyoung's patch submitted in the thread: https://mail-
 index.netbsd.org/tech-net/2013/02/01/msg003847.html You can
find out detailed investigations by dyoung about the issue in there.
Note that the change introduces a workaround for MPLS. ether_output
 knew that it needs to fill the ethertype of a frame as MPLS,
based on a tag of an original route (rtentry), but now we don't pass
it to ehter_output. So we have to tell that in another way. We use
 mtag to do so for now, which introduces some overhead. We
should fix it somehow in the future. Discussed on tech-kern and
tech-net. (user: ozaki-r tags: trunk)
[...]


On 6/19/15, bch brad.har...@gmail.com wrote:
 include fossil-users@ ...

 -- Forwarded message --
 From: bch brad.har...@gmail.com
 Date: Fri, 19 Jun 2015 12:05:13 -0700
 Subject: Re: [fossil-users] DB corruption and error msg string
 mis-handling.
 To: Andy Bradford amb-fos...@bradfords.org

 Hi.

 I got around to reviewing this, and found a couple interesting things:

 1) some of the reported 0-byte entries are now gone

 2) Here is report from the single remaining offender:

 rid: size calculated_size_of_blob, reported_uuid, calculated_sha1
 ==
 1355: 0 calculated_realsize(12),
 reported_uuid(da39a3ee5e6b4b0d3255bfef95601890afd80709),
 calcuated_sha(b844a4567c46013e52dc15a63bda87b7160266ef)

 On 6/11/15, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said bch on Mon, 08 Jun 2015 15:31:31 -0700:

 rid: size
 ==

 What are some of the SHA1 hashes for these RIDs?

 Thanks,

 Andy
 --
 TAI64 timestamp: 40005579f382




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fwd: DB corruption and error msg string mis-handling.

[bch]

include fossil-users@ ...

-- Forwarded message --
From: bch brad.har...@gmail.com
Date: Fri, 19 Jun 2015 12:05:13 -0700
Subject: Re: [fossil-users] DB corruption and error msg string mis-handling.
To: Andy Bradford amb-fos...@bradfords.org

Hi.

I got around to reviewing this, and found a couple interesting things:

1) some of the reported 0-byte entries are now gone

2) Here is report from the single remaining offender:

rid: size calculated_size_of_blob, reported_uuid, calculated_sha1
==
1355: 0 calculated_realsize(12),
reported_uuid(da39a3ee5e6b4b0d3255bfef95601890afd80709),
calcuated_sha(b844a4567c46013e52dc15a63bda87b7160266ef)

On 6/11/15, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said bch on Mon, 08 Jun 2015 15:31:31 -0700:

 rid: size
 ==

 What are some of the SHA1 hashes for these RIDs?

 Thanks,

 Andy
 --
 TAI64 timestamp: 40005579f382



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Issue with cloning a repo

[bch]

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 jacek.c...@gmail.com wrote:

 As stated in the original question 'ssh SERVERNAME' works fine, which
 means 'ping SERVERNAME' can also resolve the name ok.

 2015-06-17 13:44 GMT+01:00 Stephan Beal sgb...@googlemail.com:

 On Tue, Jun 16, 2015 at 5:44 PM, Jacek Cała jacek.c...@gmail.com wrote:

 works perfectly fine. It's not urgent for me because I can work using IP
 but I'd appreciate any hints how it may be solved.


 Try:

 ping SERVERNAME

 If that results in the same error then the problem is your DNS config or
 access to the DNS server.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] SQLITE_BUSY ?

[bch]

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
RMD160 (test-unit-3.1.2.gem) = 61bf11396fa9dd89ca62d91eba086ade7f0927c4
Size (test-unit-3.1.2.gem) = 122368 bytes
file fbef11fe9e510682756a77c987e97831b3c77899
d714600a9514dad3549baca1df0cce813378a375 8293
Arl
i@0,1wn:Update\sruby-shoulda-matchers\sto\s2.8.0.\n\npkgsrc\schange:\sallow\sbuild\son\sRuby\s2.2.\n\n#\s2.8.0\n\n###\sDeprecations\n\n*\s`ensure_length_of`\shas\sbeen\srenamed\sto\s`validate_length_of`.\n\s\s`ensure_length_of`\sis\sdeprecated\sand\swill\sbe\sremoved\sin\s3.0.0.\n\n*\s`set_the_flash`\shas\sbeen\srenamed\sto\s`set_flash`.\s`set_the_flash`\sis\n\s\sdeprecated\sand\swill\sbe\sremoved\sin\s3.0.0.\n\n*\s`set_session(:foo)`\sis\sdeprecated\sin\sfavor\sof\s`set_session[:foo]`.\n\s\s`set_session(:foo)`\swill\sbe\sinvalid\ssyntax\sin\s3.0.0.\n\n*\sUsing\s`should\sset_session[:key].to(nil)`\sto\sassert\sthat\sthat\sa\svalue\shas\snot\n\s\sbeen\sset\sis\sdeprecated.\sPlease\suse\s`should_not\sset_session[:key]`\sinstead.\n\s\sIn\s3.0.0,\s`should\sset_session[:key].to(nil)`\swill\sonly\spass\sif\sthe\svalue\sis\n\s\struly\snil.\n\n###\sBug\sfixes\n\n*\sFix\s`delegate_method`\sso\sthat\sit\sworks\sagain\swith\sshoulda-context.\s([#591])\n\n*\sFix\s`validate_uniqueness_of`\swhen\s
 
used\swith\s`scoped_to`\sso\sthat\swhen\sone\sof\n\s\sthe\sscope\sattributes\sis\sa\spolymorphic\s`*_type`\sattribute\sand\sthe\smodel\shas\n\s\sanother\svalidation\son\sthe\ssame\sattribute,\sthe\smatcher\sdoes\snot\sfail\swith\san\n\s\serror.\s([#592])\n\n*\sFix\s`has_many`\sused\swith\s`through`\sso\sthat\swhen\sthe\sassociation\sdoes\snot\n\s\sexist,\sand\sthe\smatcher\sfails,\sit\sdoes\snot\sraise\san\serror\swhen\sproducing\sthe\n\s\sfailure\smessage.\s([#588])\n\n*\sFix\s`have_and_belong_to_many`\sused\swith\s`join_table`\sso\sthat\sit\sdoes\snot\sfail\n\s\swhen\s`foreign_key`\sand/or\s`association_foreign_key`\swas\sspecified\son\sthe\n\s\sassociation\sas\sa\ssymbol\sinstead\sof\sa\sstring.\s([#584])\n\n*\sFix\s`allow_value`\swhen\san\si18n\stranslation\skey\sis\spassed\sto\s`with_message`\sand\n\s\sthe\s`:against`\soption\sis\sused\sto\sspecify\san\salternate\sattribute.\sA\sbug\shere\n\s\salso\shappened\sto\saffect\s`validate_confirmation_of`\swhen\san\si18n\stranslation\n
 
\s\skey\sis\spassed\sto\s`with_message`.\s([#593])\n\n*\sFix\s`class_name`\squalifier\sfor\sassociation\smatchers\sso\sthat\sif\sthe\smodel\sbeing\n\s\sreferenced\sis\snamespaced,\sthe\smatcher\swill\scorrectly\sresolve\sthe\sclass\sbefore\n\s\schecking\sit\sagainst\sthe\sassociation's\s`class_name`.\s([#537])\n\n*\sFix\s`validate_inclusion_of`\sused\swith\s`with_message`\sso\sthat\sit\sfails\sif\sgiven\n\s\sa\smessage\sthat\sdoes\snot\smatch\sthe\smessage\son\sthe\svalidation.\s([#598])\n\n*\sFix\s`route`\smatcher\sso\sthat\swhen\scontroller\sand\saction\sare\sspecified\sin\shash\n\s\snotation\s(e.g.\s`posts#show`),\sroute\sparameters\ssuch\sas\s`id`\sdo\snot\sneed\sto\sbe\n\s\sspecified\sas\sa\sstring\sbut\smay\sbe\sspecified\sas\sa\snumber\sas\swell.\s([#602])\n\n*\sFix\s`allow_value`,\s`validate_numericality_of`\sand\s`validate_inclusion_of`\sso\n\s\sthat\sthey\shandle\sRangeErrors\semitted\sfrom\sActiveRecord\s4.2.\sThese\sexceptions\n\s\sarise\swhenever\swe\sattempt\sto\sset\s
 
an\sattribute\susing\sa\svalue\sthat\slies\soutside\n\s\sthe\srange\sof\sthe\scolumn\s(assuming\sthe\scolumn\sis\san\sinteger).\sRangeError\sis\snow\n\s\streated\sspecially,\sfailing\sthe\stest\sinstead\sof\sbubbling\sup\sas\san\serror.\n\s\s([#634],\s[#637],\s[#642])\n\n###\sFeatures\n\n*\sAdd\sability\sto\stest\s`:primary_key`\soption\son\sassociations.\s([#597])\n\n*\sAdd\s`allow_blank`\squalifier\sto\s`validate_uniqueness_of`\sto\scomplement\n\s\sthe\s`allow_blank`\soption.\s([#543])\n\n*\sChange\s`set_session`\sso\sthat\s#[]\sand\s#to\squalifiers\sare\soptional,\ssimilar\sto\n\s\s`set_flash`.\sThat\sis,\syou\scan\snow\ssay\s`should\sset_session`\sto\sassert\sthat\sany\n\s\sflash\svalue\shas\sbeen\sset,\sor\s`should\sset_session.to('value')`\sto\sassert\sthat\n\s\sany\svalue\sin\sthe\ssession\sis\s'value'.\n\n*\sChange\s`set_session`\sso\sthat\sits\s#to\squalifier\ssupports\sregexps,\ssimilar\sto\n\s\s`set_flash`.\n\n*\sAdd\s`with_prefix`\squalifier\sto\s`delegate_method`\sto\sc
 

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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 brad.har...@gmail.com wrote:
 rid: size
 ==

 1355: 0
 2090601: 0
 2090613: 0
 2090654: 0
 2090685: 0
 2090719: 0
 2090744: 0
 2090748: 0
 2090762: 0
 2090769: 0
 2090789: 0
 2090811: 0
 2090821: 0
 2090833: 0
 2090840: 0
 2090845: 0
 2090891: 0
 2090903: 0
 2090918: 0
 2090923: 0
 2090948: 0
 2090964: 0
 2090989: 0
 2091012: 0
 2091035: 0
 2091110: 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 jo...@britannica.bec.de wrote:
 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 mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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 brad.har...@gmail.com wrote:
 There's either a corrupted database or transport corruption occurring
 w/ netbsd-src, but additionally apparent string mis-handling in the
 fossil binary:


 kamloops$ fossil pull
 Pull from http://netbsd.sonnenberger.org
 via proxy: http://one.proxy.att.com:8080
 Round-trips: 3   Artifacts sent: 0  received: 12
 content does not match sha1 hash
 Round-trips: 4   Artifacts sent: 0  received: 13
 content does not match sha1 hashcontent does not match sha1 hash
 Round-trips: 5   Artifacts sent: 0  received: 14
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hash
 Round-trips: 6   Artifacts sent: 0  received: 15
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1 hash
 Round-trips: 7   Artifacts sent: 0  received: 16
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hash
 Round-trips: 8   Artifacts sent: 0  received: 17
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1 hash
 Round-trips: 9   Artifacts sent: 0  received: 18
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hash
 Round-trips: 10   Artifacts sent: 0  received: 19
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1 hash
 Round-trips: 11   Artifacts sent: 0  received: 20
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hash
 Round-trips: 12   Artifacts sent: 0  received: 21
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1 hash
 Round-trips: 13   Artifacts sent: 0  received: 22
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hash
 Round-trips: 14   Artifacts sent: 0  received: 23
 content does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match sha1
 hashcontent does not match sha1 hashcontent does not match 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

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

rid: size
==

1355: 0
2090601: 0
2090613: 0
2090654: 0
2090685: 0
2090719: 0
2090744: 0
2090748: 0
2090762: 0
2090769: 0
2090789: 0
2090811: 0
2090821: 0
2090833: 0
2090840: 0
2090845: 0
2090891: 0
2090903: 0
2090918: 0
2090923: 0
2090948: 0
2090964: 0
2090989: 0
2091012: 0
2091035: 0
2091110: 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 jo...@britannica.bec.de wrote:
 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 mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] DB corruption and error msg string mis-handling.

[bch]

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 jo...@britannica.bec.de wrote:
 On Mon, Jun 08, 2015 at 11:52:20AM -0700, bch wrote:
 There's either a corrupted database or transport corruption occurring
 w/ netbsd-src, but additionally apparent string mis-handling in the
 fossil binary:

 For unknown reasons, sometimes empty artefacts appear. Can you check
 your repo copy?

 Joerg
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] view added tags w.r.t. last check-in

[bch]

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 m.ramak...@gmail.com 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
 changed/new files, and if those report nothing, I am assuming nothing
 needs to be checked in.

 After I add a tag to a repo on the local host, I still need to
 explicitly sync it for it to appear on the host in 'remote-url' - as
 far as I know there's no way to list added tags.

 Thanks,
 Michai
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Segfault in fossil sqlite

[bch]

I applied this.

Thanks.

-bch


On 5/13/15, Warren Young w...@etr-usa.com wrote:
 On May 13, 2015, at 3:20 PM, Richard Hipp d...@sqlite.org wrote:

 On 5/13/15, Warren Young w...@etr-usa.com wrote:
 On May 13, 2015, at 2:29 PM, Richard Hipp d...@sqlite.org wrote:

 On 5/13/15, Warren Young w...@etr-usa.com wrote:
 I got this backtrace from running fossil sqlite under gdb on CentOS
 5:

 el_init() never calls search_init().

 It does in the copy of libedit I'm using here.  src/el.c, line 109.


 Maybe its a symbol conflict between libel and the search_init()
 function of Fossil.

 Nailed it.  I renamed that function, and the symptom is gone.  See the
 attached trivial patch.

 I'm surprised the linker even allows that.

 By the way, I'm talking about NetBSD libedit here.  I don't know anything
 about a libel package.  That may not have the same problem.

  Try rebuilding Fossil without command-line
 editing and see if that clears the problem.

 I already tried that.  (See previous message.)  And yes, it does allow
 fossil sql to run without crashing.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Feature idea: Protected branches

[bch]

On May 11, 2015 8:40 AM, Andy Goth andrew.m.g...@gmail.com wrote:

 On 5/11/2015 9:10 AM, Richard Hipp wrote:
  On 5/11/15, Abilio Marques abili...@gmail.com 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 prevent pushes to certain
  branches, we would have to add knowledge of branches and check-ins to
  the push/pull logic.
 
  Note also that this goes against one of the founding principles of
  Fossil: that the VCS should implement mechanism not policy.  That is
  to say, details of who should be able to check-in to which branches
  and whatnot should not be enforced by the VCS.  Project policies need
  to be enforced by some other means.

 Can TH1/Tcl be used to implement such policies?

 I wonder if it's possible to tie this to the push/pull logic but rather
 the commit and tagging logic, such that the prohibition happens as
 quickly as possible, and the developer isn't in for a surprise when the
 eventual sync takes place but fails.

I suspect this might really be the only safe(ish?) place to attempt the job.

 This leads to a host of questions.  Having local access to a cloned
 repository gives unlimited control, so (unless all committers are
 trusted) the push/pull logic needs to double-check the rules.  Also,
 there's more than one way to put a commit on a branch, so checks need to
 be performed against control artifacts as well as normal check-ins.

 Also I want to draw a comparison to closed branches.  Can closed
 branches be refactored to be implemented in terms of this new facility,
 or can the closed branch feature itself be expanded to provide the
 foundation for limiting write access to branches?

I feel this might be best (as I feel about fork-notification) an offline
test applied to notify. Let social policy manage the sticky issues.

 --
 Andy Goth | andrew.m.goth/at/gmail/dot/com


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[bch]

For reference, a **rough** comparison (diff't repo) -- this repository
does *NOT* have the blob index  (suggested by drh) that I manually
applied to NetBSD-src:


kamloops$ time fossil pull
Pull from http://pkgsrc.sonnenberger.org
Round-trips: 4   Artifacts sent: 0  received: 177
Pull done, sent: 5626  received: 55358  ip: 135.28.13.11
  123.22 real 1.07 user 2.69 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.26 real 0.00 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 brad.har...@gmail.com wrote:
 On 4/27/15, Andy Bradford amb-fos...@bradfords.org 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.28.13.11
 1.43 real 0.00 user 0.10 sys

 Ok, that looks  much better. Notice that it does  not report any warning
 about forks (I'm not sure why it  ever did but perhaps g.rcvid was being
 initialized to  some number that  just happened to  be a valid  rcvid in
 your repository).  Also, the time  is much faster, primarily  because it
 never executed the SQL to begin with.

 So for a  sync that has no  changes, we're good. It  will be interesting
 when you  actually get a  pull that has changes  to see how  the numbers
 compare.


 This seems better this morning -- these metrics are crude, but at
 least they're something.


 kamloops$ time fossil pull
 Pull from http://netbsd.sonnenberger.org
 Round-trips: 2   Artifacts sent: 0  received: 10
 Pull done, sent: 906  received: 4596  ip: 135.28.13.11
 9.96 real 0.72 user 0.12 sys
 kamloops$ time fossil pull
 Pull from http://netbsd.sonnenberger.org
 Round-trips: 1   Artifacts sent: 0  received: 0
 Pull done, sent: 337  received: 1617  ip: 135.28.13.11
 2.64 real 0.00 user 0.01 sys
 kamloops$ time fossil pull
 Pull from http://netbsd.sonnenberger.org
 Round-trips: 1   Artifacts sent: 0  received: 0
 Pull done, sent: 337  received: 1617  ip: 135.28.13.11
 1.45 real 0.00 user 0.01 sys
 kamloops$ time fossil pull
 Pull from http://netbsd.sonnenberger.org
 Round-trips: 1   Artifacts sent: 0  received: 0
 Pull done, sent: 337  received: 1617  ip: 135.28.13.11
 1.61 real 0.00 user 0.01 sys
 kamloops$ time fossil pull
 Pull from http://netbsd.sonnenberger.org
 Round-trips: 1   Artifacts sent: 0  received: 0
 Pull done, sent: 339  received: 1617  ip: 135.28.13.11
 1.32 real 0.00 user 0.01 sys


 Thanks,

 Andy

 p.s. still cloning (looks to be 50% done).
 --
 TAI64 timestamp: 4000553eeaaf




___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[bch]

On 4/27/15, Andy Bradford amb-fos...@bradfords.org 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.28.13.11
 1.43 real 0.00 user 0.10 sys

 Ok, that looks  much better. Notice that it does  not report any warning
 about forks (I'm not sure why it  ever did but perhaps g.rcvid was being
 initialized to  some number that  just happened to  be a valid  rcvid in
 your repository).  Also, the time  is much faster, primarily  because it
 never executed the SQL to begin with.

 So for a  sync that has no  changes, we're good. It  will be interesting
 when you  actually get a  pull that has changes  to see how  the numbers
 compare.


This seems better this morning -- these metrics are crude, but at
least they're something.


kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
Round-trips: 2   Artifacts sent: 0  received: 10
Pull done, sent: 906  received: 4596  ip: 135.28.13.11
9.96 real 0.72 user 0.12 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1617  ip: 135.28.13.11
2.64 real 0.00 user 0.01 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1617  ip: 135.28.13.11
1.45 real 0.00 user 0.01 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1617  ip: 135.28.13.11
1.61 real 0.00 user 0.01 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 339  received: 1617  ip: 135.28.13.11
1.32 real 0.00 user 0.01 sys


 Thanks,

 Andy

 p.s. still cloning (looks to be 50% done).
 --
 TAI64 timestamp: 4000553eeaaf



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[bch]

kamloops$ fossil version
This is fossil version 1.32 [440ed5da09] 2015-04-27 23:54:38 UTC


And to be clear -- I'm not complaining about that latest pull -- this
set of metrics we're collecting and this testing is incredibly
low-tech, so it's hard to infer very much from them. I mention 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 d...@sqlite.org wrote:
 On 4/28/15, bch brad.har...@gmail.com wrote:
 For reference, a **rough** comparison (diff't repo) -- this repository
 does *NOT* have the blob index  (suggested by drh) that I manually
 applied to NetBSD-src:


 kamloops$ time fossil pull
 Pull from http://pkgsrc.sonnenberger.org
 Round-trips: 4   Artifacts sent: 0  received: 177
 Pull done, sent: 5626  received: 55358  ip: 135.28.13.11
   123.22 real 1.07 user 2.69 sys

 For me, a pull against http://netbsd.sonnenberger.org is fast now even
 without the new index, probably because of Andy's change at
 https://www.fossil-scm.org/fossil/info/440ed5da095da581 - are you
 using the latest code, Brad?

 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[bch]

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 a network run that took
~1s.

2) Do we not have a policy yet about dumping unratified code in
[trunk] ? If not, I vote please do not do this



On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said Richard Hipp on Sun, 26 Apr 2015 18:34:23 -0400:

 The forks  query parameter  to the /timeline  page now  shows recent
 forks in  the check-in DAG. For  this page, a fork  means a check-in
 with two or  more children in the  same branch. No attempt  is made to
 distinguish between forks that have  been resolved and those that have
 not.

 I like it.  Works great here.

 Thanks,

 Andy
 --
 TAI64 timestamp: 4000553e91f0


 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[bch]

Creating index now...

1) This demonstrates (yet again) what a good choice sql was as the
high-level language to implement fossil

I think enough churn has happened that this isn't necessarily
conclusive (if i'd known of the fallout, I'd have had a pre-problem
snapshot of the repo set aside so I could faithfully recreate all
steps at whim), but anyway, here are my results after running the
index build on the backing netbsd_src.fsl.


kamloops$ fossil version
This is fossil version 1.32 [fc3d9f52ee] 2015-04-27 19:27:59 UTC
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 338  received: 1367  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
5.90 real 4.01 user 0.28 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
6.20 real 3.91 user 0.38 sys
kamloops$



Then I closed and re-opened the repo into my working dir (both those
(untimed) took quite a while), and re-running the pull:

kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 337  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
   19.96 real 3.93 user 0.49 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 338  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
6.95 real 3.95 user 0.28 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 336  received: 1368  ip: 135.28.13.11
* WARNING: a fork has occurred *
use fossil leaves -multiple for more details.
5.69 real 3.89 user 0.32 sys
kamloops$ time fossil pull
Pull from http://netbsd.sonnenberger.org
via proxy: http://one.proxy.att.com:8080
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 338  received: 1368  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 happen in the canonical
CVS repo.

-bch

On 4/27/15, Richard Hipp d...@sqlite.org wrote:
 On 4/27/15, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said Richard Hipp on Mon, 27 Apr 2015 20:28:26 -0400:

 .timer on

 That's excellent!  I was wondering if  sqlite's command line tool  had a
 profiling  tool (having  thought of  Tcl's  time as  a useful  profiling
 feature).

 I'll play around with this some to see what various results I get.


 FWIW, I created that index on Joerg's net-bsd repo and it made a Big
 Improvement in performance there.

 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Testing. Was: Two trunks?

[bch]

On Apr 26, 2015 1:00 PM, j. van den hoff veedeeh...@googlemail.com
wrote:

 On Sun, 26 Apr 2015 19:51:44 +0200, Matt Welland mattrwell...@gmail.com
wrote:

 I like this idea. I will test this branch Monday.

 +1

 On Sun, Apr 26, 2015 at 10:16 AM, Jan Nijtmans jan.nijtm...@gmail.com
 wrote:

 2015-04-26 12:54 GMT+02:00 Richard Hipp d...@sqlite.org:
  Yes, but it is not a fork.  And so we shouldn't call it fossil forks
  since that would prevent us from creating a fossil forks command
  that actually lists real forks.
 
  Perhaps the command should be fossil warnings or fossil concerns
  and it should report all topological features that are worrisome to
  some users.  (Are there any other graph topology features besides
  multiple leaves on the same branch that people are concerned about?)

 Or, maybe just combine it with fossil info and use the more general


 +1


 term ambigeous branch (of which fork is a special case)


 which term many people would not understand, I'm afraid... some other
wording would be better I believe. actually the previous description
multiple leaves on trunk (or branch XXX) seems much clearer to me.


This touches on something I think should be considered, which is the
judgment that the report is expressing. This is why I like our ticket
system versus, say, a bug tracker. The implications are:

1) what are a readers expectations of the output

2) (per 1) what are developers expected to support (managing false
negatives, false positives, etc, etc)

3) the general tone of the experience

4) level/placement of responsibility that the tool (fossil) and operator
are assuming


 https://www.fossil-scm.org/index.html/info/4359bd8df2119799

 Regards,
 Jan Nijtmans
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Two trunks?

[bch]

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 investigate and resolve by the existing abilities we already have. I
think fossil has done a reasonable(ish) job staying simple, and I think
that will be the key to it's continued success.
On Apr 18, 2015 6:53 AM, Richard Hipp d...@sqlite.org wrote:

 Fossil has, for many years, detected potential forks prior to commit
 and warned about them, or within the past few years has disallowed the
 commit completely without the --allow-fork option.  If two users are
 committing concurrently, the fork detection fails, but even then the
 second user gets a message  warning: a fork has occurred *.
 The problem arises when the second user does not notice, or chooses to
 ignore, this message and the situational awareness within the
 organization is such that nobody notices the fork plainly displayed on
 the timeline.  The check-in on the fork gets overlooked and fails to
 make it into the next release.

 Proposed solutions include denying the ability to commit or push a
 fork.  But doesn't that just make the problem worse?  We've already
 established that users are in the habit of ignoring scary fork
 warnings.  Wouldn't they also just ignore the fact that the commit or
 push failed?  With a fork, at least the content is safely on the
 server and can be easily recovered by anybody willing to take a moment
 to review the timeline.  But if the change never gets pushed, the
 content is only on the developer's machine, out of view and
 unrecoverable by anyone except the original developer.  And if it
 never gets committed, then the work might be lost even to the original
 developer.  How is that an improvement?

 Other proposed changes include more frequent nagging about forks.  The
 issue is less clear-cut, but I still worry that it might contribute to
 warning fatigue.  I go by the motto that you should always distrust
 any computer program that thinks it knows more than you do.  Constant
 nagging about forks seems to move Fossil in the direction of programs
 that I would not trust.  This is not to say that there shouldn't be
 warnings, but there needs to be balance.

 The fossil update|co|checkout BRANCH command takes you to the most
 recent check-in for BRANCH.  If BRANCH contains leaves that are not
 the most recent check-in, it seems like this would be a good time to
 issue a warning.  The command might even fail with the message that
 BRANCH is ambiguous and then provide a list of all possible SHA1
 values that BRANCH could resolve to, enabling the user to retry the
 command with an unambiguous SHA1 hash.

 Another approach would be to provide commands (such as fossil forks)
 that actually show problems in the tree, for people who are actually
 interested - for example the release manager.  A web-version of
 fossil forks with graphical pictures of each fork would be nice to
 have.

 One other thing:  We ought to intentionally preserve several forks
 within the Fossil self-hosting repository, so that we always have test
 cases for the above mechanisms readily at hand.
 --
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Can fossil be used to apply a diff patch?

[bch]

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 w...@etr-usa.com 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)?

 Fossil itself doesn't do that.  You use the patch(1) utility for that, which
 expects a unified diff.  (fossil diff produces output in that format by
 default, but diff(1) does not.)

 If you want something that works entirely with Fossil tools, you should be
 using the new bundle features.  This creates a sub-repository containing
 a given change set, including all of the details Fossil tracks that do not
 appear in fossil diff output.
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Symlink trouble

[bch]

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). Are the problematic uses of symlinks different from that?
On Apr 7, 2015 11:14 PM, Joe Mistachkin sql...@mistachkin.com wrote:


 Andy Goth wrote:
 
  My andygoth-versioned-open branch (just checked in) addresses this
  problem and seems to fix the symlink issue.  However, the Fossil coding
  style is rather alien to me, particularly the way it leaks memory on
  purpose, so the way I'm doing things may not be the best.  Please have a
  look, and feel free to ask questions and make suggestions and further
  changes.
 

 I've made some tweaks on the branch.  Here are the highlights:

 1. By changing the return code checking for historical_version_of_file(),
which apparently returns greater than zero on success.

 2. Set noWarn based on the historical version of that file, if it exists.

 3. Unrelated: Removed superfluous slash in the .fossil-settings path
used by print_setting().

 --
 Joe Mistachkin

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Symlink trouble

[bch]

On 4/8/15, Andy Goth andrew.m.g...@gmail.com 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 management to a
 script that will be part of a release generation process (with
 repository != release in mind). Are the problematic uses of symlinks
 different from that?

 I prefer your approach, however I did not get to pick in this instance
 since I am trying to import an existing repository from ClearCase,
 actually a snapshot, and it uses symlinks.  Furthermore I think some of
 the symlinks are used stupidly, but once again I don't get to pick.

1) It's nice to hear that others are like this

2) That you imported a (in our opinion) poorly-laid-out project is a
good point to remember -- it's not always greenfield repositories that
we work with. Thanks for the reminder.

Cheers,

 --
 Andy Goth | andrew.m.goth/at/gmail/dot/com
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Multiple attachments to a repo

[bch]

Hi drh...

over the course of a previous discussion you said you have multiple
connections (separated in their own directories) to one repo to keep
your logical thoughts contained.

I was going to ask how you keep track of your various checkouts, but
discovered it myself. In case others are interested in replicating
this workflow:


fossil all ls --ckout


for example, if I've got a repo  kewl.fsl

and check it out in ./work/kewl_async, and ./work/kewl_security and
./work/kewl_perf, I could do a:

fossil all ls -ckout | grep kewl and get a clue about my various
working 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 share.

Happy fossilling,

-bch
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] New timeline display options

[bch]

On Mar 31, 2015 8:26 PM, Matt Welland mattrwell...@gmail.com wrote:



 On Tue, Mar 31, 2015 at 5:48 PM, bch brad.har...@gmail.com wrote:

 Hi Matt.

 Would picking the branch you care about (like this:

http://fossil-scm.org/index.html/timeline?r=skin-xekrindc=2015-03-25+21%3A52%3A07n=200
)
 suit your workflow ?


 Hi Brad,

 Yes, I often narrow to the branch like that but that hides the context of
activity on other branches I might be interested in. When scrolling down
through a busy timeline the visual clue of which line belongs to which
branch would be useful to me. I have one section on a timeline with 16
parallel lines and no visual hint as to which is which branch.

 Just my $0.02 ...

That sounds like a valid $0.02 to me. JS/CSS experts: is there such tech
that we could somehow select a vertical graph/branch indicator and have it
highlighted somehow?


 -bch


 On 3/31/15, Matt Welland mattrwell...@gmail.com wrote:
  On Tue, Mar 31, 2015 at 9:20 AM, Andy Bradford 
amb-fos...@bradfords.org
  wrote:
 
  Thus said Matt Welland on Mon, 30 Mar 2015 21:08:49 -0700:
 
   +1 circular nodes, +1 colored  lines, seemed to make visually
tracking
   the branch easier to my eyes. but as Brad said, a matter of style.
 
  Definitely a  matter of style. While  I think both are  pretty, I
prefer
  black edges  (the nodes are  already colored  and align nicely  with
the
  commit messages, and  I find the colored lines  distracting), and
square
  nodes. :-)
 
 
  There is one pragmatic factor. I quite often find myself tracing
timelines
  back over multiple screens and having different colored lines would
really
  help. I'd be cool if this was an option for those who like it.
 
 
 
 
  Andy
  --
  TAI64 timestamp: 4000551ac96a
  ___
  fossil-users mailing list
  fossil-users@lists.fossil-scm.org
  http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 
 
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] New timeline display options

[bch]

Hi Matt.

Would picking the branch you care about (like this:
http://fossil-scm.org/index.html/timeline?r=skin-xekrindc=2015-03-25+21%3A52%3A07n=200)
suit your workflow ?

-bch


On 3/31/15, Matt Welland mattrwell...@gmail.com wrote:
 On Tue, Mar 31, 2015 at 9:20 AM, Andy Bradford amb-fos...@bradfords.org
 wrote:

 Thus said Matt Welland on Mon, 30 Mar 2015 21:08:49 -0700:

  +1 circular nodes, +1 colored  lines, seemed to make visually tracking
  the branch easier to my eyes. but as Brad said, a matter of style.

 Definitely a  matter of style. While  I think both are  pretty, I prefer
 black edges  (the nodes are  already colored  and align nicely  with the
 commit messages, and  I find the colored lines  distracting), and square
 nodes. :-)


 There is one pragmatic factor. I quite often find myself tracing timelines
 back over multiple screens and having different colored lines would really
 help. I'd be cool if this was an option for those who like it.




 Andy
 --
 TAI64 timestamp: 4000551ac96a
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] New timeline display options

[bch]

 +1 circular nodes, -1 colored lines, as a matter of style, imo.
Really nice work, though!

-bch


On 3/30/15, Richard Hipp d...@sqlite.org wrote:
 James Moger's circular timeline nodes and colored timeline graphs are
 easily selectable skin options available to skin designers.  For a
 comparison:

  http://www.fossil-scm.org/fossil/timeline?y=ci
  http://www2.fossil-scm.org/fossil/timeline?y=ci

 --
 D. Richard Hipp
 d...@sqlite.org

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Error: wrong project

[bch]

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 jkna...@kneuro.net wrote:

 And I should have mentioned the Fossil versions:

 Laptop A: 1.32 [5811ecd7cc]
 Laptop B: 1.27 [ccdefa355b]
 Remote server: 1.27 [13ad130920]

 - Joe K


 On Sat, Mar 28, 2015 at 9:19 AM, Joe Knapka jkna...@kneuro.net wrote:

 Hello all,

 Last night I cloned a repository from a remote server to LaptopA using
 the ssh protocol, opened the repo, and made some changes (which I have not
 yet committed).

 This morning I realized that the last time I worked on this project, on a
 different machine LaptopB, I forgot to add a file. So I did fossil add
 missing_file ; fossil commit on LaptopB. Autosync is enabled on both
 laptops. I'm not sure if this is relevant, but when the repository was
 cloned to LaptopB, that was done using an http: URL.

 I went back to LaptopA and did fossil update, only to receive the
 message:

 Error: wrong project

 Any idea what might be happening here?

 Thanks,

 - Joe K

 --
 It is always best to think of reality as perfectly normal.  Since the
 beginning, not one unusual thing has ever happened. - Less Wrong




 --
 It is always best to think of reality as perfectly normal.  Since the
 beginning, not one unusual thing has ever happened. - Less Wrong

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] strangeness

[bch]

Without further information 1) reminds me of quick edits whereby the
timestamp (fossils cheap way of discovering change) may not have
chnanged ? The foolproof (expensive) way of determining changes is
to checksum ea. file (ie: fossil  changes --sha1sum)

What are the conditions that you're editing under, or is there
anything that may be advancing  the timestamp outside your initial
(failed-to-commit) edits ?

-bch

On 3/27/15, j. van den hoff veedeeh...@googlemail.com wrote:
 hi list,

 I have encountered a strange behaviour (of course right now no longer
 reproducible ...).

 setup:

 -- ssh-transport, all permissions fine
 -- local clone configured to use 'autosync'
 -- locally running some variant of 1.32, remotely of 1.31 (so updated
 recently)
 -- two year old repos (so definitely created with distinctly older
 versions of fossil)

 now for the ufos:

 1.
 yesterday I tried `fossil ci' after some edits which led to a silent
 return to the prompt without any actions having been taken. only after 2
 further tries the editor popped up for entering the ci message and the ci
 actually proceeded (and also propated to the server as it should, given
 the `autosync' setting

 2.
 today I did 2 checkins just fine (seemingly) including getting the
 autosync-related messages generated by fossil. but after the checkin the
 changes had not propagated to the remote repo. I had to do an explicit
 push to get the changes there.

 In a couple of years using fossil I have never encountered something like
 this. any ideas what might be going on here?

 thx/j

 --
 Using Opera's revolutionary email client: http://www.opera.com/mail/
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil diff -w!

[bch]

I presume you're using the call-out or hook feature of:

$ fossil set diff-command diff -bu

so that it's permanently set ?

-bch


On 3/25/15, Warren Young w...@etr-usa.com wrote:
 I just found another reason to be happy I switched from Subversion.  Many
 years ago, I constructed this horrid alias to get whitespace-insensitive
 diffs out of svn:

   alias sdw='svn diff --diff-cmd /usr/bin/diff --extensions -buwB'

 This was necessary because at the time, svn diff only had flags affecting
 the operation of the VCS-level parts of svn.  There were none affecting the
 diff operation itself: it always gave the same output format.

 I now see that more recent versions of svn allow --extensions to affect the
 internal diff implementation, too, so that I could rewrite the alias as

   alias sdw='svn diff --extensions -buw'

 Nevertheless, Fossil still has an advantage is that you don't need
 --extensions or -b, or -u, so the corresponding Fossil command is quite a
 bit shorter and more POSIX-like.

 I give a hearty Thank you! to whoever wrote that!
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users