[fossil-users] OT: security/entropy (was Re: New Fossil user experiences)

[David Mason]

I use a password generator of my own design - basically takes the userid,
concatenated with a fairly long secret phrase, and then I do SHA1 and
convert it to base64, giving a password like:
Acgq75VpCWjdsJaa5abe9JeX3I (don't worry, this isn't a real password to
anything)

After Warren's comment about wanting 256 bits of entropy, I fed this
through an online entropy calculator (https://planetcalc.com/2476/ - I
wouldn't feed a real password through anything on the web!), and got 4.29
bits of Shannon entropy (replacing a character with a special character
didn't change the number). Calculating it on a whole web page only gave
5.41.

So I tried:
dd if=/dev/random bs=100 count=1|od -c
and the result only gave 5.00 bits

So I'm guessing this isn't what he meant.

http://rumkin.com/tools/password/passchk.php does a version and it says my
fake password above is 130 bits. The 800 bits of random converted to hex
gives 779 bits

So I guess this is what Warren had in mind.  Posting this in case it helps
somebody on the list.

Thanks  ../Dave
___
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 slideshow on fossil homepage

[David Mason]

I like it, though the timing is pretty fast, and some slides are truncated.

On 9 July 2018 at 12:06, mario  wrote:

> As followup to last month` Show time.. discussion:
>
> → http://fossilslideshow.tmp.include-once.org/
>
> (Take in mind this ain't a mockup yet; just as example.)
>
> Why oh why?
> ===
>
> Our current homepage is a bit wall of textish / too bland
> I'd think. While it already gets all interesting features
> across, it's not likely enticing to new users.
>
> And such a slideshow (colors do draw eyes) would more easily
> showcase the advantages of Fossil.
>
> Pros & Cons
> ===
>
> Apart from really matching it up with the default theme,
> all the usual drawbacks of a homepage slideshow apply:
>
> · It's somewhat of a generic fad (every other pet project
>   homepage has one these days)
> · Makes it harder to follow each point (slide timing…)
> · Needs more trimming down of slides + repeating some links
>   in the doc section.
> · Images might be quite large (→ static files).
> · "CGI" is already too abstract for a concrete pictogram.
> · I feel it's slightly betraying the documentation-nature
>   of the Fossil homepage.
> · And if implemented, people would want to have it with their
>   own Fossil setup (= must to be slim enough to be embedded
>   with one of the skins).
>
> On the other hand it's a cheap feature:
>
> · No jQuery necessary (there's even CSS-only slideshows)
> · Kept the HTML list with minor adaptions
> · Looks ok in w3m or dillo still.
> · I don't think we'd even need to hire a graphics people to
>   design something neat here.
> · Allows for less shy comparisons with Git/Hub/Lab.
> · With all the work and features that went into Fossil, it's
>   perfectly warranted to show off a bit.
>
> Discussion
> ==
>
> Is this something the Fossil homepage should have?
>
> Any strong opinions or thoughts on image bloat?
>
> Who would want to partake / design one of the slideshow
> images? (archeology-themed for obvious reasons!)
>
> Cutting down on intro text / feature points.
> → How much is too much?
> → Or add *more* links even?
>
> Can we also expand the homepage documentation list into
> e.g. a three pane list (like the Apache manual):
> → users, → developers, → quick overview sections?
>
> Rephrasing
> ==
> (This is going to become the lengthier discussion…)
>
> There's a few headlines and key points which could be
> adapted IMO (without overzealous hype/marketing).
> For instance "mature + robust". Or "unobtrusive" in comparison
> to Git.
> And "fully customizable" instead of just themeable (because
> we have TH1, and a JSON API, not just the skins).
>
> One thing I'd also like to see more prominently are links to
> Hydra, ChiselApp, or even fossilrepos.sourceforge.net perhaps.
>
> Technical minutae
> =
>
> Back to the example //fossilslideshow.tmp.include-once.org/
> A few thoughts on simplifying:
>
> · The img tags could be slashed by using background-image
>   and no-repeat instead.
> · With transform and @keyframe, one could get rid of the
>   JavaScript entirely
> · Not sure if back/forward buttons make sense. But a :hover
>   stop of the slides would make sense at least.
> · If anyone is already using a simpler JS-snippet, please..
> · Not sure if embedding SVG makes sense.
> · I'd prefer the quick links floater to stay / not sure if the
>   logo needs to remain.
> ___
> 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] [minor] src/style.c:427 → "%

[David Mason]

Sorry if I was confusing... You'd only have one body tag, but the class
might change while the page is loaded... and it might be initialized to
something.

You might have CSS like:
-
div.first, div.second, div.third {display: none}
body.start div.first,
body.next div.second,
body.last div.third {display: block}
--
Then a body like: 

And some Javascript that did: document.body.className="next";

Note that https://developer.mozilla.org/en-US/docs/Web/HTML/Element/body
points out that you can only have one body in a valid HTML page.

../Dave

On 3 July 2018 at 11:50, Warren Young  wrote:

> On Jul 2, 2018, at 9:38 PM, David Mason  wrote:
> >
> > It's pretty common to put classes on  tags, to use CSS to
> conditionally choose different renderings by simply changing the class of
> the body tag.
>
> I think you’d have to write TH1 code to get Fossil to serve more than one
>  tag on a given repository.
>
> That then makes me wonder if that would be another way to trick Fossil
> into serving a second  tag.  Consider this pseudocode:
>
> 
>return [concat ""]
> 
>
> I say “pseudocode” because it’s probably horrid Tcl style, if it compiles
> at all.  I speak only pidgin Tcl these days.
> ___
> 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] [minor] src/style.c:427 → "%

[David Mason]

It's pretty common to put classes on  tags, to use CSS to
conditionally choose different renderings by simply changing the class of
the body tag.

../Dave

On 3 July 2018 at 00:23, mario  wrote:

> Mon, 2 Jul 2018 17:20:17 -0600 Warren Young :
>
> > Under what conditions would you have two different  tags in a
> > single document differing only by class, and thus need a CSS selector
> > to differentiate them?
>
> Of course you wouldn't want two  tags.
> But that's exactly the bug I ran into:
>
>
> 
> 
> 
> http://localhost:8080/timeline; />
>  Plugin Meta Data: Timeline
>  href="/timeline.rss" />  href="/style.css?id=6f242840" type="text/css"  media="screen" /> 
> 
> 
>   
>   
>   http://localhost:8080/timeline; />
>   Plugin Meta Data: Timeline
>   
>href="https://media.readthedocs.org/css/sphinx_rtd_theme.css;
> type="text/css" />  href="https://media.readthedocs.org/css/readthedocs-doc-embed.css;
> type="text/css" />
>   
>   
> 
>
>
> If you use a skin header with ``, current trunk
> will prepend a default  section and second  tag:
>
> > /*
> > ** Default HTML page header text through .  If the
> > repository-specific ** header template lacks a  tag, then all
> > of the following is ** prepended.
> > */
>
> It should check for , not just a fixed byte sequence.
>
> ##
>
> > > I see the value in the draft feature, but it's
> > > also a bit confusing still (while working on broken skins at
> > > least.)
> >
> > While I agree that the new skin editor is considerably more
> > complicated to use than the pre-2.5 method, I also don’t see how to
> > make it simpler without losing functionality we gained in that
> > release.
>
> TBH, I haven't really given it much more thought.
>
> It's clearly more practical to have secondary skins to work on,
> without harming the active/default template. And being able to
> grant additional edit permissions there is a nifty feature. As
> is the built-in help and step-by-step guide.
>
> It just got in the way for the aforementioned issue.
>
>
> > > - draftN… just treated as saved skins?
> >
> > I don’t see why that couldn’t be done in principle.
> >
> > The main practical problem is that skins can be named in a way that
> > would require ugly URL escaping to be specified in place of the
> > current draftN bit:
> >
> > https://fossil.example.com/Blitz%2C%20No%20Logo%20(built-in)/home
>
> If the PATH_URI detection can only only recognize `draftN` prefixes,
> than having all of them available wouldn't make sense. With the ugly
> percent escaping anyway.
>
> > There is a side-benefit of this change: if someone has a public
> > Fossil instance and one of the end users thinks the default skin is
> > ugly, he can change it by selecting the name of a skin he likes
> > better in the URL.  Currently, you can only change the skin this way
> > in a local clone which you’re running “fossil ui” on.
>
> Rather than extending the internal path dispatcher, supporting a
> plain/per-user cookie migth make sense. -- OTOH, this might already
> be feature creep..
>
>
> > I’m not seeing the value of that change.  The current mechanism is:
> >
> > 1. Select the skin/draft to edit.
> >
> > 2. Click the CSS/Header/Footer/Details edit links.
> >
> > Are you proposing to replace this with a grid, with skin names down
> > the left edge and 4 edit buttons per row to the right of each skin
> > name?  That does not sound like a simplification to me.
>
> It's sort of what came to mind. But indeed, that would probably just
> make it more convoluted.
>
> One simplification in the whole skin conundrum could be merging
> css+header+footer+settings editing into one page (4x textarea)
> however.
> Then it might be presentable in a table/grid scheme:
>
>  check   test
>  boxes   links
>↓   ↓
>   [ ]  Skin name[Edit]
>   [x]  Backup2  [Edit]
>   [ ]  Draft1   [Edit]
>↓
>   [Activate]  [Use as Draft]  [Publish]  [Delete]
>
> With the buttons just acting on the current selection.
>
>  * Could be fewer action buttons though.
>  * [Rename] or [Publish] better part of the css+head+foot editing
>page.
>  * The `Authenticate` option should really be part of the `Display
>Details` settings blob, btw.
>  * It would likely suffice if the template name doubles as test link
>(don't see the need for five test links).
>
> > If you have something different in mind, a graphical mockup or
> > wireframe drawing might help get your point across.
>
> I'm gonna give this a bit more thought. There's quite a lot of
> backend code for the template management already. Not really sure
> if any of this would simplify code or editing workflows.
>
> ___
> 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

Re: [fossil-users] Meta-enhancement

[David Mason]

Great! Thanks.

On 29 June 2018 at 02:24, Warren Young  wrote:

> On Jun 28, 2018, at 8:53 PM, David Mason  wrote:
> >
> > Looks nice. What I meant was: what do I have to change to make it work.
>
> Clone my repository, go into Fossil UI, then navigate to Admin > Tickets.
> Copy as much or as little of what you see there into your Admin > Tickets
> sections as makes sense for your your purposes.
>
> Then do the same for Admin > Skins.  At minimum here, you’ll want my Bugs
> and Wish List button changes.
>
> You need to copy from a local clone because you won’t be able to get into
> my repository’s Admin section via my public Fossil instance, lacking admin
> privileges on that instance.
> ___
> 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] Meta-enhancement

[David Mason]

Looks nice. What I meant was: what do I have to change to make it work.

Thanks  ../Dave

On 28 June 2018 at 18:33, Warren Young  wrote:

> On Jun 28, 2018, at 6:15 AM, David Mason  wrote:
> >
> > where did you make these changes?
>
> It’s most readily seen in this repository:
>
> https://tangentsoft.com/pidp8i
>
> In addition to the reporting changes I previously described, there are
> others, mainly in Admin > Tickets > Common.  For instance, my
> resolution_choices list includes the nonstandard “Implemented” choice,
> which I use instead of “Fixed” when I finish implementing a feature request
> ticket.
>
> Further thoughts on this topic:
>
> Features do sometimes jump multiple levels.  For instance, an idea that
> was once just a good idea — “Medium” in my system — may eventually be
> deemed essential and thus jump straight to Immediate priority.
>
> Features sometimes also fall multiple levels.  A person filing a feature
> request might have what he thinks is a really hot idea (“High”) but when we
> later go through the release planning exercise, management may think it’s a
> bad idea for some reason, so it drops to Low rather than being deleted.  We
> may add a comment on reprioritizing at this point to record who spiked the
> idea, so we know who has to be convinced if the idea comes back up again.
>
> The High priority pool rarely drains, even immediately after planning the
> next release.  We have more great ideas than time to implement them.  We
> just hope to get to those ideas before the world changes enough that the
> feature ideas become worthless, in which case we need more developers:
> we’ve left fruit on the tree.
>
> The Medium pool never drains until the project planners run out of good
> ideas, at which point it’s time to mothball the project.
>
> If the Low pool ever drains, it probably means you’re not capturing enough
> of the organization’s knowledge in Fossil.  After enough member turnover,
> the organization will forget things it should remember.
>
> “Low” may be an idea graveyard in a private repository, but in a public
> repo, it is where features that the core developers are unlikely to get to
> land.  This pool is a good place to point outside contributors, since
> they’re ideas worth keeping but they’re unlikely to conflict with a core
> developer’s plans.  That’s not an exclusive characterization: Medium will
> have more such ideas, just with a higher risk that some core developer has
> his eye on it and has plans to get to it someday.
>
> Fossil’s ticketing system is really quite flexible.  There’s a good chance
> you don’t have to accept things you don’t like about it: the fix might be
> easily accomplished.
> ___
> 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] Meta-enhancement

[David Mason]

Warren, this looks great! Apologies for not knowing, but where did you make
these changes?

On 28 June 2018 at 04:11, Warren Young  wrote:

> On Jun 27, 2018, at 8:16 AM, Richard Hipp  wrote:
> >
> > If I leave [a feature request ticket] open, then
> > people become alarmed at all the open bugs against Fossil.
>
> I solve that problem in my repositories by distinguishing “Bugs” from
> “Feature Requests.”
>
> First, I rename the default “All Tickets” report to “Bugs,” making little
> to no change to it.
>
> Then I create a “Wish List” report with the following SQL, which is
> closely related to the default report:
>
>
> SELECT
>   CASE priority
>WHEN 'Immediate' THEN '#f2dcdc'
>WHEN 'High' THEN '#e8e8bd'
>WHEN 'Medium' THEN '#cfe8bd'
>WHEN 'Low' THEN '#cacae5'
>ELSE '#c8c8c8' END as 'bgcolor',
>   substr(tkt_uuid,1,10) AS '#',
>   datetime(tkt_mtime) AS 'mtime',
>   status,
>   subsystem,
>   title
> FROM ticket
> WHERE (type='Feature Request' or type='Documentation') and status !=
> 'Closed'
> ORDER BY substr(bgcolor, 2) DESC
>
>
> Finally, I replace the Tickets navbar link with “Bugs” and “Wish List”
> links, which each take you to the report of the same name.
>
> Not only does this solve the expectation problem, it means we can then use
> the ticket system as a release planning tool:
>
> - Immediate: features for the next release.  When all such features are
> implemented, the upcoming release goes into beta (feature-complete) state.
>
> - High: things we want to get to in the next release, or maybe the one
> after that
>
> - Medium: feature ideas we like, but which we aren’t willing to commit to
> a particular release
>
> - Low: ideas worth keeping, but which we’re not likely to ever get to.  If
> nothing else, this prevents the same ideas from being re-filed: it says,
> “Yes, someone else has had this idea already, and we’re not likely to
> implement it; patches thoughtfully considered.”
>
>
> Feature requests generally move up and down one priority level at a time,
> if at all.  Ideally, all requests would move up towards Immediate, but in
> reality, many features never make it out of Medium and almost none make it
> out of Low.
> ___
> 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] Meta-enhancement

[David Mason]

On 27 June 2018 at 11:16, Richard Hipp  wrote:

> If a feature request comes in via ticket, I can either leave the
> ticket open for some future date when I might implement the idea, or I
> can close it immediately as "not a bug".  If I leave it open, then
> people become alarmed at all the open bugs against Fossil.  If I close
> it right away, people misunderstand that as rejecting the idea.
> Either way, users end up feeling unhappy.
>

Wouldn't it be better if feature requests didn't count as bugs. And if
tickets were marked as bugs, can't they be redefined as feature requests
(and then left open)? (I apologize for not knowing the details)

../Dave
___
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] Meta-enhancement

[David Mason]

It does seem a bit strange that we all sell the value of fossil partly
because it has a wiki and ticket system built in. but then we don't eat
our own dog food.

I'm no better on my personal projects... but perhaps RSS can also play a
role here. Or if one could subscribe to the email updates for the ticket
system and forum, one could monitor what was being discussed, and click in
to join the discussion.

../Dave

On 26 June 2018 at 14:52, Andy Goth  wrote:

> On 06/26/18 12:42, Richard Hipp wrote:
>
>> On 6/26/18, Andy Goth  wrote:
>>
>>> A forum might be nice, but I don't want to have to enhance Fossil
>>> just to be able to discuss enhancing Fossil!
>>>
>>
>> Initial prototypes for the forum code are already in the tree.  It
>> just needs some more work.
>>
>
> I noticed!  Thank you.
>
> The recent email notification enhancements were made in order to
>> support ongoing Forum development.
>>
>
> I figured that's why you were doing it, and I thought it was very clever
> to recognize that email is useful for more than just forum integration. So
> even if forums end up dropped, we'll still have a major benefit for having
> made the attempt.
>
> Patience, grasshopper.
>>
>
> Naturally.  But even with forums in place, I think there's benefit to
> putting the existing Fossil ticket and wiki systems back in service.
> Email/forums, tickets, and wiki individually serve different goals, but
> they can be used together to implement a workflow management system. Though
> in a sense, wiki is the odd man out.  With good email/forums and tickets,
> wiki isn't really necessary, but nevertheless wiki is commonly used as an
> informal replacement for email/forums and tickets.
>
> --
> Andy Goth | 
>
> ___
> 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 fossil library

[David Mason]

There is nothing wrong with a C library handling its internal processing
using setjmp/longjmp, as long as there's no C++ callbacks or any other way
that C++ code that might use throw/catch can be executed from within calls
to that library.

It's a little bit more work than just replacing the calls to exit with
longjmps.

There are 5 OS resources that exit resolves: CWD, open files, memory, child
processes, and the stack.

stejmp/longjmp only directly resolves the stack, but it provides a hook to
resolve the others.

Fossil appears to be careful with memory allocation too, with very few raw
calls to malloc, so memory allocaions can be unwound.

Again, chdir, and fopen are rarely used raw, so they can also be unwound.
(opendir is called raw in a few places, so they may need a fossil_opendir)

So as I originally said... its a pretty small amount of overhead code to
write to do the cleanup.

BUT, the big advantage is that then libfossil *automatically* gets all the
fossil bug-fixes and some of the improvements for free! Sure seems worth it
to me.

(Note that 3 files that might be the biggest problem: sheel.c, fshell.c,
and main.c) wouldn't be part of libfossil.

../Dave

On 25 June 2018 at 09:52, Dominique Devienne  wrote:

> On Mon, Jun 25, 2018 at 2:30 PM Warren Young  wrote:
>
>> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal 
>> wrote:
>>
>>> Isn't adding hundreds (literally) of gotos just as fraught with
>>> opportunities for failure ;)?
>>>
>>
>> #ifdef LIBFOSSIL
>> #  define FOSSIL_EXIT(n) longjmp(blabla)
>> #else
>> #  define FOSSIL_EXIT(n) exit(n)
>>
> #endif
>>
>
> If there's a libfossil ever, it should be C++ friendly IMHO, i.e. not use
> longjmp :)
>
> But whether it's C's longjmp or C++ throw, that doesn't solve the fact
> fossil doesn't
> cleanup after itself properly, simply because it's exit() based, thus lets
> the OS reclaim
> memory, and I guess all other resources like sockets, etc... That's
> obviously a nonstarter
> for a library, evidenced by all the end/free/finish APIs in SQLite, and
> value destructors
> passed to other APIs. My $0.02. --DD
>
> PS: My own interest in fossil is not in its "less core" Sam advocates for,
> although
>   I do find that prospect very interesting and worthwhile, but it's
> "fast-enough HTTP
>   server and web-app framework" in C using a lightweight template engine
> (TH1), FWIW.
>
> ___
> 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 fossil library

[David Mason]

I was thinking it would be a little more than this, but perhaps:
#  define FOSSIL_EXIT(n) (api_exit_status-=n,longjmp(blabla))
would actually be enough.

And a similar setjmp-calling macro at the beginning of each API function
would be all that would be required there.

../Dave

On 25 June 2018 at 09:37, Stephan Beal  wrote:

> On Mon, Jun 25, 2018 at 2:30 PM Warren Young  wrote:
>
>> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal 
>> wrote:
>>
>>> Isn't adding hundreds (literally) of gotos just as fraught with
>>> opportunities for failure ;)?
>>>
>>
>> #ifdef LIBFOSSIL
>> #  define FOSSIL_EXIT(n) longjmp(blabla)
>> #else
>> #  define FOSSIL_EXIT(n) exit(n)
>> #endif
>>
>
> Yeah, i was exaggerating, but still... i think the required effort is
> being underestimated by at least an order of magnitude. That said: i would
> _absolutely love_ to be proven wrong.
>
> $ sed -i -e 's/exit(/FOSSIL_EXIT(/g' src/*.c
>>
>
> i recommend a slight variation:
>
> perl -i -pe 's/\bexit\(/FOSSIL_EXIT(/g' src/*.c
>
> sed probably also has a \b (at-word-boundary) equivalent, but i'm not as
> well-versed in that flavor of regex.
>
> Sidebar: i once corrupted a fossil checkout db by using $(find . -type f)
> as my target for some perl -i-style refactoring :|. Never perlify your
> sqlite db files.
>
> --
> - 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] A fossil library

[David Mason]

Actually, setjmp/longjmp isn't goto, it's try-catch/throw.

It unwinds the stack, so you can only (correctly) longjmp to a point that
is in the current call-chain. Of course, this is C, so you can screw it up,
but said screw-ups are not subtle! And subtle bugs are the ones to worry
about.

I count 35 direct uses of exit() (2 in fossil_panic, and one in
fossil_exit). I don't know why those 32 calls to exit() don't call
fossil_exit - perhaps they don't want the db closed... but if you replace
those 35 calls with a call to fossil_exit_now then there would be only 1
place that had to do the longjmp logic.

There is often value in re-implementing programs! All I really said was
that it was a mug's game unless fossil-the-program is going to adopt it,
because you'd be constantly tracking the changes of fossil-the-program in
the re-implemented libfossil code.

I unfortunately don't have the time at the moment, or I would certainly try
the experiment.  I suspect your work on libfossil would be an excellent API
definition! Perhaps I can find a student I could interest in the project in
the fall.

../Dave

On 24 June 2018 at 18:48, Stephan Beal  wrote:

> On Sun, Jun 24, 2018 at 11:19 PM David Mason  wrote:
>
>> I really don't understand the reticence to use setjmp/longjmp to turn all
>> of these short-cut exits into library return-to-API trampolines.  It
>>
>
> To be clear: that's my reticence, not Richard's. libfossil was always
> effectively a third-party effort which had Richard's blessing.
>
> My aversion to setjmp/longjmp is that they're effectively global gotos,
> and gotos, except in very tightly-controlled circumstances, quickly
> produces spaghetti messes.
>
> would allow you to retain all the existing fossil codebase.  Rewriting the
>> code into library form is an interesting project, but it seems like a huge
>> amount of work and unless Richard is going to change fossil to use the API,
>> it is also going to be a huge ongoing maintenance nightmare and fraught
>> with opportunities for failure.
>>
>
> Isn't adding hundreds (literally) of gotos just as fraught with
> opportunities for failure ;)?
>
> It's a few dozen lines of code (in addition to the actual API interface
>> code).  Sure seems like worth the experiment to me!
>>
>
> i'll go make some popcorn :).
>
> (To be fair: my [strong] aversion to that solution isn't intended to imply
> that you can't pull it off. My journey with libfossil was always _at least_
> as much about reimplementing it "cleanly" as it was about getting it
> running at all. Without the former, the latter would have been, at best, a
> hollow success.)
>
> --
> - 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] A fossil library

[David Mason]

I really don't understand the reticence to use setjmp/longjmp to turn all
of these short-cut exits into library return-to-API trampolines.  It would
allow you to retain all the existing fossil codebase.  Rewriting the code
into library form is an interesting project, but it seems like a huge
amount of work and unless Richard is going to change fossil to use the API,
it is also going to be a huge ongoing maintenance nightmare and fraught
with opportunities for failure.

All that is required is to declare a global setjmp buffer, and then each
API function would do a setjmp before calling into the existing code... and
you ignore that code if the longjmp is called. Then you simply need to
close any files that were opened and change working-directory if it might
have been changed, then return from the API. Then in any of the places that
exit is called, add a test to see if you were called by an API function and
if so do the longjmp instead.

It's a few dozen lines of code (in addition to the actual API interface
code).  Sure seems like worth the experiment to me!

../Dave

On 24 June 2018 at 16:34, Richard Hipp  wrote:

> On 6/16/18, Stephan Beal  wrote:
> >
> > 3) Fossil effectively uses exit() to handle just about any type of
> > non-allocation error. i.e. there's little library-friendly error handling
> > in fossil.
>
> Not just errors.  If Fossil finds an opportunity to send a "304 Not
> Modified" reply, it does so and then immediately calls exit(0),
> without having to unwind the stack.
>
> --
> 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] A fossil library

[David Mason]

Just had a quick thought that might make the conversion to library much
easier.

If you have a relatively small API interface, each of the API functions
could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h and then the fatal
error routines could longjmp back. This would give you API safety, at very
limited code intervention. And if a flag got set by the API functions, then
the fatal routines could check, so that fossil the program would need no
changes as only the API functions would change the default fail-hard
behaviour.

But perhaps the API would be too big to make this a win.

Just a thought.

../Dave

On 17 June 2018 at 07:50, Stephan Beal  wrote:

> On Sat, Jun 16, 2018 at 11:44 PM Sam Putman  wrote:
>
>> I'll be reading through the codebase and documentation, some initial
>> thoughts:
>>
>
> No pressure, but: i would _love_ to see someone pick up the torch and run
> with it.
>
> A bit of background: in Sept. 2011 i had the great pleasure of meeting
> Richard in Munich (at which point i'd been active on the mailing list since
> early 2008). He asked me what Fossil needed, to which i immediately
> responded "a library". We quickly came to the conclusion that the effort
> would be "herculean" (i believe was his (apt) description of it (or maybe
> that adjective got applied on the mailing list later on)), so i responded
> with my second choice: a JSON interface. (HTTP/JSON interfaces are, in
> essence, shared libraries with call-time linking. Many of Fossil's features
> simply aren't realistic for a JSON interface, but most are.) Richard
> promptly agreed, and i spent the next few months building the JSON API
> (using a then-recent JSON wiki project of mine as the "structural basis").
>
> Anyway...
>
>
>>
>>
>>> Several aspects of fossil make it very tedious (but not difficult, per
>>> se) to port to a library:
>>>
>>> 1) it uses a great deal of global state. That's simple enough to factor
>>> into a Context object, but...
>>>
>>>
>> An incremental refactoring of this into something more modular would
>> be a boon to maintenance and testing.  Seems like a sleeping dog we can
>> let lie for now.
>>
>
> That's actually the easy part. The real effort comes in with error
> checking and handling, especially in cases where an error may (in a
> library) propagated from 3+ levels deep. The app will just exit() at that
> point, so no thought has gone (nor needed to go) into error handling or
> propagation (because there is no propagation - all errors are "immediate").
> Not only does the propagation at the error-triggering point need to be
> decided upon, but how it will propagate arbitrarily far up the call stack.
> In the end, libfossil went with a hybrid approach of returning non-0 (from
> a well-defined enum of result codes) and the context object holds an Error
> object which may (or may not, depending on context) hold more details about
> the error.
>
>
>
>> 2) it relies on a fail-fast-and-fail-loud allocator. Any allocation error
>>> will immediately (intentionally) crash the app. While that saves literally
>>> half (sometimes more) of code/error checking any place where memory is
>>> allocated (that's a lot of places), that pattern is unusable for libraries.
>>> Granted, allocation errors are rare, but every single C call which
>>> allocates has to check for failure or risk Undefined Behaviour. To simplify
>>> the vast majority of the implementation, Fossil does this checking in a
>>> single place and abort()s the app if an allocation fails.
>>>
>>>
>>  Ok, this doesn't sound /ideal/ granted, but maybe not so bad either.
>>
>
> Because allocations fail so rarely (at least ostensibly), it's "not that
> big of a deal", but the library-level implementation code "needs" (in my
> somewhat-purist point of view) to check for allocation errors nonetheless.
> App-level code is free to use a fail-fast allocator, and libfossil's
> app-level code did, in fact, use one because it speeds up writing the
> app-level code so much. Fossil does _lots_ of allocation, and does, in
> fact, sometimes run out of memory. i've never seen it happen on my
> machines, but i've seen several reports from users who try to store
> multi-GB files in fossil and then wonder why it fails on their Raspberry
> Pi. Fossil needs scads of memory. Certain parts of that "could"
> hypothetically be optimized to only alloc what they need (e.g. the diff
> generator could arguably stream its output), but (1) that would greatly
> complicate those parts and (2) very possibly wouldn't result in a leaner
> app. e.g. constructing version X of a file from its parent version and the
> diff of the versions requires allocating memory for X, X's parent, and the
> diff (it knows all of those sizes in advance). In the average case that's
> just a bit over 2X memory for each such operation, and fossil regularly has
> to perform such an operation during many different types of activities.
>
>
>
>> I would likely prefer as much allocation as possible during 

Re: [fossil-users] Perception of Fossil

[David Mason]

Yup! Looks good. (I read the whole thread, but this seemed like best
message to which to reply. I think Jungle-Boogie's comment about being able
to accept directly from the UI for things like text updates would be
great... but it could be added later.)

Will need a bit of documentation to help people understand the workflow.

The user might have made some changes and committed to their local trunk
before they realize that they have a contribution to make, so a command to
move all changes in the local repo that are different from the remote repo
into a new branch would help with that: `fossil delta`? and then `fossil
contribute-delta` (which has contribute as a prefix and is therefore better
than push-delta because that has an existing (related) command as prefix)
would be a natural way to contribute it to the repo. (The delta might be
just for the branch they are on... e.g. there is a normal branch that one
of the committers is working on called foo, and the user might have made
changes to foo and trunk... so they should do 2 deltas - one for the foo
branch and one for the trunk.)

I think this would significantly address the "no pull-request" complaint
that seems to be the leading excuse - other than "it's not GIT".

../Dave

On 15 June 2018 at 13:35, Richard Hipp  wrote:

> On 6/15/18, David Mason  wrote:
> > I heartily agree with this... A flag to allow a person (including
> > Anonymous) to make a commit that would automatically go into a new branch
> > like "Patch-1" (each one incrementing the branch number) is (a) better
> than
> > emailed patches, and (b) better than pull requests. Primarily because it
> > puts it into Fossil so you can use all your standard workflows.
> >
> > The "Patch-?" branches should not be automatically synced, and if you do
> a
> > sync with some special flag, it should offer each of the existing patch
> > branches and allow you to agree to sync it, or not. Then there needs to
> be
> > a way to delete the patch branches (whether included into the trunk or
> not)
>
> An alternative design sketch:
>
> (1) Anonymous clones repo CoolApp
>
> (2) Anonymous makes changes to CoolApp and checks those changes into a
> branch named "anon-patch" on her private clone.  Repeat this step as
> necessary to get anon-patch working.
>
> (3) Anonymous runs the command "fossil pullrequest anon-patch"
>
> (4) The pullrequest command creates a "bundle" out of the "anon-patch"
> branch and then transmits that bundle back to the server from which
> the clone originated.
>
> (5) The server accepts the bundle and parks it in a separate holding
> table, but does not merge it or otherwise make it available to average
> passers by.  The server then sends email notifications to developers
> with appropriate privileges to let them know that a pull request has
> arrived.
>
> (6) Developers who receive notification of the pull request can run a
> command that pulls down the bundle and applies it as a private branch
> on their own personal clones of the repo.  Developers can then either
> approve of the pull request by publishing it (marking it non-private)
> and pushing it back to the server.  Or they can reject the pull
> request which erases it from their clone.  They might also cause the
> pull request to be erased from the holding table on the server.
>
> Additional notes:
>
> Prior to step (3), Fossil might require Anonymous to provide contact
> information so that developers can get in touch in case there are
> questions or requests for clarification.  Anonymous might also be
> asked to sign a contributors agreement to be included in the bundle
> (as an entry in the bconfig table).
>
> --
> 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] Perception of Fossil

[David Mason]

I heartily agree with this... A flag to allow a person (including
Anonymous) to make a commit that would automatically go into a new branch
like "Patch-1" (each one incrementing the branch number) is (a) better than
emailed patches, and (b) better than pull requests. Primarily because it
puts it into Fossil so you can use all your standard workflows.

The "Patch-?" branches should not be automatically synced, and if you do a
sync with some special flag, it should offer each of the existing patch
branches and allow you to agree to sync it, or not. Then there needs to be
a way to delete the patch branches (whether included into the trunk or not)

../Dave

On 15 June 2018 at 09:23, Olivier R.  wrote:

> Le 15/06/2018 à 01:32, Chad Perrin a écrit :
>
>> On Thu, Jun 14, 2018 at 09:59:12PM +0100, Thomas wrote:
>>
>>>
>>> Pull requests are not supported, hence the software can't be used for
>>> community driven open source.
>>>
>>
>> The pull request interface on GitHub is a feature of GitHub, not of Git.
>> While it would be nice to have a similar feature built into the Fossil
>> web UI, doing it the same way would require having a centralized website
>> on which to implement it.  Something similar could theoretically be
>> supported in Fossil itself, but would not be identical to the way
>> GitHub's pull request feature works.
>>
>
> I also feel that PR is missing in Fossil. Giving rights to unknown people
> to allow them to modify the repo is annoying.
>
> When someone clones the repo, make one or several commit(s), then push to
> the repo without having the right to change it, this commit could be queued
> somewhere (in a temporary branch maybe?), then the administrator(s) may
> apply it as it is or with modifications, or refuse it. To avoid spams and
> useless commits, it should be allowed to delete unwanted changes waiting in
> the queue.
>
> Olivier
> ___
> 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] Why SQLite Does Not Use Git

[David Mason]

This is very funny looks a lot like the real thing:

   https://git-man-page-generator.lokaltog.net/

but it's auto-generated on the fly!

../Dave

On 14 April 2018 at 07:49, Richard Hipp  wrote:

> On 4/14/18, Svyatoslav Mishyn  wrote:
> > (Sat, 14 Apr 06:22) Richard Hipp:
> >> Article:  https://sqlite.org/whynotgit.html
> >>
> >> HN discussion: https://news.ycombinator.com/item?id=16806114
> >>
> >> Reddit discussion:
> >> https://www.reddit.com/r/programming/comments/8c2niw/
> why_sqlite_does_not_use_git/
> >
> > and Lobsters discussion:
> > https://lobste.rs/s/slcntl/why_sqlite_does_not_use_git
>
> I added that link to the article.  Thanks!
>
> --
> 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] Replacing subversion revision number... by what?

[David Mason]

Days since start of the release branch would seem like a good proxy -
assuming you create release branches (which seems like a good idea):
1) increasing
2) small number - you could use hours instead of days if you release
multiple versions per day
3) pretty directly mappable to a commit.
4) same on any machine
​
../Dave
___
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] Tag problems

[David Mason]

Why not support --dryrun and --dry-run but only document the former? Then
scripts won't break.  It's not like anyone is going to accidentally use
--dry-run to mean something else.​

../Dave
___
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] Tag problems

[David Mason]

On 16 December 2017 at 20:33, Andy Bradford <amb-fos...@bradfords.org>
wrote:

> Thus said David Mason on Sat, 16 Dec 2017 15:36:51 -0500:
>
> > I tried to add a tag to  my fossil. After looking at the documentation
> > which said:
>
> The ``fossil  tag'' command  is for very  low-level tag  operations. You
> probably don't want to use it until you understand what it's doing.
>
> If you do actually want to add tags to commits from the command-line you
> might want to look at ``fossil amend'' instead---it more closely mirrors
> what is available in the UI:
>

Fair enough. It would be helpful if the documentation said that.

The other options don't seem to work as advertised, either. Perhaps they
only work if the magic values are supplied, but again, it would be helpful
if the documentation said that.

../Dave
___
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] Tag problems

[David Mason]

I didn't want the other junk in there, so I re-cloned it. Then used the GUI
to tag the checkout.

A thought: if the default timeline didn't show edits (like colour or tags)
it would be cleaner (and less clamour for rebasing, perhaps).  Obviously
you'd want an option to see all the gory details.

On 16 December 2017 at 16:52, Richard Hipp <d...@sqlite.org> wrote:

> On 12/16/17, David Mason <dma...@ryerson.ca> wrote:
> > Can I back those out any way short of re-cloning the remote fossil?
>
> You can "cancel" the old tags so that they don't have any effect.  You
> should see "Cancel" buttons for each tag on the web-based edit page.
> --
> 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] Tag problems

[David Mason]

Can I back those out any way short of re-cloning the remote fossil?

On 16 December 2017 at 16:10, Richard Hipp <d...@sqlite.org> wrote:

> On 12/16/17, David Mason <dma...@ryerson.ca> wrote:
> > I tried to add a tag to my fossil.
>
> I didn't write the "fossil tag" command - that is contributed code.
> Whenever I want to tag a check-in, I use the web interface.  I know
> the web interface works, because I use it all the time.  Have you
> tried creating the tag that way?
> --
> 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] Tag problems

[David Mason]

I tried to add a tag to my fossil. After looking at the documentation which
said:

I did the following:
: ~/fs/Optijava ; fs tag add -n --user-override shruthi pre-dissertation
e5b61ea041
not found: pre-dissertation
: ~/fs/Optijava ; fs help tag|less
: ~/fs/Optijava ; fs tag add -n --user-override shruthi e5b61ea041
pre-dissertation
: ~/fs/Optijava ; fs time
=== 2017-12-16 ===
15:11:16 [5b755ab016] Edit [e5b61ea04194cb41|e5b61ea041]: Add tag "shruthi"
with note "pre-dissertation". (user: dmason)
=== 2017-12-12 ===
00:11:57 [e5b61ea041] *CURRENT* Adding spills before copy instructions
during calls (user: shruthi tags: trunk, shruthi).

A few problems:
1) -n did not prevent it from running.
2) --user-override didn't - and didn't consume a parameter and didn't give
any warning! I'm guessing I should have used --user-override=shruthi but
nothing indicates that and I don't want to put more crap in my timeline.
3) Initially I thought my tag vs. checkin order was wrong (i.e. that the
documentation was wrong on that) and then it did something, but not the
right thing.
4) There is no mention of a "note" in the documentation. It does say
'?VALUE?' at the end of 'fs help tag' but no indication what it is... and
the word 'value' is used several times, but not referring to it.
5) I presume these are on the local fossil - can I *REMOVE* them (I tried
cancel, but that just adds another record to the timeline!) I haven't done
anything else since to that fossil.

This is fossil version 2.3 [f7914bfdfa] 2017-07-21 03:19:30 UTC

Thanks ../Dave
___
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

[David Mason]

I would like yesterdays with a bit of whitespace between commit comments.

Also someone liked the original because the checkin tag was in a
predictable place.  If you put the tag last in the extra information it
would be predictably at the right margin.

On 27 November 2017 at 21:01, Richard Hipp  wrote:

> On 11/27/17, Steve Landers  wrote:
> > Nice work.
> >
> > Have you considered dropping the borders on the commits?  They do add
> > definition to the commit, but at the expense of repetition and possibly
> > “noise” when the branch isn’t colored
>
> Here are comparison links:
>
> As it was yesterday:
>https://www.fossil-scm.org/fossil/timeline
>https://www.fossil-scm.org/fossil/timeline?dp=d95f712=4
>https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
>https://www.fossil-scm.org/fossil/finfo?name=src/db.c
>
> Warren Young's new approach:
>https://www2.fossil-scm.org/fossil/timeline
>https://www2.fossil-scm.org/fossil/timeline?dp=d95f712=4
>https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
>https://www2.fossil-scm.org/fossil/finfo?name=src/db.c
>
> Steve Landers' modifications to Warren's approach:
>https://www3.fossil-scm.org/site.cgi/timeline
>https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712=4
>https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
>https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c
>
> Please do not restrict yourself to just the links shown.  Look at
> various timelines to see what works well and what does not.
>
> --
> 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] Repository size - Fossil v. Git

[David Mason]

Does it stay that size with moderate activity, or does it start growing
significantly? Does the pack format slow it down, or speed it up?

Given that the Git version only has 93% of what the Fossil repo has, I'd
say Fossil is doing quite well.

../Dave

On 27 November 2017 at 16:16, Joerg Sonnenberger  wrote:

> On Mon, Nov 27, 2017 at 03:28:37PM -0500, Richard Hipp wrote:
> > I didn't try any repacking.  I merely ran "git clone" then looked at
> > the packfile in .git/objects/pack.  You would think that the server
> > would want to do an aggressive repack before sending the packfile
> > across a clone, to save bandwidth.  But maybe GitHub values CPU cycles
> > more than bandwidth...
>
> git import is writing pretty dumb packs. Lots of redundancy in it,
> so it's not really that surprising. It's kind of similar to the effect
> of avoiding "fossil rebuild --compress" or Mercurial's generic delta.
> Cloning IIRC will mostly use the deltas as recorded, it doesn't
> recompute them. GitHub in generally naturally avoids CPU load as much as
> possible, since it is one of the more expensive parts of running in the
> cloud.
>
> > Your git-foo is much greater than mine, Joerg.  Can you please clone
> > https://github.com/mackyle/sqlite.git and see if you can get the
> > packfile to come out smaller?
>
> git repack -A -d --depth=500 --window-memory 4g -f -F
> gives me around 43MB for .git.
>
> 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] [PATCH] Improve symlink following offile_wd_isdir()

[David Mason]

I use symlinks *very* heavily. Almost exactly 10% of the files in my main
fossil hierarchy are actually symlinks. Fossil not supporting them would be
a huge drawback for me. Good support for symlinks and nested repositories
are 2 of the details I like best about Fossil (in addition to the obvious
features).

../Dave

On 27 November 2017 at 18:20,  wrote:

> On Mon, 27 Nov 2017 09:52:19 -0500
> Richard Hipp  wrote:
>
> > I am in receipt of your patch.  I have not evaluated it yet because
> > the entire symbolic-link mechanism in Fossil is confused and very
> > difficult to manage.  It mostly works now, but is brittle.  A
> > seemingly simple patch like what you sent could cause breakage.
>
> Perhaps a separate function "make_path()" just to create any
> directories that may not exist, rather than stuffing it all in
> blob_write_to_file(). It can be called as follows if needed:
>
>   make_path(zFile);
>   blob_write_to_file(, zFile);
>
> >
> > I am very sorry that I allowed symbolic link support into Fossil in
> > the first place.   (Symbolic link support was neither designed nor
> > written by me - it is contributed code.)  I would really like to get
> > rid of symbolic link support.  Symbolic links seem out-of-place in a
> > version control system.  As implemented, symbolic links are a point of
> > confusion which (as far as I can see) adds no useful capabilities.
>
> Are you referring to symlinks inside a working directory, or Fossil's
> ability to "follow" them? If so have a survey of users, or a
> disabled-by-default policy to see if any users need 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] fossil-users Digest, Vol 118, Issue 46

[David Mason]

On 26 November 2017 at 16:52, Ron W  wrote:

> I think there needs to be some indication that there is more information.
> From my experience, an ellipses is a very common tool for this purpose - as
> long as they are visible.
>

I agree. I really think tooltips (titles) should be used as well as the
ellipsis.

../Dave
___
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

[David Mason]

What you have seems to handle the ellipsis properly (by my definition of
properly).

But you really should use title/tooltip.

On 25 November 2017 at 21:45, Richard Hipp  wrote:

> On 11/25/17, Richard Hipp  wrote:
> > On 11/25/17, sky5w...@gmail.com  wrote:
> >> Ok, the current behavior is cool, but renders the ellipses superfluous.
> >> Clicking anywhere in a line expands/contracts the info.
> >> Any chance to drop the many many ⋯'s after all my comments?
> >>
> >
> > I think the following CSS will do that for you:
> >
> > .timelineEllipsis { display: 'none'; }
>
> No, that won't work, because the toggleEllipsis() JS function will get
> confused.
>
> How about making your ellipsis very small:
>
>.timelineEllipsis { font-size: 50%; }
>
> --
> 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] More timeline changes

[David Mason]

  function cancelProp(event){
 if (event.stopPropagation) {event.stopPropagation()} //w3c
else {event.cancelBubble = true } // ie
  }


  http://google.ca; onclick="cancelProp(event)" title=" ">
google
  
  blah blah


Suppressing the title on the link is tricky the above works on
Chrome/Firefox but shows a space on IE/Safari - see:
https://stackoverflow.com/questions/5881954/html-stop-child-elements-from-inheriting-parents-title-attribute
but you might have a useful title to give it.

../Dave

On 25 November 2017 at 20:47, Richard Hipp <d...@sqlite.org> wrote:

> On 11/25/17, David Mason <dma...@ryerson.ca> wrote:
> >
> > When I did that, I made clicking on anywhere in that div expand it.
> >
>
> I've done that in the latest.  Actually, I made it click-to-toggle.
> That seems to work a lot better than trying to click on the ellipsis.
>
> But there is a subtle problem.  For timeline comments that contain a
> hyperlink (ex: https://www.sqlite.org/srcx/timeline?c=b016c28f) if I
> click on the hyperlink, it first toggles the detail on/off before it
> takes the hyperlink.  Do you have suggestions on how I can disable the
> "onclick" on the outer  when one clicks inside an inner ?
> --
> 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] More timeline changes

[David Mason]

Looks good.

When I did that, I made clicking on anywhere in that div expand it.

You should also add a title that says "Click to expand" so that they don't
have to know/infer that the ellipsis is an active link.

I also like being able to shrink it back... right now there isn't that much
extra detail, but you may add more.

I don't want to sound critical or look a gift-horse in the mouth, but I
looked at your page source and it's way more complicated than it needs to
be.  If you look at my message in the other thread, all the code is there
to make it work with a lot less generated HTML and be a lot cleaner.

../Dave

On 25 November 2017 at 16:40, Richard Hipp  wrote:

> The names of the of the buttons are now "Advanced" and "Basic".  And
> they work by setting .style.display using JS.
>
> Timelines now come up in Basic mode, which means only the check-in
> comment shows.  There are ellipses at the end of each comment.  If you
> click on the ellipsis for one comment, it expands the (detail) section
> for that one timeline entry.
>
> Try it out:
>
>  https://www.fossil-scm.org/fossil/timeline
>  https://sqlite.org/srcx/timeline
>
> Problems:  (please suggest solutions)
>
> The ellipses at the ends of comments in basic mode are barely visible.
> And they are not configurable using CSS (at least not by any CSS that
> I know).
>
> That's the only serious problem that springs immediately to mind, but
> perhaps you can find others for me.
> --
> 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] Interface improvement ideas from GitHub

[David Mason]

To extract the relevant bits:
HTML:
 
JS:
  function toggleExpand(node,shrink,expand) {
if (node.classList.contains(shrink)) {
node.classList.remove(shrink);
expand && node.classList.add(expand);
node.setAttribute('title','Click to '+shrink);
} else {
expand && node.classList.remove(expand);
node.classList.add(shrink);
node.setAttribute('title','Click to '+(expand || 'expand'));
}
}
CSS:
.shrink > :nth-child(n+1) {
display: none;
}
.shrink {
white-space: nowrap;
overflow:hidden;
text-overflow:ellipsis;
}

The optional expand parameter to toggleExpand is if you want to add a
different class when it's expanded. I use it elsewhere, but not here.

../Dave

On 25 November 2017 at 09:38, David Mason <dma...@ryerson.ca> wrote:

> 1) Add/remove a class to an enclosing DIV. You can see a very simple
> version that I wrote in action on https://programmingfortherestofus.com
> click on the bullets under Elevator Pitch.
>
> 2) Include all the content, just don't display it by default...
> dynamically downloading additional content is almost certainly not worth it.
>
> ../Dave
>
> On 25 November 2017 at 08:53, Richard Hipp <d...@sqlite.org> wrote:
>
>> I notice on diff pages of GitHub (ex:
>> https://github.com/mackyle/sqlite/commit/028307ebcc953ee944d
>> 389fe359d146ab4893d16)
>> that above and below each diff chunk there is a light-blue block on
>> the left with an icon in the middle.  If you hover over this area, you
>> get a pop-up hint that says "Expand".  If you click, it adds more
>> context to the diff.
>>
>> Questions:
>>
>> (1) What's the best way to add mouse-over pop-up hints, in raw CSS+JS,
>> without using a "framework"?
>>
>> (2) How do they implement this "expand the diff context" feature?
>> Surely this is something that needs to be added to Fossil, don't you
>> think?
>>
>> --
>> 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] Interface improvement ideas from GitHub

[David Mason]

1) Add/remove a class to an enclosing DIV. You can see a very simple
version that I wrote in action on https://programmingfortherestofus.com
click on the bullets under Elevator Pitch.

2) Include all the content, just don't display it by default... dynamically
downloading additional content is almost certainly not worth it.

../Dave

On 25 November 2017 at 08:53, Richard Hipp  wrote:

> I notice on diff pages of GitHub (ex:
> https://github.com/mackyle/sqlite/commit/028307ebcc953ee944d389fe359d14
> 6ab4893d16)
> that above and below each diff chunk there is a light-blue block on
> the left with an icon in the middle.  If you hover over this area, you
> get a pop-up hint that says "Expand".  If you click, it adds more
> context to the diff.
>
> Questions:
>
> (1) What's the best way to add mouse-over pop-up hints, in raw CSS+JS,
> without using a "framework"?
>
> (2) How do they implement this "expand the diff context" feature?
> Surely this is something that needs to be added to Fossil, don't you
> think?
>
> --
> 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] A-B comparison of proposed timeline changes

[David Mason]

I like the B cases... in fact I'd indent the details a bit so that the
comments are easier to find visually.

On 24 November 2017 at 11:53,  wrote:

> I understand the need for links, but do users really need truncated hashes
> for every line?
> Can the link be applied more subtly?
> Can there be a similar "quiet" setting for the Timeline like *Per-Item
> Time Format = (off) *to conserve space?
> My commits prepend a simple timestamp in the comment and multiline text
> for more immediate descriptions right up front.
> Having this tail every entry -> (check-in: [4dfa592f]
>  user: drh
> 
>  tags: trunk
> )
> <-
> makes the timeline quite busy.
>
> Thanks for Fossil!
>
> On Fri, Nov 24, 2017 at 11:27 AM, Richard Hipp  wrote:
>
>> On 11/24/17, bch  wrote:
>> >>
>> >>   (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.
>>
>> Those are CSS changes.  So you will need to press "Reload" in your
>> browser, possibly multiple times if you use Chrome, before you will be
>> able to see the changes.
>>
>> --
>> 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] Fossil-NG Bloat?

[David Mason]

Also as a mere fossil user, I would find it useful if fossil could respond
to a git client and serve files. I use Pharo, which is working toward
integrated support for git, but I'd much rather trust my bits to Fossil.
While the Fossil UI is nice, I see much less value in using a local Fossil
to access a remote git/hg repo.

There are two things that are much more relevant for me:

1) Improvements to ignoring files. One solution is per-directory .fslignore
file (like git and hg have) so I can get better granularity on ignoring
files. In particular I would like to generally ignore .class files as being
Java binaries, but another tool I use generates .class as an extension for
directories that contain class methods (as opposed to instance methods). An
alternative that works for this problem would be a way to specify in a glob
file that a match was for directories vs. files, or to have include globs
so I could ignore *.class but accept *.class/*

2) Allow me to designate any file in the directory structure as
unversioned.  The current unversioning model does not work well for me.  It
essentially is equivalent to Dropbox. I am working with PharoJS which
produces Javascript files from Smalltalk code. I want my source code and
the generated code in Fossil. I also have movies and image files that I
want in particular places.  I realize the Fossil model is to be able to
revert to exactly the state of things on such-and-such a date, including
the versions of movies and images as they were, but I - at least - very
rarely care that images and movies are exactly as they were, I'd almost
always be perfectly happy using the current version. An ideal alternative
would be to have versioned files but where it only kept snapshots of
versions I explicitly asked for, otherwise it would just update the current
version.

Thanks for fossil!

../Dave
___
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 with Apache Proxy

[David Mason]

I've found a few minor things that make fossil less flexible than it could
be.

1) SQLITE_DEFAULT_FILE_PERMISSIONS is set to 0644 where I would argue that
it should be 0666, because it is masked by umask anyway. It was surprising
to me when I set umask to 7 and then created a fossil that ended up with
640 permissions. Of course, one can simply chmod g+w, but it's a surprise.

2) enter_chroot_jail should only be called if running as root, because the
semantics of setgid/setuid are tricky when running as a (non-root)
setuid/setgid program (see http://unixpapa.com/incnote/setuid.html if you
doubt me!). In my case I end up unable to read the repo, so cannot
initialize it properly. This is also solvable, although not so easily.

Sorry, I wrote this a while ago, and I've worked around the issues, but it
would be nice if they were resolved.

../Dave


On 28 September 2017 at 16:04, Richard Hipp <d...@sqlite.org> wrote:

> On 9/28/17, David Mason <dma...@ryerson.ca> wrote:
> >
> > Last question for a while: in clone.c line 104 it says to use %40, %2f
> and
> > %3a for special characters in the userid and password (for obvious
> > reasons). Are there any other restrictions on the repo name or other
> parts
> > of the URL?
>
> Note that I recall.  But there might be some that I've forgotten about.
>
> As a security precaution in your system, I think you would do well to
> restrict repo names to begin with an alphanumeric, end with ".fossil",
> and contain no characters other than alphanumerics, '.', '_', and '-'.
> Maybe also only allow a single '.', specifically the one that occurs
> on the ".fossil" suffix.
> --
> 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] Using Fossil with Apache Proxy

[David Mason]

I seem to be thick as a brick today, but I found the --nocgi but can't seem
to use it...
a bit later after looking at the sources... Ahhh... it's only parsed if
GATEWAY_INTERFACE is in the environment!

I would argue that line 601 should use & instead of && - principle of least
surprise.

It appears that `unset GATEWAY_INTERFACE` is a more robust way to deal with
it in the meantime (and you have to unset it... not just set it to '').

Last question for a while: in clone.c line 104 it says to use %40, %2f and
%3a for special characters in the userid and password (for obvious
reasons). Are there any other restrictions on the repo name or other parts
of the URL?

Thanks  ../Dave



On 28 September 2017 at 09:53, Roy Keene <fos...@rkeene.org> wrote:

> On Thu, 28 Sep 2017, Mark Janssen wrote:
>
>
>>
>> On 28 Sep 2017 13:37, "David Mason" <dma...@ryerson.ca> wrote:
>>
>>
>>> I have all the logic I need I just want fossil to behave like it
>>> would at a terminal prompt, rather than acting like a CGI... the
>>> complication is that I am calling it from a CGI!  But removing all the
>>> environment
>>> variable mostly solves the problem.
>>>
>>>
>> To get the commandline behavior of fossil in a CGI context use the
>> --nocgi flag.
>>
>>
>>
>>
> For what it's worth, this is how Flint (which powers ChiselApp.com) does
> it:
>
> http://chiselapp.com/user/rkeene/repository/flint/artifact?
> ln=33-37=1eb0582d234199bc
>
> ___
> 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 with Apache Proxy

[David Mason]

No, just setuid something other than www - an ordinary user.

I'm currently doing a workaround to not run fossil from within a CGI, but
it's not optimal (exposes some information I'd rather not expose).

Thanks

On 28 September 2017 at 09:26, Richard Hipp <d...@sqlite.org> wrote:

> On 9/28/17, David Mason <dma...@ryerson.ca> wrote:
> >
> > The CGI is also setuid,...
>
> Setuid root?  If so, remember that when Fossil sees that it running as
> root, it puts itself inside a chroot jail and drops all privileges (it
> reverts to the owner of the repository) prior to doing much of
> anything else.  Might the chroot() and/or setuid() be causing you some
> kind of grief?
>
> --
> 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] Using Fossil with Apache Proxy

[David Mason]

I thought I had it... but no...
I tried:

env - PATH=$PATH FOSSIL_HOME=. fossil new -A  foo.fossil
on a terminal and it worked perfectly... I use the same values in the CGI,
and it gives the read permission problem. It does create the foo.fossil
file, but it's junk.

Sigh  ../Dave

On 28 September 2017 at 07:37, David Mason <dma...@ryerson.ca> wrote:

> I wasn't clear! (I've been working all night on this so it's
> understandable.)
>
> I have all the logic I need I just want fossil to behave like it would
> at a terminal prompt, rather than acting like a CGI... the complication is
> that I am calling it from a CGI!  But removing all the environment variable
> mostly solves the problem.
>
> The CGI is also setuid, and I'm wondering if that could explain some of
> the permission problems I'm seeing... in particular fossil says:
>
> Fossil internal error: repository does not exist or is in an unreadable
> directory
> when it really isn't. So I changed the permissions on the directory to 777
> and now I get:
>
> Fossil internal error: read permission denied for repository
> Fossils/A.fossil
> which is equally mystifying!
> And there are no users defined.
>
> Obviously there is some heavy voodoo happening that I'm not tracking.  For
> the record this is Linux.
>
> Thanks  ../Dave
>
> On 28 September 2017 at 06:37, Richard Hipp <d...@sqlite.org> wrote:
>
>> On 9/28/17, David Mason <dma...@ryerson.ca> wrote:
>> >
>> > I need to create fossils on the fly [using CGI]
>>
>> Fossil does not (currently) have that capability.
>>
>> What you are really asking for is a "meta-fossil" that is a
>> server-side program that manages multiple fossil repositories.
>>
>> The closest thing we have to that right now is that in your CGI
>> script, you can use the "directory:" keyword in place of "repository:"
>> to specify a directory that contains multiple "*.fossil" files, and
>> then Fossil will give you a list of the files to choose from.  But
>> with that mechanism, there is no opportunity to customize the look &
>> feel of the screen, nor authenticate the user, nor do any of the other
>> kinds of things that a true meta-fossil would need to do.
>>
>> Perhaps a full-up "meta-fossil" capability should be a feature request.
>>
>> See also:  http://chiselapp.com/
>> --
>> 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] Using Fossil with Apache Proxy

[David Mason]

I wasn't clear! (I've been working all night on this so it's
understandable.)

I have all the logic I need I just want fossil to behave like it would
at a terminal prompt, rather than acting like a CGI... the complication is
that I am calling it from a CGI!  But removing all the environment variable
mostly solves the problem.

The CGI is also setuid, and I'm wondering if that could explain some of the
permission problems I'm seeing... in particular fossil says:

Fossil internal error: repository does not exist or is in an unreadable
directory
when it really isn't. So I changed the permissions on the directory to 777
and now I get:

Fossil internal error: read permission denied for repository
Fossils/A.fossil
which is equally mystifying!
And there are no users defined.

Obviously there is some heavy voodoo happening that I'm not tracking.  For
the record this is Linux.

Thanks  ../Dave

On 28 September 2017 at 06:37, Richard Hipp <d...@sqlite.org> wrote:

> On 9/28/17, David Mason <dma...@ryerson.ca> wrote:
> >
> > I need to create fossils on the fly [using CGI]
>
> Fossil does not (currently) have that capability.
>
> What you are really asking for is a "meta-fossil" that is a
> server-side program that manages multiple fossil repositories.
>
> The closest thing we have to that right now is that in your CGI
> script, you can use the "directory:" keyword in place of "repository:"
> to specify a directory that contains multiple "*.fossil" files, and
> then Fossil will give you a list of the files to choose from.  But
> with that mechanism, there is no opportunity to customize the look &
> feel of the screen, nor authenticate the user, nor do any of the other
> kinds of things that a true meta-fossil would need to do.
>
> Perhaps a full-up "meta-fossil" capability should be a feature request.
>
> See also:  http://chiselapp.com/
> --
> 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] Using Fossil with Apache Proxy

[David Mason]

Another challenge!

I'm running fossil from within a CGI of my own... I want to do things like
`fossil new foo.fossil`

But fossil decides it is running as a CGI itself and doesn't do what I
ask.  Running it as `exec - /usr/local/bin/fossil new foo.fossil` kind of
works, but some things are still strange. I reset GATEWAY_INTERFACE and
PATH_INFO to '' but that didn't solve it.

The actual fossil name I'm using looks like: A+foo_bar.com+oth_re.ex.fossil
- would that be causing me strange problems? Also this CGI that's calling
fossil is running setuid... does fossil use the system to determine
permissions or does it use stat etc. to look at the files directly. I.e. do
I need to call seteuid?

I thought this was going to be easy to use it (in this very idiosyncratic
way), but it's been a pile of hassles.

The reason for this weirdness is that I need to create fossils on the fly
and change permissions/passwords, etc.

Thanks

On 26 September 2017 at 12:01, David Mason <dma...@ryerson.ca> wrote:

> This is proxy, not CGI, but the same appears to apply:
>
> fossil clone http://dmason%40ryerson.ca@localhost:8081/f2017/A-dmason_
> ryerson.ca x.fossil
>
> (talking directly to the server) also doesn't seem to want the .fossil
> extension, whereas ssh: and file: do.
>
> This seems inconsistent to me, though obviously you won't be changing it!!!
>
> Thanks again (both for the immediate help, and for fossil itself)!
>
> ../Dave
>
> On 26 September 2017 at 10:05, Richard Hipp <d...@sqlite.org> wrote:
>
>> On 9/26/17, David Mason <dma...@ryerson.ca> wrote:
>> > Indeed! Thanks... I already noted that in the web access, but the file
>> does
>> > end in .fossil and I've always used that before when cloning (using the
>> > ssh: access method). Is there a difference in how fossil names are
>> > recognized in ssh: vs http(s): ?
>>
>> When using http(s), you need to tell the web server the name of the
>> CGI script, not the name of the repository.  Apache doesn't know
>> anything about Fossil and has no idea how to deal with it.  But Apache
>> does know how to run CGI.
>>
>> When using the ssh: access method, the client uses the "ssh" command
>> to run "fossil server $repo" on the remote side, where $repo is the
>> name of the repository as specified in the URL.  In this case, the
>> command being run is "fossil" and it does know how to deal directly
>> with a repository.  Hence, ssh: is a little different from https: in
>> that ssh: wants the name of the repository whereas https: wants the
>> name of the CGI script.
>>
>> Note that it is usually undesirable to download the repository file
>> directly, as the repository contains additional information such as
>> usernames and password hashes and log files that should normally be
>> kept private.  If you ever do need to share a Fossil repository with
>> an untrusted third party, first make a copy of the repo, then run the
>> "fossil scrub" command on the copy in order to remove all sensitive
>> information.  Share the copy, not the original.
>>
>> --
>> 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] Using Fossil with Apache Proxy

[David Mason]

This is proxy, not CGI, but the same appears to apply:

fossil clone http://dmason%40ryerson.ca@localhost:8081/f2017/A-dmason_ryerson.ca
x.fossil

(talking directly to the server) also doesn't seem to want the .fossil
extension, whereas ssh: and file: do.

This seems inconsistent to me, though obviously you won't be changing it!!!

Thanks again (both for the immediate help, and for fossil itself)!

../Dave

On 26 September 2017 at 10:05, Richard Hipp <d...@sqlite.org> wrote:

> On 9/26/17, David Mason <dma...@ryerson.ca> wrote:
> > Indeed! Thanks... I already noted that in the web access, but the file
> does
> > end in .fossil and I've always used that before when cloning (using the
> > ssh: access method). Is there a difference in how fossil names are
> > recognized in ssh: vs http(s): ?
>
> When using http(s), you need to tell the web server the name of the
> CGI script, not the name of the repository.  Apache doesn't know
> anything about Fossil and has no idea how to deal with it.  But Apache
> does know how to run CGI.
>
> When using the ssh: access method, the client uses the "ssh" command
> to run "fossil server $repo" on the remote side, where $repo is the
> name of the repository as specified in the URL.  In this case, the
> command being run is "fossil" and it does know how to deal directly
> with a repository.  Hence, ssh: is a little different from https: in
> that ssh: wants the name of the repository whereas https: wants the
> name of the CGI script.
>
> Note that it is usually undesirable to download the repository file
> directly, as the repository contains additional information such as
> usernames and password hashes and log files that should normally be
> kept private.  If you ever do need to share a Fossil repository with
> an untrusted third party, first make a copy of the repo, then run the
> "fossil scrub" command on the copy in order to remove all sensitive
> information.  Share the copy, not the original.
>
> --
> 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] Using Fossil with Apache Proxy

[David Mason]

On 26 September 2017 at 06:30, Richard Hipp <d...@sqlite.org> wrote:

> On 9/26/17, David Mason <dma...@ryerson.ca> wrote:
> >  if I try:
> >fossil clone
> > https://dmason%40ryerson...@cps506.scs.ryerson.ca/fossil/
> f2017/A-dmason_ryerson.ca.fossil
> >  foo.fossil
> >  it prompts for password, but then says it can't find it.
>
> Fossil prompts for a password whenever it sees a URL of the form
> "http[s]://USER@DOMAIN//...".  It does this before it ever attempts to
> connect the server.  So, for example, is should still prompt for the
> password if you type:
>
> fossil clone https://dma...@does.net.exists/bogus/repo/xyzzy
> xyzzy.fossil
>
> I think your failure is occurring because you added a ".fossil" to the
> end of the URL.


Indeed! Thanks... I already noted that in the web access, but the file does
end in .fossil and I've always used that before when cloning (using the
ssh: access method). Is there a difference in how fossil names are
recognized in ssh: vs http(s): ? Or is it because there is already a '.' in
the repo name (the full file name is A-dmason_ryerson.ca.fossil
<http://40ryerson...@cps506.scs.ryerson.ca/fossil/f2017/A-dmason_ryerson.ca.fossil>
)

Thanks for your quick response. I spent several hours trying to figure this
out, because I couldn't make sense of why this didn't work like my previous
experience with ssh: access.

../Dave
___
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 with Apache Proxy

[David Mason]

On 25 September 2017 at 13:59, Richard Hipp <d...@sqlite.org> wrote:

> On 9/25/17, David Mason <dma...@ryerson.ca> wrote:
> > I am trying things differently this year. I want to use one instance of
> > fossil running proxied behind a firewall.  I have the following in my
> > Apache conf file:
> > 
> >
> >   ProxyPass http://127.0.0.1:8081
> >
> >   ProxyPassReverse http://127.0.0.1:8081
> >
> >   SetOutputFilter proxy-html
> >
> >   ProxyHTMLURLMap http://127.0.0.1:8081 /fossil
> >
> > 
> >
> > RewriteRule ^/fossil$ /fossil/ [R]
> > and the forward proxy works, except the resulting page doesn't have the
> CSS
> > and all the links are 127.0.0.1:8081 links instead of the right ones.
> >
>
> How are you starting up the fossil server?  Are you using the
> --baseurl option so that Fossil knows how to construct URLs that point
> to itself?


That solved it, thanks. I'm guessing I don't need the ProxyPassReverse and
ProxyHTMLURLMap now.

I can access the fossil web interface now at:
https://cps506.scs.ryerson.ca/fossil/f2017/A-dmason_ryerson.ca using
dma...@ryerson.ca for login, however if I try:
   fossil clone
https://dmason%40ryerson...@cps506.scs.ryerson.ca/fossil/f2017/A-dmason_ryerson.ca.fossil
<https://cps506.scs.ryerson.ca/fossil/f2017/A-dmason_ryerson.ca> foo.fossil
 it prompts for password, but then says it can't find it. Unfortunately the
file system doesn't record access times, so I can't tell on the remote
machine if the fossil file was read. Any ideas what I'm doing wrong?

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

[fossil-users] Using Fossil with Apache Proxy

[David Mason]

I am trying things differently this year. I want to use one instance of
fossil running proxied behind a firewall.  I have the following in my
Apache conf file:


  ProxyPass http://127.0.0.1:8081

  ProxyPassReverse http://127.0.0.1:8081

  SetOutputFilter proxy-html

  ProxyHTMLURLMap http://127.0.0.1:8081 /fossil



RewriteRule ^/fossil$ /fossil/ [R]
and the forward proxy works, except the resulting page doesn't have the CSS
and all the links are 127.0.0.1:8081 links instead of the right ones.

Further, when I try to clone these via:

fossil clone
https://dma...@cps506.scs.ryerson.ca/fossil/f2017/A-dmason_ryerson.ca.fossil
cps506.fossil
it always fails (after asking for password, which I just set).

I'm certainly doing something silly wrong.  All help appreciated!

Thanks  ../Dave
___
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] Empty file constantly being deleted

[David Mason]

On 8 September 2017 at 10:47, Thomas  wrote:

> If I do this I can never use addremove again. The checkin script runs
> addremove automatically each time.
>

If it's in the ignore-glob file, addremove won't add it.  So put in the
ignore-glob, remove it once, clean up the shun, commit, and then what you
are doing in your script will work just fine.
___
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] toc.tcl

[David Mason]

On 29 August 2017 at 23:55, Andy Goth  wrote:

> I'm curious how the Markdown formatter would know what language rules to
> use for syntax highlighting, so surely there's more to the syntax than
> bracketing ("fencing") the code with lines consisting entirely of "```".
> I searched online and found the answer to be: put the name of the syntax
> highlight mode (i.e. the language) right after the first "```" on the
> same line, for instance "```ruby".
>

Discord and github handle a keyword after the "```" on the first line. So:
```smalltalk
foo: anObject
^ anObject + 5
```
would format the 2 lines in Smalltalk.

../Dave
___
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 file replacement is broken?

[David Mason]

I've seen it too, but it's sporadic.  My crontab pull script now checks if
the size is 0 and ignores the file if so.

../Dave
___
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-dev] Backout the --no-dir-symlinks option. Was strange problem with graphical diff

[David Mason]

It is unclear from the documentation what this switch actually does, and I
unfortunately do not have time at the moment to read the code.

I use Linux and MacOSX and use symlinks to directories very heavily, so am
a little worried about what this change does.  I never explicitly use this
switch.

I want a symlink to behave in fossil like it does in the Unix find command
- i.e. stop at a symlink without a --follow switch, and like it does in the
Unix tar command (which should be the model - if I `fossil add foo` it
should reference the same things as `tar cf - foo`). So addremove, for
example should not add things in the linked-so directory.  One of the
things I often have is a symlink to ../TeX which points to a separate
working directory for (La)TeX support files. Once (a year or 2 ago) I was
setting up a new repo in fossil and did an addremove and it added all the
files in that directory and it was a bit of a pain to clean up. Since then
I never use addremove because I don't trust it not to make work for me.

Thanks again for this fabulous tool!

../Dave

On 24 August 2017 at 05:50, Johan Kuuse  wrote:

> Hi,
>
> Minimal fix: remove unused variable in Check-in [92ea6183]
>
>
> Index: src/file.c
> ==
> --- src/file.c
> +++ src/file.c
> @@ -626,11 +626,11 @@
>  **
>  ** On success, return zero.  On error, return errorReturn if
> positive, otherwise
>  ** print an error message and abort.
>  */
>  int file_mkfolder(const char *zFilename, int forceFlag, int errorReturn){
> -  int i, nName, rc = 0;
> +  int nName, rc = 0;
>char *zName;
>
>nName = strlen(zFilename);
>zName = mprintf("%s", zFilename);
>nName = file_simplify_name(zName, nName, 0);
>
>
> BR,
> Johan
>
>
> On Wed, Aug 23, 2017 at 6:33 PM, Richard Hipp  wrote:
> > On 8/23/17, Richard Hipp  wrote:
> >> The problem originates at this check-in:
> >> https://fossil-scm.org/fossil/timeline?c=2375d6cbce933267
> >
> > I do not understand what benefit the check-in above provides.  But it
> > does definitely change the semantics of a lot of operations,
> > complicate the code, and introduce bugs.  So I am inclined to back
> > that change out.
> >
> > If you are using the --no-dir-symlinks option and/or think it should
> > remain in the code, then you have 24 hours to make your case.  In the
> > absence of a compelling reason to keep the --no-dir-symlinks, and a
> > promise for fixes to the code, I will back out that capability at the
> > conclusion of the comment period.
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> > ___
> > fossil-dev mailing list
> > fossil-...@mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
> ___
> 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 easy questions

[David Mason]

Wow... longest thread I've ever seen.  I scanned through and didn't see
mention of the simplest solution, if you have shasum available.

> shasum urltags.js
1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
> fossil ui

Then go to localhost:8081/artifact/1bea11bf4a97b012e7d8b17c71a7d444f0b5a5aa
and you'll get the exact file you're looking for.  Of course, if someone
edited the file you're SOL. There may be a command-line way to do this, but
I can't find it.

../Dave
___
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 content for distribution

[David Mason]

Actually it's not clear what revert does. I removed the file and revert
didn't recover it. I created an empty file and revert didn't recover it.
(But maybe this is timestamp related, or because I'm on the machine that
created the uv file in the first place.)

Thanks  ../Dave

On 14 June 2017 at 01:41, David Mason <dma...@ryerson.ca> wrote:

> `fossil uv list` doesn't mention any path information. Does it have path
> information behind the scenes so that `fossil uv revert` can put the file
> in the original place?
>
> Is there a way to find if any unversioned file has been updated apart from
> looking at the hash or the date for particular files?
>
> Thanks  ../Dave
>
> On 14 June 2017 at 01:32, David Mason <dma...@ryerson.ca> wrote:
>
>> I finally got around to this, but I got the following errors on Linux:
>> : ~/Sites/p4ru/kitPJS ; fossil unversioned revert
>> Usage: fossil sync URL
>> : ~/Sites/p4ru/kitPJS ; fossil ver
>> This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
>> : ~/Sites/p4ru/kitPJS ; fossil unversioned list
>> 504e6cf08911 2017-06-14 00:45:18   37820760173 index.js
>> : ~/Sites/p4ru/kitPJS ; fossil sync -u
>> Usage: fossil sync URL
>> : ~/Sites/p4ru/kitPJS ; fossil unver cat index.js|wc
>>22347960  378207
>>
>> I downloaded this version today from the website. On MacOSX, `fossil sync
>> -u` seems to work fine (as does `fossil unver revert`). It's good that cat
>> works, but revert seems nicer!
>>
>> Thanks ../Dave
>>
>> On 10 May 2017 at 09:34, David Mason <dma...@ryerson.ca> wrote:
>>
>>> Perfect! I knew it would be easy.
>>>
>>> Thanks
>>>
>>> On 10 May 2017 at 07:04, Richard Hipp <d...@sqlite.org> wrote:
>>>
>>>> On 5/10/17, David Mason <dma...@ryerson.ca> wrote:
>>>> > I have a fossil repo and in it I have a file foo.js that is generated
>>>> by my
>>>> > build process - so I don't want it versioned. But I *do* want it
>>>> > distributed, and want it referencable from foo.html - which *is*
>>>> versioned.
>>>> > foo.html and foo.js are *not* served by fossil, but by a simple
>>>> apache or
>>>> > nginx server.
>>>> >
>>>> > So in my working directory I create foo.js and then do what to get it
>>>> moved
>>>> > to the master fossil repo.
>>>>
>>>> fossil uv add foo.js
>>>> fossil uv sync
>>>>
>>>>
>>>> > Then on my production machine I do what command
>>>> > to get the current version of foo.js from the master fossil repo?
>>>>
>>>> fossil uv sync
>>>> fossil uv export foo.js foo.js
>>>> OR:  fossil uv cat foo.js >foo.js
>>>>
>>>> >
>>>> > I'm sure it's easy, but the documentation does not give me guidance
>>>> on this
>>>> > simple use-case.
>>>> >
>>>> > Thanks  ../Dave
>>>> >
>>>>
>>>>
>>>> --
>>>> 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] Unversioned content for distribution

[David Mason]

`fossil uv list` doesn't mention any path information. Does it have path
information behind the scenes so that `fossil uv revert` can put the file
in the original place?

Is there a way to find if any unversioned file has been updated apart from
looking at the hash or the date for particular files?

Thanks  ../Dave

On 14 June 2017 at 01:32, David Mason <dma...@ryerson.ca> wrote:

> I finally got around to this, but I got the following errors on Linux:
> : ~/Sites/p4ru/kitPJS ; fossil unversioned revert
> Usage: fossil sync URL
> : ~/Sites/p4ru/kitPJS ; fossil ver
> This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
> : ~/Sites/p4ru/kitPJS ; fossil unversioned list
> 504e6cf08911 2017-06-14 00:45:18   37820760173 index.js
> : ~/Sites/p4ru/kitPJS ; fossil sync -u
> Usage: fossil sync URL
> : ~/Sites/p4ru/kitPJS ; fossil unver cat index.js|wc
>22347960  378207
>
> I downloaded this version today from the website. On MacOSX, `fossil sync
> -u` seems to work fine (as does `fossil unver revert`). It's good that cat
> works, but revert seems nicer!
>
> Thanks ../Dave
>
> On 10 May 2017 at 09:34, David Mason <dma...@ryerson.ca> wrote:
>
>> Perfect! I knew it would be easy.
>>
>> Thanks
>>
>> On 10 May 2017 at 07:04, Richard Hipp <d...@sqlite.org> wrote:
>>
>>> On 5/10/17, David Mason <dma...@ryerson.ca> wrote:
>>> > I have a fossil repo and in it I have a file foo.js that is generated
>>> by my
>>> > build process - so I don't want it versioned. But I *do* want it
>>> > distributed, and want it referencable from foo.html - which *is*
>>> versioned.
>>> > foo.html and foo.js are *not* served by fossil, but by a simple apache
>>> or
>>> > nginx server.
>>> >
>>> > So in my working directory I create foo.js and then do what to get it
>>> moved
>>> > to the master fossil repo.
>>>
>>> fossil uv add foo.js
>>> fossil uv sync
>>>
>>>
>>> > Then on my production machine I do what command
>>> > to get the current version of foo.js from the master fossil repo?
>>>
>>> fossil uv sync
>>> fossil uv export foo.js foo.js
>>> OR:  fossil uv cat foo.js >foo.js
>>>
>>> >
>>> > I'm sure it's easy, but the documentation does not give me guidance on
>>> this
>>> > simple use-case.
>>> >
>>> > Thanks  ../Dave
>>> >
>>>
>>>
>>> --
>>> 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] Unversioned content for distribution

