[darcs-users] Darcsforge update (from: Comercial hosting and branching)

Max Battcher me at worldmaker.net
Sun Mar 1 22:17:24 UTC 2009


Gour wrote:
>>>>>> "Max" == Max Battcher <me at worldmaker.net> 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


More information about the darcs-users mailing list