[darcs-devel] darcs and darcs hub (Re: obliterated patches)

Ben Franksen ben.franksen at online.de
Mon Mar 16 00:07:33 UTC 2015

Simon Michael wrote:
> On 3/12/15 2:15 PM, Ben Franksen wrote:
>> What advantages would this give me, compared to pushing/pulling/sending
>> from/to the original repos?
> Here's how I always thought of it (I don't know if they seem like
> advantages to you):
> 1. a browsable and linkable web UI, facilitating code and patch
> review/discussion/searching

I may be wrong but I guess this would mean a rather different work-flow than 
what we currently have?

> 2. more visibility and clarity on the various darcs branches and their
> purpose


> 3. convenient forking/tracking/merging of everybody's dev branches, and
> a more efficient web-based github-style workflow

Is this (web-based github-style) workflow really more effective? I am not 
saying it isn't, but I'd like to have a clearer view about what this 
workflow would entail.

My current workflow (simplified) is:

Go to my clone of screened. Darcs pull. Hack away. Record. Compile, test. 
Darcs send. Now I can see the patch in the tracker and a mail is sent to the 
darcs-dev list. If I find that the patch makes sense, I can push it to the 
screened repo. In any case, discussion about the patch takes place in the 
tracker, mostly, though the mailing list is indispensable at least as 
notifier about who said what regarding which patch or bug.

This already is web-based, in a way, via roundup as patch tracker.

What is the typical workflow with darcshub?

> 4. concentration of darcs developers and users on a single
> highly-visible hub running the latest darcs and darcsden code, thereby
> promoting a virtuous cycle of dogfooding and improvement

While this sounds like a good idea, I have doubts that moving to darcshub 
would allow us to keep using the tools we do now. Would using darcshub mean 
we no longer do 'darcs send' but instead use the github model of pull-

Currently the mailing list is well integrated with the repos and with 
roundup for tracking bugs and patches. How can we keep that running if the 
repos move over to darcshub?

> Regarding 2 and 3, in fact I hoped the mirroring would be temporary, and
> the master repos would move to darcs hub at some point. I also thought
> that the official darcs repos would be immutable (no rewriting of
> history), and so their hub mirrors would be also.

I guess this is a chicken-and-egg sort of problem. I fear there is little 
incentive for an individual developer to use darcshub until we move the 
repos there committed to it as our development platform (and integrated it 
into our workflow).

>>> I’ve reduced the mirroring
>>> period from 15m to 2h, how’s that ?
>> I think it would be better to record the time when patches are applied in
>> upstream and wait 2 hours before pulling them. That means you can probe
>> as often as you want, but should not apply until after the "grace period"
>> (I guess 2 hours is fine.
>> A more radical solution would be to auto-obliterate things in the mirrors
>> that disappear upstream. That would mean you can stay in however close a
>> sync as you want.
> Indeed, or we could update the mirrors much less frequently, or remove
> them. Or now that I think of it, you darcs devs can and should do
> whatever obliterating you want on darcs hub, using the ssh or web
> interface. Eg currently Ganesh, Guillaume and Owen have member access to
> darcs-screened and I believe can obliterate there. Also IIRC Ganesh and
> Guillaume have the password for the darcs user, so can manage these
> repos and their access. I can adjust or turn off the cron jobs that do
> the pulling as y'all tell me.

I would prefer to have one place to go when editing a repo, not two or 
three. So IMO either we move our main repos to darcshub or we do automatic 
mirroring, including obliterates. Everything else is just maintenance 

"Make it so they have to reboot after every typo." ― Scott Adams

More information about the darcs-devel mailing list