[David Mason]

I finally got around to this, but I got the following errors on Linux:
: ~/Sites/p4ru/kitPJS ; fossil unversioned revert
Usage: fossil sync URL
: ~/Sites/p4ru/kitPJS ; fossil ver
This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
: ~/Sites/p4ru/kitPJS ; fossil unversioned list
504e6cf08911 2017-06-14 00:45:18   37820760173 index.js
: ~/Sites/p4ru/kitPJS ; fossil sync -u
Usage: fossil sync URL
: ~/Sites/p4ru/kitPJS ; fossil unver cat index.js|wc
   22347960  378207

I downloaded this version today from the website. On MacOSX, `fossil sync
-u` seems to work fine (as does `fossil unver revert`). It's good that cat
works, but revert seems nicer!

Thanks ../Dave

On 10 May 2017 at 09:34, David Mason <dma...@ryerson.ca> wrote:

> Perfect! I knew it would be easy.
>
> Thanks
>
> On 10 May 2017 at 07:04, Richard Hipp <d...@sqlite.org> wrote:
>
>> On 5/10/17, David Mason <dma...@ryerson.ca> wrote:
>> > I have a fossil repo and in it I have a file foo.js that is generated
>> by my
>> > build process - so I don't want it versioned. But I *do* want it
>> > distributed, and want it referencable from foo.html - which *is*
>> versioned.
>> > foo.html and foo.js are *not* served by fossil, but by a simple apache
>> or
>> > nginx server.
>> >
>> > So in my working directory I create foo.js and then do what to get it
>> moved
>> > to the master fossil repo.
>>
>> fossil uv add foo.js
>> fossil uv sync
>>
>>
>> > Then on my production machine I do what command
>> > to get the current version of foo.js from the master fossil repo?
>>
>> fossil uv sync
>> fossil uv export foo.js foo.js
>> OR:  fossil uv cat foo.js >foo.js
>>
>> >
>> > I'm sure it's easy, but the documentation does not give me guidance on
>> this
>> > simple use-case.
>> >
>> > Thanks  ../Dave
>> >
>>
>>
>> --
>> 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] Is it possible to merge repository's?

