Limiting which csets get shared with peers?

Dov Feldstern dovdevel at gmail.com
Sun Mar 23 13:54:10 CDT 2014


Hi!

This is in continuation of the discussion last month about "sharing
secrets with friends" [1], the upshot of which was that a better
approach would be not to share secrets, but rather to optionally limit
the sharing of drafts (or, more generally, arbitrary revsets, such as
proprietary branches?) with certain peers.

I've been playing around with a few different approaches for achieving
this, but I don't like any of the results, and I would appreciate some
ideas about how to go about this...

To recap: my initial goal is to be able to specify that certain
changesets should not be shared (at all); where "certain changesets"
can either mean just "drafts", hardcoded; or possibly be expanded to
include arbitrary revsets. Note that I would much prefer not to merely
stop an exchange if it would share csets which shouldn't be shared;
but rather to let the exchange to proceed, and just not include those
csets (just like secrets are currently handled).

One approach I tried was inspired by Martin's answer at [2]: the idea
is to turn all drafts into secrets before sharing, and then turn them
back to drafts after the sharing is done. The advantage of this
approach is that there is no need to touch any of the core
functionality -- we already know not to share secrets. The first idea
was to use the "preoutgoing" hook for this, but it turns out that it
is often (always?) invoked *after* already having started to determine
what can or cannot be shared (for example, when cloning, the hook is
invoked *after* checking whether there are any secret or hidden
changesets, and, if not, deciding to use the copy method of cloning,
which clones *everything*; so changing the drafts to secrets after
that is too late -- they *do* become secret, but get cloned anyway).
So then I tried using the "pre-commnd" hooks instead. That works, but
requires parsing arguments, knowing about default paths, etc., and it
sort of seems a shame to have to work at such a high level that we
can't benefit from the argument parsing which is about to happen soon
anyway... But perhaps this is still a viable approach.

A completely different idea is to somehow make use of the repoview
filters mechanism. On the face of it, this appears to be quite close
to what I am trying to achieve -- a "view" of the repo which doesn't
necessarily expose all changesets. However, filters are not currently
used as the sole means of restricting sharing, and there are still
plenty of places where the code checks specifically for secrets or for
hidden csets, rather than using the corresponding filters. Also, the
filters in repoview are expected to be subsets of more inclusive
filters, so this would not work very well with arbitrary revsets. So
I'm not sure if this could be used for my purposes here.

Finally, I've also tried just modifying the code directly -- not
worrying for the moment about making this extensible or backwards
compatible or anything -- but this just seems to involve many
different places in the code, something which I was hoping could be
avoided...

So, any ideas about how how to go about this?

Thanks!
Dov

[1] http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/66347
[2] http://stackoverflow.com/questions/9637984/mercurial-include-secret-changesets-in-bundle/9645786#9645786


More information about the Mercurial-devel mailing list