broke my .hgsubstate file

[Julius Ziegler]

Hello,

I somehow broke my .hgsubstate file. For the last commit it shows this
diff:

-a74fa9fd8a84971528ec1cfabf79f31232bc5b95 raw_extract
-1761c8cf18b83d501e1dc5fc08b5d017406afbcd record_button
+ raw_extract
+7bd38916165ab1f19392ba38e6c8d8691248cdec record_button

What does the empty revision for subrepo raw_extract mean? I cannot
update to this bad revision, the error

00changelog.i@: ambiguous identifier

comes up. I managed to "branch around" this bad commit, but it is
annoying that I cannot update to the bad commit for the purpose of
pruning the bad branch.

As always, it is kind of hard for me to retrace how I got into this
situation (that diff is not helping me either)!

Any ideas what went wrong, or how I can fix this?

Thanks!

Julius

_______________________________________________
Mercurial mailing list
Merc...@selenic.com
http://selenic.com/mailman/listinfo/mercurial

[Mads Kiilerich]

On 01/09/2012 05:17 PM, Julius Ziegler wrote:
> Hello,
>
> I somehow broke my .hgsubstate file. For the last commit it shows this
> diff:
>
> -a74fa9fd8a84971528ec1cfabf79f31232bc5b95 raw_extract
> -1761c8cf18b83d501e1dc5fc08b5d017406afbcd record_button
> + raw_extract
> +7bd38916165ab1f19392ba38e6c8d8691248cdec record_button
>
> What does the empty revision for subrepo raw_extract mean? I cannot
> update to this bad revision, the error
>
> 00changelog.i@: ambiguous identifier
>
> comes up. I managed to "branch around" this bad commit, but it is
> annoying that I cannot update to the bad commit for the purpose of
> pruning the bad branch.
>
> As always, it is kind of hard for me to retrace how I got into this
> situation (that diff is not helping me either)!
>
> Any ideas what went wrong, or how I can fix this?

I guess you used an old Mercurial with a bug that now has been fixed?

Revisions with the bad .hgsubstate will however remain poisonous
forever, unless you do some kind of tricky surgery to remove it.

/Mads

[Julius Ziegler]

On Mon, 2012-01-09 at 17:45 +0100, Mads Kiilerich wrote:
> On 01/09/2012 05:17 PM, Julius Ziegler wrote:
> > Hello,
> >
> > I somehow broke my .hgsubstate file. For the last commit it shows this
> > diff:
> >
> > -a74fa9fd8a84971528ec1cfabf79f31232bc5b95 raw_extract
> > -1761c8cf18b83d501e1dc5fc08b5d017406afbcd record_button
> > + raw_extract
> > +7bd38916165ab1f19392ba38e6c8d8691248cdec record_button
> >
> > What does the empty revision for subrepo raw_extract mean? I cannot
> > update to this bad revision, the error
> >
> > 00changelog.i@: ambiguous identifier
> >
> > comes up. I managed to "branch around" this bad commit, but it is
> > annoying that I cannot update to the bad commit for the purpose of
> > pruning the bad branch.
> >
> > As always, it is kind of hard for me to retrace how I got into this
> > situation (that diff is not helping me either)!
> >
> > Any ideas what went wrong, or how I can fix this?
>
> I guess you used an old Mercurial with a bug that now has been fixed?

Thanks for your reply Mads,

involved were these mercurial versions (I was using two working copies
on different Linuxes, and a "canonic" repository on a file server):

1.6.3 (copy 1)
1.7.5 (copy 2)
2.0.1 (file server)

do you deem any of these buggy?

Anyway, I found out that the problem started when I enabled this in
my .hg/hgrc:

[ui]
commitsubrepos=no

It is supposed to suppress recursive commits of subrepos. However, in my
case it caused exactly that problem, i.e. creating "empty" revisions
instead of just not touching the revision (which is the behaviour I had
expected).

Can someone confirm that this really is a bug and not a feature?

Thanks!
Julius

[Mads Kiilerich]