[David Mason]

You can have a working directory for one repository nested inside a folder in a 
working directory of another repository.  See the —nested option for `fossil 
open`.

I use this *extensively*. It’s very convenient. But it may not be quite what 
you want because you do have to commit separately for each repo.

../Dave

On May 31, 2017, 12:37 PM -0400, The Tick , wrote:
> The reason I had is because I started a subproject and, after a couple
> weeks, realized that it would be more convenient to have its repository
> merged into my main project as a sub-directory. I thought this might be
> an existing feature somehow.
___
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] Limiting cruft in my repos

[David Mason]

On 10 May 2017 at 17:05, Artur Shepilko  wrote:

> Not sure about the objectives the students are learning in this
> course,  but if it in any way relates to programming, recognizing as
> to what to keep under version control is a reasonable objective on its
> own.
>

While I might agree, and the top x% of the students would get that, x is
far smaller than any of us would like (probably 30% or less).  I further
can't afford a week of lectures to nail down the concept of SCMs.  The
largest course that I use fossil for has 160 students - with a wide range
of competencies - and covers 4 very different programming languages in 12
weeks.  There is no time for nuance in SCM details.

Unfortunately.

(If someone made me god, or gave me a magic wand, I would make the world
very different in many ways... including making SCMs and TDD intuitive
concepts for all humans, or at least all who would become programmers. :-)

