[darcs-devel] How we handle the screened repo

[Ganesh Sittampalam]

On 21/11/2018 09:48, Ben Franksen wrote:
> Am 18.11.18 um 15:37 schrieb Ganesh Sittampalam:
>> A rollback is fine, it's one of the risks we accepted by having
>> the screened/reviewed setup.
> 
> Perhaps we should rethink this setup, or rather, the way we handle it.
> 
> The way we do this now is a bit schizophrenic: even if a patch is
> rejected we will push it (and its rollback) to reviewed.

One of the reasons for rolling back in general is that some other patch
might have been added in the meantime that depends on the rejected
patch, so just obliterating wouldn't be possible. That was really the
main premise of setting up the screened repo - patches weren't getting
reviewed for a long time, and in the meantime other people were making
conflicting changes.

> I see nothing wrong with obliterating or amending patches in a shared
> repo, especially since we are such a small team. It makes no sense to
> mirror screened on hub.darcs any longer if we do that, but otherwise I
> don't see any problem with such a convention. What could go wrong? You
> suddenly have a patch in your local clone that isn't in upstream. Big
> surprise! So what? I never 'push -a' to darcs-unstable at darcs.net,
> instead carefully check each patch to make sure this is really what I
> want to push. I would notice immediately if Darcs offered me a patch I
> didn't author and assume it got obliterated in the upstream repo. And if
> someone really is that careless chances are good that this will conflict
> and thus be rejected. And even if not, we can just obliterate it again.

I don't feel too strongly either way. Changing state in a shared repo
introduces some overhead for users of that repo, but as you say there
aren't that many of us.

> It would help if we had a --force option for push that obliterates
> patches in the remote that conflict (after presenting them to the user
> and making sure this is really what they want to do etc etc), so we
> don't have to log in via ssh and obliterate patches manually. The remote
> obliterate should have an automatic '-O' option so that nothing gets lost.

This feels a bit fragile to rely on, as "this patch has a textual
conflict" isn't the same as "this patch was rejected". Some patches will
only have semantic conflicts, or none at all but we still don't want
them. If the idea is to catch situations where a patch has been
accidentally pushed to screened, I think it'd be better to fail and then
get the user to manually fix up screened.

Ganesh