Limiting which csets get shared with peers?

[Tim Delaney]

On 24 March 2014 05:54, Dov Feldstern <dovdevel at gmail.com> wrote:

> 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...
>

What if hg push and hg pull gained a --secret option? That would allow
keeping the changesets you don't generally want shared as secret, but allow
transferring them between your own clones that presumably you have complete
control over. Include an option in hgrc to allow pushing/pulling of secret
changesets (off by default).

You could combine this with authentication e.g. to ensure that only you can
push secret changesets to a particular clone.

This would work perfectly for my own use cases:

1. Pushing work-in-progress to another clone (e.g. on another machine) to
build and run unit tests;

2. Working in a secret branch so that I can rebase, collapse, etc to get
the clean changesets I want, whilst still being able to back up my work in
progress by pushing to another clone;

3. Having a "code review" clone which can take other developers' work in
progress, review, pair with the author to make changes, etc and not have it
dirty up the clean history in the main repo (because the changesets are
secret).

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140324/7d5ee4ce/attachment.html>