../Dave
___
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] Limiting cruft in my repos

[David Mason]

I generate the initial fossil for them. The problem is that I don't
control, e.g. executable names, so if they have foo.c and say `make foo`
they will have foo.o which I can match, but also foo which I can't (because
they might call it foox.c - and hence foox - instead).

Because I generate the initial fossil the `:::BINARY:::` pattern in the
ignore-glob file is viable, as would be a `:::SizeOver:::10` pattern.

I'm mostly not worried about them intentionally or maliciously creating
cruft, but rather accidentally and carelessly.

../Dave

On 10 May 2017 at 09:50, Andy Bradford <amb-fos...@bradfords.org> wrote:

> Thus said David Mason on Wed, 10 May 2017 01:07:22 -0400:
>
> > If the  students were  very disciplined,  they would  assiduously edit
> > ignore-glob to prevent  this. But if there is one  thing that students
> > (en-mass) are not, it's disciplined!
>
> Do students  generate their own Fossil,  or is the Fossil  generated for
> them? If  it is generated for  them, why not just  commit an ignore-glob
> that covers the kinds of large files  they are likely to generate to the
> .fossil-settings directory?
>
> Andy
> --
> TAI64 timestamp: 400059131ac8
>
>
>
___
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] Limiting cruft in my repos

[David Mason]

