Hiding old data from new users

[Steve - Gadget Barnes]

On 20/10/2016 15:32, Augie Fackler wrote:
> On Thu, Oct 20, 2016 at 10:08:27AM -0400, Bob Eby wrote:
>> Hi Mercurial experts,
>>
>> This may sound strange but we've checked a secret into one of our
>> repositories and now we want to share pretty much everything but that
>> with an outside consultant.
>>
>> I tried creating a partial repo of a "cleaned" branch with:
>>
>> hg clone -b
>>
>> Problem is, this included all the parents which pulled in the old
>> default branch that had the secret.
>>
>> Aside from copying a current checked out file set into a brand
>> spanking new repository, is there a way to create a partial repository
>> suitable for intermediate push/pull upstream from client repositories
>> that can act as a "secrecy buffer" against some old default file?
>>
>> I'd like to give them some but not all of the repo history, or does it
>> not even make sense to want to share that extra history?
> 
> This isn't something we can currently do. Right now, your options (as
> far as I can remember) are:
> 
> 1) Use 'hg convert' to make a sanitized version of the repository
> history. This will change all the revision identifiers and make
> exchanging revisions between the repositories hard or impossible.
> 
> 2) Wait for something like narrowhg or sparse to finalize and use
> that. I can't say that I'd recommend either of them now, as they're
> still fairly immature and probably don't let you do the kind of ACL
> enforcement you likely need.
> 
> Sorry I don't have a better answer. :/
> 
>>
>> Thanks for any and all input,
>> Robert Eby

Assuming that the "secret" is no longer used or is of only historic
interest, I would suggest the following process:

 1. Add a prominent notice to the repository that on a specific date and
time the repository will be undergoing a major change and that all work
must be committed and pushed by that time. Ideally make the date a
little time in the future and a holiday, weekend, some time when nobody
is likely to be working. Also notify by email, notices on the board,
every method that you can, all of your users of the upcoming deadline.
Possibly even requiring from each user an acceptance of the event.
 2. Use the convert utility to create a new, 'sanitised', repository and
place this on your internal 'master' servers with a different URL or
Location to the original.

 3. Archive the current, (including secret), repository to multiple
secure off=line storage locations, assuming that you need to keep this
somewhere.
 4. Check into the current repository a prominent notice that the
repository has been relocated to the new location, mark the rest of the
content as deleted, mark the entire repository as lock required and push
this to the original location.
 5. Leave that on the original URL/servers for long enough that the vast
majority of your contributors will get it.
 6. Send out a notice of the change as well and ask them, once they have
checked out the new repository to delete the old from their machines.
 7. Deal with the people, (nearly wrote a ruder description), who
"didn't get notified" that will almost certainly emerge by getting them
to manually merge their changes into a checkout of the new repository.
 8. Make absurd and anatomically impossible threats to the one who
mentions histedit.



-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.