Sorry: s/collection, UDFs/collection of UDFs/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
But those intricate algorithms for deduplication, hash chaining, and
merging, those would come
in handy across the board.
A bit about drift: it's a natural outcome of parallel codebases, even with
something like a common
standard. Without that, it's guaranteed, unless one of the forks doesn't
On 13.03.2015 21:55, Richard Hipp wrote:
On 3/13/15, Warren Young w...@etr-usa.com wrote:
Few organizations have the problem that the full power of Git solves.
And yet many organizations voluntarily take on the problems that come
with using Git. Weird.
Аnyway, Github won that game. In
Hi Ashwin,
On 12.12.2014 02:58, Ashwin Hirschi wrote:
Are you trying to build on Unix/Mac or on Windows? Did you follow the
instructions at
https://www.fossil-scm.org/fossil/doc/tip/www/build.wiki ?
I'm unable to build or debug Fossil because I've just switched to a new
(Windows) machine.
On 11.01.2014 20:44, Joseph R. Justice wrote:
On Sat, Jan 11, 2014 at 1:24 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
2014/1/4 James Turner ja...@calminferno.net:
I *still* haven't sent out that message / warning yet, but I'm getting
closer. Have info now for:
CentOS (and Scientific
On 29.09.2012 15:48, Barak A. Pearlmutter wrote:
Please send a proper URL for bug reports against the Debian/Ubuntu packages.
Sure. You can look at
http://bugs.debian.org/fossil
http://packages.qa.debian.org/f/fossil.html
Although bugs can be submitted by manually composing email, the
[Forwarding the thread to the Debian/Ubuntu Fossil maintainer]
Hi Barak,
Please send a proper URL for bug reports against the Debian/Ubuntu packages.
As you can see from this beautiful thread, our list seriously lacks the
maintainers voice ;-)
Kind Regards,
Alek
On 26.09.2012 16:14, Scott
On 04.11.2011 11:45, Stephan Beal wrote:
@Everyone else: please correct that if it's wrong.
No need of correction, I use fossil this way too:
cat /etc/systemd/system/fossil.service
[Unit]
Description=Fossil Repositories
After=network.target
[Service]
Type=simple
User=fossil
Group=src
Hi Nolan, Stephan,
I think that this is doable for a restricted subclass of usage scenarios
(these conforming workflow style cited by Stephan above + bunch of
other restrictions).
We can benefit the fantastic opportunity of sqlite as fossil artifacts
container - I think that it is possible
On 04.11.2011 21:01, Stephan Beal wrote:
The biggest catch there is binary data, since JSON has no native way of
handing it. However, my current thinking on binary data is this...
from JSON we serve URL paths which, which called by an HTTP client, will
return the raw content (binary or not) for
On 04.11.2011 22:32, Andreas Kupries wrote:
Does hg have something git's rebase and other history rewriting
operations ?
Yes - hg supports all of them and more (via various bundled [1] and
endless count of community extensions), but as you know, history
rewriting kills any repo/repo
On 27.10.2011 02:15, Caleb Gray wrote:
@ Stephan Beal:
I see the appeal in creating a separate HTML application. I will take
this approach, and will see how everyone feels about having installable
skins in Fossil: shipping it with only the Default skin.
+1: Absolutely - optional AJAX
BTW, I just cloned Veracity source using veracity (vv) and realized that
the repo consists of 13 sqlite DBs (WAL mode) + 1 external BLOB file (+
counting number simple sqlite3 files with containing table)
On 19.10.2011 15:39, Lluís Batlle i Rossell wrote:
On Wed, Oct 19, 2011 at 08:18:01AM
13 matches
Mail list logo