Yes, that would work.

A flag to reject binary files could work too, for all the .o and .beam
files that are small but annoying.  I know that wouldn't work perfectly as
the binary detection is heuristic, but would be very convenient. Actually a
flag that caused `fossil add` and `fossil addremove` to treat binary files
as if they were in the ignore-glob would be perfect because  you could
override it with `--force` when the heuristic was wrong. Alternately a
special pattern in ignore-glob like `:::BINARY:::` would work.

It would also be convenient if these were exported configuration so when
they first clone the repo their local repo gets the configuration.

../Dave

On 10 May 2017 at 07:11, Richard Hipp <d...@sqlite.org> wrote:

> On 5/10/17, David Mason <dma...@ryerson.ca> wrote:
> > I've described before how I use fossil to manage student assignment
> > submissions in courses I teach.
> >
> > A perennial problem is that the students commit binary executables, .o
> > files, and the like. Theses change every build so I have dozens of
> versions
> > of potentially large files in the student repos.  Disk is cheap, but when
> > you have hundreds of students committing multiple versions of
> > multi-megabyte, it adds up.  If the students were very disciplined, they
> > would assiduously edit ignore-glob to prevent this. But if there is one
> > thing that students (en-mass) are not, it's disciplined!
> >
> > So I need something on the server side that will block large and/or
> binary
> > files from being saved (like an implicit shun).
> >
> > Any ideas?
> >
>
> Crazy idea:  Maybe we could add an option to the server configuration
> so that it rejects all files larger than a preset size - say 1MB.
> Source files would always be less than 1MB.  (Well, almost always -
> sqlite3.c is 7.1MB.  But student-written source files are less than
> 1MB.)  The rejection size threshold would be configurable, of course,
> and would default to infinity (and thus be turned off by default).
> Would something like that work for you?
>
> --
> 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] Unversioned content for distribution

