Having more than three phases (was RFC: Phase UI (revset, phase command and others))

[Laurens Holst]

Op 3-1-2012 11:55, Laurens Holst schreef:
> Op 03-01-12 10:38, Pierre-Yves David schreef:
>> On Thu, Dec 29, 2011 at 01:22:51PM -0600, Matt Mackall wrote:
>>> Not really sure why this is necessary. After all, we only share 
>>> public and draft, so only the public/draft boundary every needs to 
>>> be exposed remotely. 
>> Exchanging secret boundary are actually useful to detect secret 
>> changeset that
>> exist elsewhere. The current behavior when such (not so) secret 
>> changeset are
>> detect is to set them in draft phase (at least).
>
> I think the secret boundary should not be exchanged. By sharing you do 
> give away some information, that at that point in time a changeset 
> with that ID existed. Secret should mean secret, and you shouldn’t 
> share this kind of information.
>
> E.g. say I made something during company time, but wanted to keep it 
> secret so I can push it when I’m at home and (technically) keep the 
> copyrights on it. If my boss can then prove I made the changeset 
> during work hours by showing server logs that contain the changeset 
> ID, they’ve got a pretty strong case.
>
> I’ve seen people publicly blogging changeset IDs to prove that a 
> change was made without disclosing the contents of the changeset (to 
> defend against possible patent claims with prior art), so this kind of 
> use is not unrealistic.

Another more serious problem with that:

If I have made a copy of a local repository, and then pull from the 
original, the secret changesets would be made public. That’s unexpected 
and undesirable, it would be too easy to accidentally publish secret 
changesets.

~Laurens

-- 
~~ Ushiko-san! Kimi wa doushite, Ushiko-san nan da!! ~~
Laurens Holst, developer, Utrecht, the Netherlands
Website: www.grauw.nl. Working @ www.roughcookie.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4332 bytes
Desc: S/MIME cryptografische ondertekening
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120103/88d1795f/attachment.bin>