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