[David Mason]

Perfect! I knew it would be easy.

Thanks

On 10 May 2017 at 07:04, Richard Hipp <d...@sqlite.org> wrote:

> On 5/10/17, David Mason <dma...@ryerson.ca> wrote:
> > I have a fossil repo and in it I have a file foo.js that is generated by
> my
> > build process - so I don't want it versioned. But I *do* want it
> > distributed, and want it referencable from foo.html - which *is*
> versioned.
> > foo.html and foo.js are *not* served by fossil, but by a simple apache or
> > nginx server.
> >
> > So in my working directory I create foo.js and then do what to get it
> moved
> > to the master fossil repo.
>
> fossil uv add foo.js
> fossil uv sync
>
>
> > Then on my production machine I do what command
> > to get the current version of foo.js from the master fossil repo?
>
> fossil uv sync
> fossil uv export foo.js foo.js
> OR:  fossil uv cat foo.js >foo.js
>
> >
> > I'm sure it's easy, but the documentation does not give me guidance on
> this
> > simple use-case.
> >
> > Thanks  ../Dave
> >
>
>
> --
> 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] Limiting cruft in my repos

[David Mason]

I've described before how I use fossil to manage student assignment
submissions in courses I teach.

A perennial problem is that the students commit binary executables, .o
files, and the like. Theses change every build so I have dozens of versions
of potentially large files in the student repos.  Disk is cheap, but when
you have hundreds of students committing multiple versions of
multi-megabyte, it adds up.  If the students were very disciplined, they
would assiduously edit ignore-glob to prevent this. But if there is one
thing that students (en-mass) are not, it's disciplined!

So I need something on the server side that will block large and/or binary
files from being saved (like an implicit shun).

Any ideas?

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

[fossil-users] Unversioned content for distribution

[David Mason]

I have a fossil repo and in it I have a file foo.js that is generated by my
build process - so I don't want it versioned. But I *do* want it
distributed, and want it referencable from foo.html - which *is* versioned.
foo.html and foo.js are *not* served by fossil, but by a simple apache or
nginx server.

So in my working directory I create foo.js and then do what to get it moved
to the master fossil repo. Then on my production machine I do what command
to get the current version of foo.js from the master fossil repo?

I'm sure it's easy, but the documentation does not give me guidance on this
simple use-case.

Thanks  ../Dave
___
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] [Announce] New FossilSCM Tortoise-like Finder extension for macOS - SnailFossil

[David Mason]

On 7 May 2017 at 12:20, John Pateman  wrote:

>
> The right click commit seems to work fine in Sierra. You need to add the
> checkout directory to the list that SnailFossil is tracking. The files that
> are synced up should all have a green tick badge. Adding a new file to the
> checkout folder should then result in the new file icon being tagged with a
> blue ‘?’. Right clicking brings up a context menu incl ‘Fossil commit’.
> There is a blank area for a commit message and below this, a list of
> possible files to add. There is a 'select all' checkbox or individual files
> can be selected.
>

The problem was that the Finder window has to be on the working directory
or a sub-directory.  If it's on a super-directory, commit doesn't work even
though you right-click>commit on a file in the working directory.

I've found a bunch of other problems and reported them.  They've been very
responsive - especially for a weekend!

../Dave
___
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] [Announce] New FossilSCM Tortoise-like Finder extension for macOS - SnailFossil

[David Mason]

I bought this, largely to support the Fossil community (because I don't use
Finder much, but this might change my workflow), and a couple of points:

1) the docs are wrong... to add a working directory you need to go to
SnailFossil preferences.

2) The right-click to commit doesn't do anything for me. I've emailed them,
but any help appreciated.

../Dave

On 7 May 2017 at 06:24, John Pateman  wrote:

> Apologies to all if this is not the correct etiquette but I wanted to
> bring to the attention of the Fossil users community a new finder extension
> for macOS that has been recently released. I have no affiliation with the
> developer (other than having written to them to ask if they would consider
> developing this!) or any commercial interest.
>
> Users may be familiar with ‘Tortoise’ - a windows interface adaptation
> that tags icons in the explorer with badges to indicate that they are in
> sync with a ‘git' master repository, have been added/removed etc. Recently
> a there has been a number of extensions written for other SCMs
> (git/mercurial and svn) by Langui enabling the same sort of functionality
> on macOS. I approached Langui recently to see if they would also consider
> supporting Fossil and they produced this new app!
>
> SnailFossil is now available on the Mac App Store:
> https://itunes.apple.com/us/app/snailfossil/id1226366997?mt=12
>
> I thought that this group would be a good place to bring this to users
> attention. Again, apologies if it is not but I do think the app should be
> worth a mention on the Fossil main site. There have been attempts to do
> this previously but this is a fully functional solution which seems to work
> extremely well.
>
> BW
>
> JP
>
> ___
> 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] Feature request: local .fossil-ignore

[David Mason]

I have had to use Git for something this semester.  It was mostly a failure
and I'll find a way to use fossil going forward.

That said, I noticed one feature of Git that was very useful, and I'd love
to see in Fossil.  In Git, you can have a .gitignore file in any directory
and it applies to that directory and nested sub-directories.  This is very
handy, especially for build directories and executables.  For example, if I
have a directory where I'm working on a program foo.c, I can (and do)
exclude *.o in my .ignore-glob, but I don't really want to put "foo" there
because I might have a file foo in another directory that I *do* want in
the repo. If I could put "foo" in a .fossil-ignore file - in that
particular directory - that would be very convenient. It would also be
useful in a target directory (for Rust/cargo) or a _build directory (for
Elixir/mix), where the only file you'd add to the repo would be the
.fossil-ignore, where you'd put "*" so that nothing would be added.

I think this would be a nice little project for someone who wants to delve
into the fossil codebase. I would, but I'm *way* over-committed at the
moment.

../Dave
___
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 deal with obsolete stuff in a repository

[David Mason]

Another option is to create a fossil for the 3rd party libraries, and then
open that fossil --nested in a directory inside your working directory.
Then nothing in that nested directory tree will be part of the main
fossil.  You don't even need to commit to it if you don't want.  Lastly,
when you don't want that version any more, remove the contents, close the
repo and create a new one for the new version of the 3rd-party library.

Nested repositories is one of the things I like best about Fossil.

../Dave

On 17 April 2017 at 22:26, The Tick  wrote:

> On 4/17/2017 9:11 PM, Ross Berteig wrote:
>
>> On 4/17/2017 6:50 PM, The Tick wrote:
>>
>>> I've put a project under fossil. Since it depends on a couple other
>>> libraries, I've also put those into the repository so that I am not
>>> dependent on being able to download those particular versions. Now,
>>> when new versions of those dependent libraries become available, I
>>> want to update my project. I could just add the new versions and
>>> modify my makefile. The problem I see is that over time the fossil
>>> repository is going to get >really< big as it will contain a bunch of
>>> obsolete stuff.
>>>
>>> Is there a way to handle this? I really want to keep the dependent
>>> libraries in the repository since who knows what might happen to
>>> someone else's open source project in the future, and in addition, it
>>> makes my project "self contained".
>>>
>>
>>
>>
>
>> Unzip the new library on top of the old in your workspace. Try to avoid
>> preserving a version number as part of the folder names in the workspace
>> even if your upstream does that to you. That will just confuse life.
>>
>>
> So I've goofed up by putting freetype-2.7.1/ and others into the
> repository?
>
> I guess I had assumed that I could just add, say, freetype-2.8 some day
> and change the master makefile as appropriate while making any other
> changes that might be necessary to accommodate the new library version.
> Then, I would do a commit after verifying everything still works.
>
> If the library's name should not contain a version string, I guess I'd
> need a readme or something to tell what the current version is? I guess the
> commit message could mention that, but stuff gets lost in all the commit
> messages.
>
>
> ___
> 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] Issue with ignore-glob

[David Mason]

I've been using fossil for several years now, so when I set up a new fossil
my first operation is to copy over an existing .fossil-settings and commit,
so I haven't been exposed to this problem for a while.  I certainly
remember when I first used it that it did some unexpected things. Perhaps
if there is no ignore-glob or --ignore fossil should give an error pointing
out that it will put *ALL* files into the repo. (When I say error here, and
in the earlier comment) I meant a prompt that you can override (like a
cr/lf file).)

I just did the following:

: /tmp ; fossil new foo.fossil
project-id: 4718320ad8895a1e5b2878f7d88ebb6b349c3777
server-id:  bf202e7dcd2d960fc5a4ead57fcd3b0ce6edb3d1
admin-user: dmason (initial password is "8bd847")
: /tmp ; cd foo
: /tmp/foo ; fossil open ../foo.fossil
project-name: 
repository:   /private/tmp/foo/../foo.fossil
local-root:   /private/tmp/foo/
config-db:/Users/dmason/.fossil
project-code: 4718320ad8895a1e5b2878f7d88ebb6b349c3777
checkout: 7ea66bcf3c7871acfb653662f743aa8b027d0dcc 2017-04-11 21:30:40
UTC
tags: trunk
comment:  initial empty check-in (user: dmason)
check-ins:1
: /tmp/foo ; echo 'int main(){}' >foo.c
: /tmp/foo ; make foo.o
cc-c -o foo.o foo.c
: /tmp/foo ; make foo
cc   foo.o   -o foo
: /tmp/foo ; fs addremove
ADDED  foo
ADDED  foo.c
ADDED  foo.o
added 3 files, deleted 0 files
: /tmp/foo ; fossil ci -m new
./foo contains binary data. Use --no-warnings or the "binary-glob" setting
to disable this warning.
Commit anyhow (a=all/y/N)?

I would have it similarly tell you that you haven't set up "ignore-glob"
and that it will add everything and let you commit anyway, maybe with a
list of all the files it is committing. To make it go away, all you'd have
to do is ``touch .fossil-settings/ignore-blob``.

../Dave
___
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 ignore-glob

[David Mason]

On 11 April 2017 at 14:34, Scott Robison  wrote:

> No, it is an explicit command clearly stating the user's desire for
> exclusion of these files *that are not already under source control*.
> The fact that the user does not remember or did not realize they
> issues conflicting commands does not mean that fossil should suddenly
> stop tracking the file, or so it seems to me.
>
> If a file was previously added to a repository (indicating a desire to
> keep track of modifications to the file), that is more important than
> ignoring the file.
>

I think --ignore should give an error if the --ignore matches a file
already in the repository.  The current behaviour is clearly somewhat
ambiguous.

Alternately (or additionally!) a command that would check and report if
there is any file(s) that would match the --ignore or the ignore-glob flag
would be helpful.

../Dave
___
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] OT: Facebook engineers preferring hg to Git

[David Mason]

Richard and Warren both make very legitimate comments.  I wasn't seriously
suggesting that work should stop moving Fossil forward for the perhaps
marginal benefit of conversion to Rust.

However, the value of Rust is not simply memory management.  The
*considerably* more expressive type system, and the much more robust type
checking can reduce LOC while improving both readability and safety.

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

[fossil-users] OT: Facebook engineers preferring hg to Git

[David Mason]

I's about 1/3 of the way through this report:
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/nh4fITFlEMk

It seems that they originally preferred GIT (because it was what they knew)
but now prefer hg, although it's a bit light on the reasons.  The article
points out that Facebook has a heavily mod-ed version of hg.  It might be
interesting to see what they've done that has made their people happy...
for consideration for fossil.

There's also a new command called absorb that does some merging before
commits that seems quite useful.

Also of interest is that Facebook is doing an implementation of hg in Rust.
Fossil seems pretty robust in C, but Rust would increase safety confidence.

../Dave
___
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] Purging data from Fossil

[David Mason]

Another nice use of this capability would be to make nested fossils - one
of the really nice unique features of fossil.

Eg. fossil X with directories A, B and C (and lots of files and commits).
If you could (via export or strip) C into C.fossil and everything *but* C
into RestX.fossil then you could now open C.fossil nested under a RestX
opened directory and the fossils can be shared and maintained separately...

So ARGS should allow you to include or exclude a directory and everything
under it.

On 26 July 2016 at 17:04, Richard Hipp <d...@sqlite.org> wrote:

> Further thoughts:
>
> With shunning, Fossil remembers the SHA1 hashes of the shunned
> artifacts so that they can never again be received by subsequent
> pulls.  It seems like this is more than you need.  Suppose we created
> a new command
>
> "fossil trim ARGS..."
>
> This new command would remove selected artifacts from the local copy
> of the repository, but the removal would be temporary.  The artifacts
> would reappear the next time the local repository is synced with some
> other repo that holds the artifacts.  (The removal would, of course,
> be permanent if there were no other copies of the repo to sync with.)
> It seems like the "trim" command might serve several purposes:
>
> (1) Allow the creation of a repo that omits selected historical
> information that one does not want to share.
>
> (2) Allows putting Fossil into a weird state in order to stress the
> sync logic for testing purposes.
>
> I could have made use of this feature for purpose (1) last week, had
> it been available.  So I am now officially interested in adding it.
>
> The ARGS part would embody several options for doing things like
> removing all instances of a specific file, or all check-ins within a
> range of dates, all tickets matching some criteria, all wiki pages
> whose names match a GLOB pattern, etc.  The problem I had last week
> was I needed a cut-down instance of a repository that only contained
> data for two specific check-ins out of around 3000.
>
> Community members, I want your help as follows:
>
> (A)  Suggest a better name than "fossil trim"
>
> (B)  Define the syntax of ARGS.
>
> (C)  Define a safety mechanism that allows content to be restored if
> it is accidentally trimmed when there are no other repos available
> with which to sink.  Perhaps the trimmed content gets written into a
> separate "trash-can" database?
>
> On 7/26/16, David Mason <dma...@ryerson.ca> wrote:
> > I have a problem.
> >
> > I use fossil for my courses - one I've used for 4 years.  In each year
> > there are grades files (with student names, student numbers and grades),
> > and they get changed and committed over the semester, so there are many
> > versions in the fossil (hundreds of checkins).
> >
> > I want to share these fossils with some people who cannot be allowed to
> see
> > the grades files. So I need to remove the data.  I could shun the
> artifacts
> > and rebuild (and, in fact that's what I started to do), but finding all
> the
> > versions of the files seems rather daunting, and it appears I can only
> shun
> > from the UI, so I can't even write a script to do it.
> >
> > Any ideas on how to clean this up? fossil purge looked like it might
> help,
> > but then not so much...
> >
> > BTW, on the shun page, when it lists pending shuns at the bottom of the
> > page, it would be very convenient if it listed the files that correspond
> to
> > that hash (probably only 1, modulo renaming, but useful regardless).
> >
> > Thanks for any help!
> >
> > ../Dave
> >
>
>
> --
> 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] Purging data from Fossil

[David Mason]

On 26 July 2016 at 17:13, Richard Hipp  wrote:

> SELECT DISTINCT uuid
>   FROM blob, mlink, filename
>

Works a charm (18 UUIDs show up).  Now if there were a way to shun from the
command line, I'd be golden.

BTW, swapping "uuid" and "filename.name" in the SQL lists the files that
match a uuid.

Thanks  ../Dave
___
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] Purging data from Fossil

[David Mason]

Is there any way to find all the artifacts that correspond to a given
pathname?  Then I could shun those.

On 26 July 2016 at 16:51, Richard Hipp <d...@sqlite.org> wrote:

