[PATCH 3 of 6] phases: add basic pushkey support

Pierre-Yves David pierre-yves.david at logilab.fr
Thu Dec 15 09:43:26 CST 2011


On Thu, Dec 15, 2011 at 04:10:32PM +0100, Laurens Holst wrote:
> Op 15-12-11 15:40, Dominik Psenner schreef:
> >>>Case 3: repo A is active and publishing (questionable user case)
> >>I have another use case for this,
> >>
> >>Sometimes when I don't have access to my development environment and I
> >>need to fix something (especially when it's urgent), I SSH directly to
> >>my server to fix it there and commit the fix.
> >>
> >>As the commit appears in the public repository, I think it should be
> >>marked as public.
> >It's marked once someone pulls from the repository, doesn't it?
> >
> 
> See subcase 3b in Matt’s mail (should’ve quoted it).
> 
> What I wrote above is similar to that but hopefully a more realistic
> example.
> 
> The difference is that the local use of the publishing repository is
> only incidental, so the repository is clearly not misconfigured
> (although perhaps misused, but don’t we all sometimes).

It is seen as public by any client pushing or pulling on this repo. Therefor
such commit should not stay draft on the server for a long time. (any
pull//push cycle will mark is public).

The only case you can get real issue from this behavior is if you make active
history rewriting on your public other passive server. This is obviously a bad
idea! Anyway, you have two options to prevent such mess if you are really
afraid of it.

A) Using the strict public option (as discussed at the end of the mail) would
   prevent your coworker to misuse such public repo.

B) Using secret changeset will prevent other people to pull changeset you are
   actively working on.

-- 
Pierre-Yves David

http://www.logilab.fr/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20111215/e502ae7f/attachment.pgp>


More information about the Mercurial-devel mailing list