Gour wrote:
"Max" == Max Battcher <[email protected]> writes:
Max> (As I get closer to getting my own hosting platform together I've
Max> been debating the viability of opening it up to paid private
Max> hosting.
Any news about Darcsforge?
I've got a bunch of good patches I'm sitting on in a local repository
that I should probably publish sooner rather than later... I've been
trying to get it to a deployable point where Repositories and Files
mostly work, and possibly Tags.
Once I get it next deployed I'm debating asking around for interest in
paid, private hosting with it to help me continue to work on it. My
current thoughts are something like $15-$50 per month per project, with
"unlimited" (mostly related) repositories per project (including "user"
repositories) and big/healthy quota caps between levels (possibly with
micro-payments over the quotas). Important features that I see being
Day 1 features: SSL support (you buy the cert, we host it; you can have
all visits of your private project site redirect to the SSL-encrypted
site) and CNAME support (project.yourcompany.com rather than or in
addition to yourcompanyproject.whatevermyhostingsitegetscalled.com).
I'm hopeful that once things get going the prices would probably drop or
the quotas will continually rise. I certainly feel that I would need
some time before I've figured out the economy of scale of the thing; I
certainly don't have major site hosting experience and am not entirely
thrilled to run such a beast by myself, but hopefully it will mostly run
itself or I can spin it off/sell it down the road if it is a successful
venture.
Some details on what I've been working on in what spare time I can spend
on it for those that might be interested:
The big hangup is that I've been slow to finish my File state caching
application. I'm basing it on the modern darcs pristine.hashed cache
(which means that hashed/darcs-2 repositories will be required for file
state information to be useful). Basically the idea is to (hopefully)
quickly "snapshot" a pristine directory, generating interesting HTML
cache files from it (that is, the associated file as highlighted source
code, highlighted darcs annotate view, and if the file is of a useful
markup format (such as reStructuredText) a transformed/marked-up
version). The benefit of mirroring the pristine hashes in the file
caches should be that just as darcs shares pristine files across
multiple repositories so should these caches be usefully shared across a
Darcsforge project.
Sticky issues I'm dealing with right now are how long to archive caches
and how to usefully present to archives to a web visitor; I'm
particularly not fond of the idea of directly using the pristine hashes
in URLs. I'm also wondering about the (probably rare) likelihood of
intra-project hash conflicts and worse (and probably less rare)
likelihood of inter-project hash conflicts. Particularly because there
doesn't seem an easy way to distinguish hash conflicts other than
possibly differences in file size (you could try to use names, but darcs
supports file moves and the pristine files themselves do not anymore
encode filenames). Related to that I've been debating how best to define
per-file overrides, because there is a many pristine objects to one
"file" relationship it would be somewhat annoying to have to make
changes for each and every pristine object cached for a file, but to
some extent it will be the pristine objects that are "real" and the
file's that a virtual collections of relations to pristine objects. (The
big, probably most common example is the need to manually set file's
mime-type/extension for correct/best source code highlighting.)
More interesting work: I've spent some time documenting what I need to
support darcs send to an HTTP POST (and consequently, a decent portion
of what is needed for darcs send to an email address), and I'm looking
forward to writing some pretty cool patch bundle handling code. I've
got some cool ideas for it, and I think its a pretty important key piece
of my platform as I'm expecting darcs send to be the primary (and
probably only) means to apply new patches to Darcsforge-based
repositories. (I think that a simple HTTP POST address and/or email
address crawler is a lot easier to maintain with regards to security and
scalability than SSH jails and to be honest I'm not interested in
setting up SSH jails.) It's also something that I think is hugely
important as a key difference in the darcs "way of life" with comparison
to other DVCSes. Look at the way darcs itself is developed with nearly
every patch expected to be sent with darcs send to the appropriate
mailing address and bounced back to the mailing list if it doesn't meet
tests or is from an unauthenticated user. That's the basic workflow
that I'm interested in emulating: darcs send a patch bundle to your
Darcsforge-tracked repository; if you don't sign it or it fails tests it
gets "published" to the bundle tracker on the website so that comments
can be made on it or a replacement/follow-up can be sent with an
appropriate --in-reply-to. It is the exact same tools and workflow for
new developers on your project; no public versus private repository
paths just public HTTP-only repositories and a darcs send POST address
(and possibly/probably email address as well) for all.
Wow, that "brief" status report turned out longer than I thought...
Hopefully there might be something of interest in my ruminations above.
--
--Max Battcher--
http://worldmaker.net
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