> On 7/26/16, David Mason <dma...@ryerson.ca> wrote:
> > I have a problem.
> >
> > I use fossil for my courses - one I've used for 4 years.  In each year
> > there are grades files (with student names, student numbers and grades),
> > and they get changed and committed over the semester, so there are many
> > versions in the fossil (hundreds of checkins).
> >
> > I want to share these fossils with some people who cannot be allowed to
> see
> > the grades files. So I need to remove the data.  I could shun the
> artifacts
> > and rebuild (and, in fact that's what I started to do), but finding all
> the
> > versions of the files seems rather daunting, and it appears I can only
> shun
> > from the UI, so I can't even write a script to do it.
> >
> > Any ideas on how to clean this up? fossil purge looked like it might
> help,
> > but then not so much...
>
> It is theoretically possible to do this with the current data design.
> It would really just be a few SQL statements, with the corresponding C
> code to handling the user interface.  But that code does not currently
> exist.
>
> Adding code to do this would make a good student project.  Do you have
> any students willing to undertake it?  :-)
>
>
> >
> > BTW, on the shun page, when it lists pending shuns at the bottom of the
> > page, it would be very convenient if it listed the files that correspond
> to
> > that hash (probably only 1, modulo renaming, but useful regardless).
>
> The "shun" table currently has the "scom" field which is intended to
> be human-readable text that explains why the shun occurred.  Probably
> you would want to add another field to be the filename of the object
> shunned.  This is doable.  But, again, the code is not yet in place.
>
> --
> 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] Purging data from Fossil

[David Mason]

I have a problem.

I use fossil for my courses - one I've used for 4 years.  In each year
there are grades files (with student names, student numbers and grades),
and they get changed and committed over the semester, so there are many
versions in the fossil (hundreds of checkins).

I want to share these fossils with some people who cannot be allowed to see
the grades files. So I need to remove the data.  I could shun the artifacts
and rebuild (and, in fact that's what I started to do), but finding all the
versions of the files seems rather daunting, and it appears I can only shun
from the UI, so I can't even write a script to do it.

Any ideas on how to clean this up? fossil purge looked like it might help,
but then not so much...

BTW, on the shun page, when it lists pending shuns at the bottom of the
page, it would be very convenient if it listed the files that correspond to
that hash (probably only 1, modulo renaming, but useful regardless).

Thanks for any help!

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

[fossil-users] "The Hammer Principle" and version control

[David Mason]

It's a strange name, but this website gives useful ranking of many things
over a variety of competing products.

Here is the version-control link: http://hammerprinciple.com/versioncontrol

Fossil does quite well along many of the vectors of comparison, but adding
your ranking would help.

../Dave
___
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] Getting time of last repository change

[David Mason]

I submitted a patch to create a --mail-quiet option for update that is
quiet unless a change has happened.  But it never made its way into trunk
(even though I sent the copyright form to Rich)

The comment for it reads:

The -m or --mail-quiet option suppresses status info unless there was
some change that took place in the current checkout.  This is useful
in a cron script to send mail only when an update is performed, such as:
fossil update -m | mail -E -s "update occurred" a...@ex.com b...@ex.com

I use it on my server for all my fossils.

Here's the diff, if anyone is interested:

: ~/fs/fossil ; fs diff -r 2186f0f0e7

ADDEDfeatures-requests-dmason

Index: src/update.c

==

--- src/update.c

+++ src/update.c

@@ -83,22 +83,28 @@

 ** If FILES is omitted, all files in the current checkout are subject

 ** to being updated and the version of the current checkout is changed

 ** to VERSION. Any uncommitted changes are retained and applied to the

 ** new checkout.

 **

+** The -m or --mail-quiet option suppresses status info unless there was

+** some change that took place in the current checkout.  This is useful

+** in a cron script to send mail only when an update is performed, such as:

+** fossil update -m | mail -E -s "update occurred" a...@ex.com b...@ex.com

+**

 ** The -n or --dry-run option causes this command to do a "dry run".

 ** It prints out what would have happened but does not actually make

 ** any changes to the current checkout or the repository.

 **

 ** The -v or --verbose option prints status information about

-** unchanged files in addition to those file that actually do change.

+** unchanged files in addition to those files that actually do change.

 **

 ** Options:

 **   --case-sensitive  override case-sensitive setting

 **   --debug  print debug information on stdout

 **   --latest acceptable in place of VERSION, update to latest
version

 **   --force-missing  force update if missing content after sync

+**   -m|--mail-quiet  quiet unless there are actual changes

 **   -n|--dry-run If given, display instead of run actions

 **   -v|--verbose print status information about all files

 **   -W|--width  Width of lines (default is to auto-detect). Must be
>20

 **or 0 (= no limit, resulting in a single line per
entry).

 **

@@ -112,10 +118,11 @@

   int dryRunFlag;   /* -n or --dry-run.  Do a dry run */

   int verboseFlag;  /* -v or --verbose.  Output extra information */

   int forceMissingFlag; /* --force-missing.  Continue if missing content */

   int debugFlag;/* --debug option */

   int setmtimeFlag; /* --setmtime.  Set mtimes on files */

+  int hideInfoFlag; /* -m or --mail-quiet. Quiet unless there are
actual changes */

   int nChng;/* Number of file renames */

   int *aChng;   /* Array of file renames */

   int i;/* Loop counter */

   int nConflict = 0;/* Number of merge conflicts */

   int nOverwrite = 0;   /* Number of unmanaged files overwritten */

@@ -144,10 +151,11 @@

   }

   verboseFlag = find_option("verbose","v",0)!=0;

   forceMissingFlag = find_option("force-missing",0,0)!=0;

   debugFlag = find_option("debug",0,0)!=0;

   setmtimeFlag = find_option("setmtime",0,0)!=0;

+  hideInfoFlag = find_option("mail-quiet","m",0)!=0;



   /* We should be done with options.. */

   verify_all_options();



   db_must_be_within_tree();

@@ -514,15 +522,18 @@

 free(zFullPath);

 free(zFullNewPath);

   }

   db_finalize();

   db_finalize();

-  fossil_print("%.79c\n",'-');

   if( nUpdate==0 ){

-show_common_info(tid, "checkout:", 1, 0);

-fossil_print("%-13s None. Already up-to-date\n", "changes:");

+if ( !hideInfoFlag ){

+  fossil_print("%.79c\n",'-');

+  show_common_info(tid, "checkout:", 1, 0);

+  fossil_print("%-13s None. Already up-to-date\n", "changes:");

+}

   }else{

+fossil_print("%.79c\n",'-');

 show_common_info(tid, "updated-to:", 1, 0);

 fossil_print("%-13s %d file%s modified.\n", "changes:",

  nUpdate, nUpdate>1 ? "s" : "");

   }


On 11 April 2016 at 11:17, Stephan Beal  wrote:

> On Mon, Apr 11, 2016 at 5:06 PM, Jan Danielsson <
> jan.m.daniels...@gmail.com> wrote:
>
>>The most obvious method would be to do roughly what the timeline does
>> and find the latest modification on the timeline, but this wouldn't work
>> (since it would miss modifications from older checkins (say a user on a
>> secondary site checks in an old experimental branch)).
>>
>
> That would still retain the current time for timeline purpose, making it
> the newest (assuming there's not a clock skew or similar, in which case all
> bets are off).
>
> Ach... i just set up this new PC yesterday and don't have any source repos
> (nor a copy of fossil) on it, so i can't try this out right 

Re: [fossil-users] Fossil and SQLite on Slant

[David Mason]

Somebody implied that Fossil bug tracking requires the CLI.
http://www.slant.co/topics/2727/viewpoints/8/sections/4/comments#1

I don't think that's true, but when I go to http://fossil-scm.org and click
on tracker, there is no way to enter a bug, even if I log in as anonymous.
I haven't actually used the bug-tracker yet, so I don't know what I'm
missing.

../Dave

On 7 April 2016 at 16:17, David Mason <dma...@ryerson.ca> wrote:

> I just added
> http://www.slant.co/topics/1274/viewpoints/5/~acid-compliant-scalable-databases~sqlite
> and
> http://www.slant.co/topics/2727/viewpoints/8/~self-hosted-bug-trackers~fossil
> on Slant.co
>
> Others might be better placed to add pros and cons.
>
> ../Dave
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fossil and SQLite on Slant

[David Mason]

I just added
http://www.slant.co/topics/1274/viewpoints/5/~acid-compliant-scalable-databases~sqlite
and
http://www.slant.co/topics/2727/viewpoints/8/~self-hosted-bug-trackers~fossil
on Slant.co

Others might be better placed to add pros and cons.

../Dave
___
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 questions

[David Mason]

A switch or setting to --perservemtime sounds like it would be easy to do,
and useful.

It would leave the default behaviour for legacy reasons but allow Zoltan
and others who are willing to do the make clean;make (like me) to have a
useful set of file times.

The nice thing would be that if you're bisecting, you can do it without the
switch and get fast compilation of differences, and then you could do a
fresh checkout with the switch and get the times set back to their
providence.

../Dave

On 17 February 2016 at 08:41, Richard Hipp  wrote:

> On 2/17/16, Zoltán Kócsi  wrote:
> >
> > In fact, what I saw was that fossil didn't even do that. I checked out
> > two branches (with different last mod dates) into two separate
> > directories and every file had the same mtime: the current time when I
> > checked them out. That is, fossil simply wrote the files from the
> > database to the filesys and left the mtime as it was set by the system.
> >
>
> That is the desired behavior, because when you do "fossil update;
> make" that makefile will be looking at the mtimes and you want recent
> mtimes so that the project is correctly rebuilt.
>
> --
> 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] Write problem for SSH access to fossil

[David Mason]

On 9 February 2016 at 15:56, Andy Bradford  wrote:

> Are you allowing REMOTE_USER to work in your Fossils/dmason.fossil?
>
> $ echo "SELECT * FROM config WHERE name = 'remote_user_ok';" | fossil sql
> -R Fossils/dmason.fossil
>

Bingo!  I had actually added this to my script last year

   fossil sqlite $f "INSERT INTO config VALUES
('remote_user_ok',1,strftime('%s','now'));"

but I had omitted the -R switch (for some reason I can't fathom at the
moment, I wasn't seeing the errors that I get if I try this at the command
line).

All good now.

To Warren: if you use REMOTE_USER in the .ssh/authorized_keys file, you get
full enforcement of permissions.

Thanks!  ../Dave
___
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] Problem on windows sync

[David Mason]

I'm reviving a question about a problem from a year ago that was never
satisfactorily resolved (the student gave up and never replied to my
request for --sshtrace).

This time the (new) student has not committed successfully, and on any
attempt to write gets "Unable to write to standard output: The pipe is
being closed."  This is using SSH/PLINK on Windows.

I ran "fossil sync --sshtrace" and saw exactly the headers I'd expect (200,
etc). The student.fossil file on the remote server appears to have been
written to by the clone command, but not by the commit or sync.  I expect
this is the case for MANY of the students using Windows.

Because of other issues (which I'll address separately) the remote
directory has 777 permissions and the remote fossil has 666.  The other
issues *might* be the same problem but we get different responses from
Windows and Mac.

../Dave

On 26 March 2015 at 15:42, David Mason <dma...@ryerson.ca> wrote:

> Me again... :-)
>
> I have a student running Windows using the current fossil as of January.
>
> 1) PLINK.EXE works so there's no ssh problem.
> 2) She has successfully committed before.
> 3) She tried to commit and got a "Would fork" so
> 4) She did an update
> 5) then commit she got "Unable to write to standard output: The pipe is
> being closed." on the autosync part.
> 6) Subsequent sync does same think - after her command prompt has been
> printed.
>
> I thought I'd seen this on the list, but google only gives one hit (in
> Japanese) on part of the search string.
>
> Any ideas?
>
> Thanks  ../Dave
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Write problem for SSH access to fossil

[David Mason]

As you may remember, I use fossil to have students submit assignments for
my courses.  Last year it worked well (eventually) with some problems with
Windows.

I have 160+ students.  All of their fossils are made by the same script
that creates a user with their ID and capabilities:v and a developer user
that has capabilities:dei and a dmason user with capabilities s. Most of
them access their fossil via an ssh connection to a common account: ssh://
cps...@cps506.sarg.ryerson.ca and none of them have been able to
sync/commit to their remote fossil, getting a: "Error: not authorized to
write" message.  But my grad students who have an account on the machine
and can hence ssh to a shell on it are able to commit.

So I cloned a sample fossil each of the 2 ways

fs clone ssh://cps...@cps506.sarg.ryerson.ca xxx.fossil
fs clone ssh://cps506.sarg.ryerson.ca/cps506-fossils/xxx.fossil xxx2.fossil

These both reference sym-links to the same fossil file on the server.

The first one cannot write, the second one can.

The first one goes through an authorized_keys file with a line like:
command="REMOTE_USER=dmason fossil http Fossils/dmason.fossil" ssh-rsa
CCMZ dmason

There is a user dmason with capabilities s in the fossil.

This all worked last year, but doesn't now.  I thought it might have to do
with the students having a different version of fossil, but this is me
running version 1.34 locally and on the server.  The server directory is
777, the fossil file is 666,

I just changed the link accessed by the cps506 user to a fossil file from
last year and it worked!  The old one again has me as s - the only
capability difference was that last year's anonymous had z permissions.
But changing that in the current file didn't fix anything (I didn't
re-clone it, just tried to push).

I'm mystified.  Any ideas?

Thanks  ../Dave
___
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)

[David Mason]

On 3 November 2015 at 10:48, Eric Rubin-Smith  wrote:

>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal 
> wrote:
>>
>> i can't speak for Richard, but if i had my way, fossil wouldn't support
>> symlinks at all.
>>
>
This would force me to stop using Fossil (or at least updating to a version
that didn't support them), and to recommend to everyone (including the
hundreds of students who I've introduced to Fossil) to be wary using it.

Part of the problem in this discussion is that everyone seems to be
assuming that Fossil is only used for source trees and makefiles.  I
maintain a dozen web sites, a few of them are my course-based ones.  I have
(simplified for expository purposes) let's say 3 repos: Courses, cps710 and
cps506.  Courses has sub-directories Themes (for CSS, etc.) and JScript.
 cps710 and cps506 are nested under Courses, so the structure looks like:
Courses
   Themes
   JScript
   cps710
 Themes -> ../Themes
 JScript -> ../JScript
 f2013
  index.html
  f2013 -> .
  current -> ../current
  Themes -> ../Themes
  JScript -> ../JScript
 f2015
  index.html
  f2015 -> .
  current -> ../current
  Themes -> ../Themes
  JScript -> ../JScript
 current -> f2015
 index.html -> current/index.html
   cps506
 Themes -> ../Themes
  JScript -> ../JScript
 index.html -> current/index.html
etc.

So symlinks, with nested repos is a huge win for me.  Fortunately, I only
need to set up a new course occasionally, so I only have to fight with
Fossil about symlinks occasionally, but too often!

The poor support for symlinks is far and away my biggest complaint with
Fossil. (The limited support for file permissions is second, because I
often want to put things in the repo that I'm not ready to show the
students yet.)

It's simple: a symlink is a filesystem artifact and should be reflected as
such in the repository.  It should not be followed; if foo is a symlink and
I say "fs add foo/bar" it should probably give an error. (This might
surprise people the first time, but it's easy to explain - foo/bar isn't
part of the repo, regardless of where foo points.)


> :-) Fossil creates a problem by not supporting symlinks properly, and you
> use the volume of complaints about the problem to support your claim that
> the problem was inevitable.
>
> Not implementing them at all, or implementing them poorly as Fossil has,
> is what maximizes complaints -- hence the large amount of emails.
>

Exactly.  Please fix symlinks so that if you live only on Unix you get
seamless support.  If you work back and forth between Windows and Unix then
you probably just don't use symlinks, so it won't be a problem for you!

../Dave
___
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] Multiple Projects in one Repo

[David Mason]

On 16 September 2015 at 21:56, Steve Stefanovich  wrote:

> ‎Isn't the main annoyance the need to commit two times, one in nested
> checkout and one in the 'root' repo, and to try to keep timeline order in
> both?
>
> How do you guys manage that - prevent committing/cloning to root and
> always use sub-repos?


There's only one commit, in the sub-repo, unless I change something in the
root repo, but that's pretty rare for me.

../Dave
___
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] Multiple Projects in one Repo

[David Mason]

On 14 September 2015 at 13:58, Warren Young  wrote:

> On Sep 12, 2015, at 9:54 AM, Oliver Friedrich <
> redtalonof+mailingl...@gmail.com> wrote:
> >
> > with nested repositories my administration overhead would exceed even
> the single repository solution, right?
>
> The alternative to managing just one .fossil file is managing just one
> directly full of .fossil files.  Is that really such a big difference?
>
> Note that “fossil serve” works the same when pointed to a directory full
> of fossils as it does when pointed at a single fossil, with the exception
> that the URLs are all one directory deeper.


I use nested checkouts and I have many .fossil files in my ~/Fossils
directory.  One of them, Admin, has a wiki page that points to pages in the
others so I can access them easily.  I keep the url
http://localhost:8080/Admin/wiki?name=Admin open in one of my browser tabs
(actually the first one) so I can easily get at any of the repos in one
click.  I have sections in that wiki page like:

Direct Links
  *  Courses Links
  *  CPS313 Links

