Spot of bother with hidden changesets in subrepo

John Jefferies j.jefferies at ntlworld.com
Tue Nov 19 09:19:06 CST 2013


On 19/11/2013 13:34, John Jefferies wrote:
>
> I've been using the evolve extension in a project using subrepos and 
> got into problems with the parent repo referring to a hidden changeset 
> in a subrepo.
>
> - I amended the subrepo with commit --amend, which makes a new 
> changeset and marks the original as hidden.
> - Then I attempted to update the parent repo to a changeset N that 
> referred to the now hidden subrepo change, and found I couldn't.
>
> What I ended up doing to fix it was to update to the change (N-1) in 
> the parent and restored the Nth change with export/import, and 
> updating the subrepo to the amended change.
>
> I realise there are dragons when doing history changing operations on 
> subrepos, but are there any safe methods that could be recommended. Or 
> would the advice simply be "don't do history changing on subrepos".


FTR. I've worked out that I could have rescued myself by unhiding the 
hidden changeset in the subrepo by simply updating to it:
         hg up -r X --hidden

which would have allowed me to update the parent repo to changeset N. 
Then I could have updated the subrepo to the amended version, and 
finally amended the commit in the parent (which is what I was trying to do).


At the end of the day, I'm pleased I've found a way to make what I was 
wanted to work. It would be nicer though, if a requested update that 
referred to a hidden changeset in a subrepo told you that it was hidden, 
rather than simply giving an error:
         "abort: unknown revision 
'e4a5ec764b58d8300752449386e500611e56a64e'!"

and leaving you with a dirty repo that has to be cleared up.

Thanks

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20131119/72ce48db/attachment.html>


More information about the Mercurial mailing list