sgbeal

47 ms·

721.
by sgbeal 11y ago
> Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history. No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multi
722.
by sgbeal 12y ago
i suspect he's talking about the general aesthetics of the UI. None of the developers (and i'm allowed to say this, being one of them ;) has demonstrated a particular gift for making apps look really pretty.
723.
by sgbeal 12y ago
Separation of tickets and VCS: that has been a bit of a stickler in the development of libfossil ( http://fossil.wanderinghorse.net/r/libfossil ). In fossil the ticket system is married to a custom mini-script engine cal
724.
by sgbeal 12y ago
Fossil is not the right job for that - there's a dozen entries in the ML archives explaining why. Short version: it doesn't do file permissions and system users, and many files in /etc require specific perms and owners.
725.
by sgbeal 12y ago
"...complaining about the conflict resolution process..." In Fossil? Absurd. i don't know that i have ever, without help from a git professional, successfully resolved a merge conflict in git. In fossil it's trivial.
726.
by sgbeal 12y ago
"...complex sql to remove a spam ticket..." that was very possible the reason for his woes. Do not EVER manually edit the fossil repo db. That's like hex-editing an MS Word Doc.
727.
by sgbeal 12y ago
Fossil was initially written for that very purpose - to host sqlite. That is still its primary target. The fact that the sqlite project is so heavily used gives fossil a great deal of exposure, and Richard regularly updates the sqlite.org s
728.
by sgbeal 12y ago
FWIW: simply removing records from your repo db (in particular the blob table) _will_ corrupt it. Fossil stores deltas and other metadata which span blobs, and it's not trivial (and in many cases not possible) to separate them post fac
729.
by sgbeal 12y ago
i've been working with/on Fossil since late 2007, and within the Fossil team we are not aware of _any_ loss of data except that caused by "system events" or severe user error (e.g. once i accidentally included a repo db
730.
by sgbeal 13y ago
To their credit, they warned us some months ago (April?) on the list that the InvocationCallback signature and Persistent would change. That was a new step for them - the first time i was warned about breakage before it happened. But withou
731.
by sgbeal 13y ago
Thank you for your kind words. It took me a good long while to get my mind wrapped around the templates well enough to implement it. It was a very incremental process, starting with the basic type conversions and culminating in the function
732.
by sgbeal 13y ago
No worries - i didn't notice the typo. It seems that comment editing expires after a short time, so you've gotta be fast. i tried it, too ;).
733.
by sgbeal 13y ago
PS: @leokun: FWIW, i up-voted you. Your suggestion about the change of tone from frustration to information is something i will definitely keep in mind for the next time (no, there's no sarcasm there!). Unfortunately, i didn't hav
734.
by sgbeal 13y ago
A very heartfelt thank you for your depiction and endorsement. :) PS: i don't always agree with everything i say, either ;)
735.
by sgbeal 13y ago
If i ever commission a biography, i'm coming to you to write it for me ;).
736.
by sgbeal 13y ago
FWIW: your interpretation of my intentions is how i hoped they would come across :).
737.
by sgbeal 13y ago
Thank you, TallGuyShort :). i think i did come across as a bit bitchy, but i tried to stay on topic and removed lots of stuff i wrote simply out of primal frustration :/. i'm only human ;). i thought about it for a couple months b
738.
by sgbeal 13y ago
FWIW, i agree completely that v8 has to serve its primary target, and there was never any illusion that that wasn't Chrome. i'm not mad about them for that. i'm just frustrated at giving up something i put literally thousands
739.
by sgbeal 13y ago
i'm happy to hand over admin access to the repo as soon as someone asks for it. i would really hate to see cvv8 go to waste (IMH (and biased) opinion it's the best binding/conversion lib for v8), but i can't deal with th
740.
by sgbeal 13y ago
That approach doesn't work (without a lot of effort) with templates at the level cvv8 uses them. There are literally thousands of InvocationCallback instances in the cvv8 tree, most of which are bound via the XTo templates, which run t
741.
by sgbeal 13y ago
The problem with NOT documenting PUBLIC APIs is that all behaviour becomes, from the client perspective, undefined. People keep going back to the point of private API docs - private details are private for a reason. Nobody but the v8 devs n
742.
by sgbeal 13y ago
This project is 28 days old: http://fossil.wanderinghorse.net/repos/f2/doxygen/ it is experimental, alpha quality, and developed only by me. It has more public API docs than v8. i cannot for the life of me co
743.
by sgbeal 13y ago
i would say "hubris" rather than "narcissism." My goal was not to change v8 - my goal was to explain to the cvv8/v8-juice users why i cannot afford to expend more energy supporting v8 by making their APIs more acces
744.
by sgbeal 13y ago
The claim that it breaks "all v8 applications" is based on the fact that the v8::InvocationCallback signature (which is used by all client applications who actually embed anything) is now different. It can't NOT be incompatib
745.
by sgbeal 13y ago
Wow... i didn't mean to start waves, which was why i unsubbed from the list within moments :/. i _really_ appreciate all of your support AND critiques (they are not unfair). Now i can't sleep. On a tablet, so won't say m