On 01/09/2012 06:25 PM, Julius Ziegler wrote:
> On Mon, 2012-01-09 at 17:45 +0100, Mads Kiilerich wrote:
>> On 01/09/2012 05:17 PM, Julius Ziegler wrote:
>>> Hello,
>>>
>>> I somehow broke my .hgsubstate file. For the last commit it shows this
>>> diff:
>>>
>>> -a74fa9fd8a84971528ec1cfabf79f31232bc5b95 raw_extract
>>> -1761c8cf18b83d501e1dc5fc08b5d017406afbcd record_button
>>> + raw_extract
>>> +7bd38916165ab1f19392ba38e6c8d8691248cdec record_button
>>>
>>> What does the empty revision for subrepo raw_extract mean? I cannot
>>> update to this bad revision, the error
>>>
>>> 00changelog.i@: ambiguous identifier
>>>
>>> comes up. I managed to "branch around" this bad commit, but it is
>>> annoying that I cannot update to the bad commit for the purpose of
>>> pruning the bad branch.
>>>
>>> As always, it is kind of hard for me to retrace how I got into this
>>> situation (that diff is not helping me either)!
>>>
>>> Any ideas what went wrong, or how I can fix this?
>>
>> I guess you used an old Mercurial with a bug that now has been fixed?
>
> Thanks for your reply Mads,
>
> involved were these mercurial versions (I was using two working copies
> on different Linuxes, and a "canonic" repository on a file server):

(I wouldn't recommend using a shared repo on a file server. Any client
will be able to mess anything up. A proper shared server setup will
ensure that repo history is append only.)

> 1.6.3 (copy 1)
> 1.7.5 (copy 2)
> 2.0.1 (file server)
>
> do you deem any of these buggy?

All software is buggy, and the latest version will always include most
bug fixes (and an unknown number of new unfixed bugs) ;-)

Subrepos has been very immature for a long time, so I would avoid using
these 1.x versions when subrepos are involved. Using the latest version
is the best way to find out if it has been fixed or would have to be
fixed in the next version.

> Anyway, I found out that the problem started when I enabled this in
> my .hg/hgrc:
>
> [ui]
> commitsubrepos=no

I doubt that is related - I strongly suspect that any apparent
correlation must be a coincidence.

The problem started exactly when the incorrect .hgsubstate was
introduced. What hg version was used there?

Can you reproduce that Mercurial introduces this incorrect .hgsubstate
entry when committing on top of a correct .hgsubstate?

Are you using any extensions?

[Julius Ziegler]

What do you mean by a proper shared server? hg serve? We are
pushing/pulling via a ssh:// url. We do need an ssh'ish authentication
stage and encryption, an without looking into it to much, this seemed to
be the easiest way.

> > 1.6.3 (copy 1)
> > 1.7.5 (copy 2)
> > 2.0.1 (file server)
> >
> > do you deem any of these buggy?
>
> All software is buggy, and the latest version will always include most
> bug fixes (and an unknown number of new unfixed bugs) ;-)
>
> Subrepos has been very immature for a long time, so I would avoid using
> these 1.x versions when subrepos are involved. Using the latest version
> is the best way to find out if it has been fixed or would have to be
> fixed in the next version.
>
> > Anyway, I found out that the problem started when I enabled this in
> > my .hg/hgrc:
> >
> > [ui]
> > commitsubrepos=no
>
> I doubt that is related - I strongly suspect that any apparent
> correlation must be a coincidence.

I doubt it now, too, since this option has only been introduced in
version 1.8.

> The problem started exactly when the incorrect .hgsubstate was
> introduced. What hg version was used there?

I must have introduced in on 1.6.3 or 1.7.5, since I definitely was not
messing around with my remote.

> Can you reproduce that Mercurial introduces this incorrect .hgsubstate
> entry when committing on top of a correct .hgsubstate?

I cannot reproduce it on a local copy, and this makes me think that this
is somehow introduced via the remote (I do not want to try to reproduce
this, because I do not want to screw up my remote).

Maybe I will try to setup a "sandbox"-remote tomorrow and try to
reproduce it, but for today I have reached my frustration threshold :-)

> Are you using any extensions?

No!

> /Mads

Thanks again for your comments, Mads!

Best,
Julius

[Matt Mackall]

On Mon, 2012-01-09 at 20:27 +0100, Julius Ziegler wrote:
> What do you mean by a proper shared server? hg serve? We are
> pushing/pulling via a ssh:// url. We do need an ssh'ish authentication
> stage and encryption, an without looking into it to much, this seemed to
> be the easiest way.
>
> > > 1.6.3 (copy 1)
> > > 1.7.5 (copy 2)
> > > 2.0.1 (file server)

I think Mads was responding to "file server". A real file server (ie
NFS, CIFS) is indeed a less robust mode of operation.

I put some info about doing 'manual checkouts' on the wiki just now that
might be useful to you:

http://mercurial.selenic.com/wiki/ManualCheckout

--
Mathematics is the supreme nostalgia of our time.

[Julius Ziegler]

> I put some info about doing 'manual checkouts' on the wiki just now that
> might be useful to you:
>
> http://mercurial.selenic.com/wiki/ManualCheckout
>

Hi Matt,

I just wanted to let you know that a "manual checkout" worked perfectly
for patching up my broken .hgsubstate file, an I was able to at least
close the bad branch!

Best regards,
Julius