Administrative links
  *  Courses
  *  Research

along with other generally useful links.

Yes, I have to use --nested when I open a new directory on a repo, but I do
that only a few times a year (in fact, I usually forget, but fossil tells
me there's a problem, so I re-issue the open with --nested).

../Dave
___
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] why merge does not prompt for commit?

[David Mason]

On 26 August 2015 at 04:27, Luca Ferrari fluca1...@infinito.it wrote:


 Correct!
 Shame on me.


Not shame, at all!  Some of the reasons for things are useful to think
about, and because a popular system (e.g. GIT) does it a particular way can
make us think it is the right way without thinking carefully.  I didn't
know GIT did this, which makes it another strike against it, from my
perspective.  For example, if you had a C (for a common example):

void foo(someRec *x) {
   x.a=1;
   x.b=2;
   x.c=3;
}

and 2 developers realized that x.count needed to be incremented every time
foo was called, developer A adds x.count++; as the first statement and
developer B does the same thing as the *last* statement.  Once merged and
committed, foo will increment count by *2*.  If after the merge the
developers had run their test suite, they would detect the trivial error
and fix it.

../Dave
___
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] Files shared (and updated) between repos?

[David Mason]

On 21 August 2015 at 07:33, Martin Gagnon eme...@gmail.com wrote:

 - Links in home page on each of your repos:
 - Open nested repository:


I do the nested one a lot (I have a Courses repo with common stuff for all
the courses I teach, and a nested repo underneath for each course).

The 3rd choice is a symbolic-link.  Many of my repos are research based
where there are papers to be written, so then have a symlink ln -s ../TeX
. that points to a common TeX repo.  Note that you may have to enable
symlinks in your repo, and this may not work well on Windows.

../Dave
___
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] forget binary files

[David Mason]

On 4 August 2015 at 06:09, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Aug 4, 2015 at 12:04 PM, Luca Ferrari fluca1...@infinito.it
 wrote:

 On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal sgb...@googlemail.com
 wrote:
  http://www.fossil-scm.org/index.html/help?cmd=/shun

 In that case you would have to shun all of the files individually. Fossil,
 by design, makes it exceedingly difficult to change history, and that
 includes removing files. Shunning is really only intended to be used when
 someone checks in sensitive or malicious data.


 But it's a reasonable way to remove binaries that you don't want.  Just be
careful not to shun 0 length files or you won't be able to commit a
0-length file until you've cleared the shun table (because all 0-length
files have the same SHA-1 id.

../Dave
___
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 serve repolist error

[David Mason]

A simple fix would seem to be to match *.fossil but not .fossil - in other
words, require a non-empty prefix to consider it a fossil.

../Dave
​
___
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] workflow question

[David Mason]

I use Fossil in 2 ways with students.

1) for each research project I have a Fossil, and all Grad students working
on that project (and I) have commit access.  There are few enough people
that it works out.

2) for assignments, I create a Fossil per student and the student plus the
marker(s) and I have commit access.

The biggest problem is people committing binary blobs to the repo.  But
they can be shunned, if necessary, to manage repo size.

../Dave
​
___
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 changes] and execute/symlink flag changes

[David Mason]

Any improvement to the handling of symlinks gets my vote!

../Dave

On 7 May 2015 at 23:25, Abilio Marques abili...@gmail.com wrote:

 +1. Been there, two times just in the last week (I need to sleep better).

 On Thu, May 7, 2015 at 7:51 PM, Andy Goth andrew.m.g...@gmail.com wrote:

 I propose extending [fossil changes] to report when a file's execute bit
 has changed or it has become a symlink or ceased to be a symlink.

 For various annoying reasons, many times I've unwittingly checked in a
 bunch of execute or symlink brokenness, sometimes not discovering it
 until much later.  Running [fossil changes] before [fossil commit] isn't
 enough to protect me from this problem.

 My question is whether this extra level of reporting should be standard
 [fossil changes] behavior or only accessible if an extra option is
 supplied.  My vote is to make it always report execute bit and symlink
 state changes.

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

[David Mason]

Thanks for the examples, Andy.

I use symlinks a lot.  I *really* wish fossil handled them properly.

This is one of my biggest beefs about fossil.

The other big one is that if I set some property (in this case
allow-symlinks true) and I also set the corresponding .fossil-setting I get
a warning when I do almost anything.  Even if they are saying the same
thing (i.e., yes, allow).  I definitely should get a warning if they
disagree, but the current behaviour is annoying. (And the reason I do the
set version is to work around some of points Andy was making at the
beginning of this thread. And the reason I do the .fossil-settings version
is to document the status in the file-system, or if I were ever to want to
put the working directory into another fossil, I want the symlinks handled
properly.)

I keep intending to do something about these annoyances, but never find the
time.

../Dave
___
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

[David Mason]

Here is another problem with symlinks:

​Last login: Tue Apr  7 20:11:50 on ttys004

: ~ ; cd /tmp

: /tmp ; fs init foo.fossil

project-id: d24564a4337e8c50f77a20ee355e2f76a9b84b78

server-id:  aa025469a22046732337b7fa075c7c4e85f45c0a

admin-user: dmason (initial password is d5a283)

: /tmp ; cd foo

: /tmp/foo ; fs open ../foo.fossil

project-name: unnamed

repository:   /private/tmp/foo/../foo.fossil

local-root:   /private/tmp/foo/

config-db:/Users/dmason/.fossil

project-code: d24564a4337e8c50f77a20ee355e2f76a9b84b78

checkins: 0

: /tmp/foo ; mkdir foo

: /tmp/foo ; touch foo/bar foo/blat

: /tmp/foo ; fs add foo

ADDED  foo/bar

ADDED  foo/blat

: /tmp/foo ; fs ci -m foo

New_Version: d01c99b9316832532f4acdf7b1afb06e9c071e43

: /tmp/foo ; mv foo ../foob

: /tmp/foo ; ln -s ../foob foo

: /tmp/foo ; fs stat

repository:   /private/tmp/foo/../foo.fossil

local-root:   /private/tmp/foo/

config-db:/Users/dmason/.fossil

checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41
UTC

leaf: open

tags: trunk

comment:  foo (user: dmason)

: /tmp/foo ; ls -l

total 8

lrwxr-xr-x  1 dmason  wheel  7  8 Apr 15:21 foo - ../foob

: /tmp/foo ; fs stat

repository:   /private/tmp/foo/../foo.fossil

local-root:   /private/tmp/foo/

config-db:/Users/dmason/.fossil

checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41
UTC

leaf: open

tags: trunk

comment:  foo (user: dmason)

EDITED foo/bar

: /tmp/foo ;

As you can see if a directory is replaced with a link to a directory
outside of the working directory it doesn't recognize it.  And it thinks
that files in that directory (which is outside the WD) are still to be
tracked.

This bit me when I was moving several projects into fossil, and I
recognized a common subdirectory (TeX to be exact), so I did something like
the above.  Took a while to figure out what went wrong and to fix it.

Same problem if you move the directory into a nested working directory.
Continuing from the previous example (hence the first couple of commands to
revert to the original situation):

: /tmp/foo ; rm foo;mv ../foob foo

: /tmp/foo ; cd ..

: /tmp ; fossil init bar.fossil

project-id: a52834ead71c0589bfe88c2874c45fb05818d3d4

server-id:  9b79fad662c144ea54dca3ab3f5b5fc522030c0d

admin-user: dmason (initial password is d4f221)

: /tmp ; cd foo

: /tmp/foo ; fs stat

repository:   /private/tmp/foo/../foo.fossil

local-root:   /private/tmp/foo/

config-db:/Users/dmason/.fossil

checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41
UTC

leaf: open

tags: trunk

comment:  foo (user: dmason)

EDITED foo/bar

: /tmp/foo ; mkdir bar

: /tmp/foo ; cd bar

: /tmp/foo/bar ; fs open --nested ../../bar.fossil

project-name: unnamed

repository:   /private/tmp/foo/bar/../../bar.fossil

local-root:   /private/tmp/foo/bar/

config-db:/Users/dmason/.fossil

project-code: a52834ead71c0589bfe88c2874c45fb05818d3d4

checkins: 0

: /tmp/foo/bar ; cd ..

: /tmp/foo ; ls

bar foo

: /tmp/foo ; mv foo bar

: /tmp/foo ; ln -s bar/foo .

: /tmp/foo ; fs stat

repository:   /private/tmp/foo/../foo.fossil

local-root:   /private/tmp/foo/

config-db:/Users/dmason/.fossil

checkout: d01c99b9316832532f4acdf7b1afb06e9c071e43 2015-04-08 19:20:41
UTC

leaf: open

tags: trunk

comment:  foo (user: dmason)

EDITED foo/bar

: /tmp/foo ; cd bar

: /tmp/foo/bar ; fs ext

foo/bar

foo/blat

: /tmp/foo/bar ;

So now we have the same files in 2 repositories.  Not the expected (nor, I
suspect, intended) behaviour.

Moving and symlinking *within* a repo seems to work properly.
___
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

[David Mason]

What Scott says, abbreviated from the C FAQ:

http://c-faq.com/null/ptrtest.html
​
FWIW, I always use if(p) to verify a pointer is valid.

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

[fossil-users] Problem on windows sync

[David Mason]

Me again... :-)

I have a student running Windows using the current fossil as of January.

1) PLINK.EXE works so there's no ssh problem.
2) She has successfully committed before.
3) She tried to commit and got a Would fork so
4) She did an update
5) then commit she got Unable to write to standard output: The pipe is
being closed. on the autosync part.
6) Subsequent sync does same think - after her command prompt has been
printed.

I thought I'd seen this on the list, but google only gives one hit (in
Japanese) on part of the search string.

Any ideas?

Thanks  ../Dave
___
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] Minor bug that causes some confusion

[David Mason]

Problem 2 is similar to fossil add filename saying ADDED: filename even
if it was already known.  This confuses novice users.

On 25 March 2015 at 16:44, to...@acm.org wrote:

   This is on a Windows machine so, filenames are case insensitive.

 To reproduce (f = fossil):

 f new xxx.fossil
 f o xxx.fossil
 echo Hello  hello
 f add hello
 f cha
 f ext
 f rev Hello
 f cha
 f ext

 Problem 1: “f rev Hello” does not revert the ADD (note: Hello is given
 with a different case from the previously added “hello” but on a Windows
 system this should not matter).  I assume this behavior is related to the
 name mismatch due to wrong use of case-sensitive comparison under Windows.

 Problem 2: The REVERT command always says “UNMANAGE: filename” even when
 it does nothing.  Combined with the previous problem, this is misleading.
 Saying UNMANAGE for any random filename when that filename is not part of
 the repo (or even the disk) is also wrong in itself.

 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] Fossil version 1.32

[David Mason]

Does the server fossil know the version number of the client fossil on a
clone?  Or could it ask?  If so, it could do what Andy suggests.

../Dave

On 16 March 2015 at 14:24, Richard Hipp d...@sqlite.org wrote:

 On 3/16/15, Andy Bradford amb-fos...@bradfords.org wrote:
  Thus said Stephan Beal on Mon, 16 Mar 2015 18:41:34 +0100:
 
  wiki-/ticket-only repos might not have a manifest at all.
 
  Then these  types of repositories would  have to be unclonable  by older
  versions of  Fossil. The server would  have to refuse the  clone request
  (similar to how it refuses to accept content from clients with an out of
  date  schema).  The clone  protocol  could  be  modified to  include  an
  identifier  that allows  the  server to  know if  such  a repository  is
  incompatible  with the  client making  the request  before allowing  the
  clone to proceed.
 
  Not sure if this is even possible, but in theory it seems to work. :-)
 

 Keep in mind that if everyone is using Fossil 1.30 or later, we never
 need to have any check-ins in the repository and the first check-in
 (if one exists) need not be artifact 1.  The code already takes care
 of all of that.

 The problem comes up when people try to use Fossil 1.27.  And we
 cannot go reach into peoples machines and fix 1.27.  We have to work
 around whatever it is that 1.27 does.
 --
 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] Google code shutting down

[David Mason]

Thank you Graeme for your thought-provoking post.  It seems most
challenges and rebuttals have played out.

If anyone was mining this thread for ways to improve fossil, I think
they'd see 2 things:

1) Fossil's ticket handling is not best-in-class.  What are the key
features that would make it at least competitive? What features does
it have that are already better than most? (I've never used tickets,
although the integrated ticket system was one of my reasons for moving
from Hg to Fossil.)

2) The wiki is not best-in-class.  What are the key features it needs?
(Merging of changes is certainly one that I see.  If multiple people
are working on the train to/from work, you don't want last committer
wins in your wiki.  This is the point of DVCSs.)

../Dave
___
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 code shutting down

[David Mason]

You have a typo in your post:

only projects I use Git on are my own

pretty sure you meant Fossil in that phrase.

On 13 March 2015 at 08:40, Graeme Pietersz gra...@pietersz.net wrote:


 On 13/03/15 08:17, jungle Boogie wrote:

 Yes, I'm being optimistic about the userbase but we must agree Fossil
 to much easier and friendlier to use.


 Not always. My reply to this turned out to be rather long and a bit of rant,
 so I turned it into a blog post. I hope its not spammy to post a link here
 rather than paste it into an email:
 http://pietersz.co.uk/2015/03/fossil-vs-git

 The short version is, Fossil is easier to use than Git, but it is not easier
 to use than Github.

 ___
 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 fix parallel timeline

[David Mason]

Thanks Tontyna!

I was going to do what you tried, today, but I really appreciate you
confirming it.

It is certainly possible that the students would do a fossil rebuild
if fossil told them to.  The odds of 20 of them doing that if not told
are very low.

../Dave

On 12 March 2015 at 06:40, Tontyna tont...@ultrareal.de wrote:
 Am 11.03.2015 um 18:48 schrieb David Mason:

 The problem was that the version of fossil that apt-get used was
 version 1.27 (I think... maybe 1.29) and I created the fossils with
 1.30[a507dc7cf5] (and use 1.30[cf49528e5c] to look at them).  This is
 the resource page I point them at:


 Can't imagine how your students were able to work with 1.27 on a repository
 created with 1.30 without doing a fossil rebuild

 With 1.29 I'm not even able to open the 1.30 repo.
 With 1.27 I can open the cloned repo but cannot add files.

 Managed to reproduce your corrupted timeline:

 1. Created a repo with Fossil 1.30
 2. Switched to Fossil 1.27
 3. clone/open worked without warning
BTW: open produced a _FOSSIL_ but the local reposirory was empty,
i.e no checked-out files at all
 4. created a new file
 5. `fossil add` warned me about the wrong schema version
 6. did what I was told: `fossil rebuild`
 7. Now `add .` worked fine
 8. `commit` warned me about autosync not working
I ignored that an continued.
 9. fossil ui/timeline -- see attached picture


 ___
 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 fix parallel timeline

[David Mason]

The repository provided to the students *did* have commits:
.fossil-settings with 4+ files and 6 directories with .hold files in
them.  But maybe what you're saying is that something post-1.27 to
support that caused other problems.

../Dave

On 12 March 2015 at 10:34, Richard Hipp d...@sqlite.org wrote:
 On 3/12/15, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 Much better, preventing the problem all together: create the
 repository with Fossil 1.27 to begin with. Fossil 1.30 had
 bugs which ill-treat repositories without any commits. Those
 were fixed in Fossil 1.30.


 Just to be clear:  Those changes that allow one to create a repo that
 has no commits - they are going to be backed out just as soon as I get
 the opportunity.
 --
 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] How to fix parallel timeline

[David Mason]

No I copied the script that creates the fossils directly into that
email, and apart from the warning in red, the instructions to students
are unchanged.  The odd student might do something different, but most
will have done only and exactly what the instructions say.

../Dave

On 12 March 2015 at 13:25, Andy Bradford amb-fos...@bradfords.org wrote:
 Thus said Tontyna on Thu, 12 Mar 2015 11:40:32 +0100:

 1. Created a repo with Fossil 1.30
 2. Switched to Fossil 1.27
 3. clone/open worked without warning
 BTW: open produced a _FOSSIL_ but the local reposirory was empty,
 i.e no checked-out files at all

 According  to David's  instructions[1], there  were files  added to  the
 repository before it was made available for cloning to the students...

 Does this still happen if you add files prior to cloning?

 I suppose it's  possible that there are some missing  steps from David's
 instructions?

 [1] 
 http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19480.html

 Thanks,

 Andy
 --
 TAI64 timestamp: 40005501cc3f
 ___
 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] How to fix parallel timeline

[David Mason]

I have several students who, through some problem while cloning the
fossil I created for them, created a parallel timeline. (see
screenshot)

I want to merge them, but fossil merge says there's no head to merge.
The commits by the student are on the right and are not tagged as
trunk, but tagging them as such doesn't seem to help.  Using
--baseline in merge didn't help either.

Any help to merge these timeline much appreciated.

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