Synchronization loss using strip

Create issue
Issue #254 new
Jason Harris created an issue

In starting the testing of hgsubversion for integration with MacHg I came across the following issue.

If you clone a svn repository using hgsubversion and then maybe make some changes, then realize you have messed up or done something screwy, its nice to be able to go backwards. Thus strip to some certain point and then pull again.

But this doesn't seem to work.

{{{ Last login: Tue Feb 1 02:27:30 on ttys003 [Bolt:~] ⌘ cd test

[Bolt:~/test] ⌘ hg clone http://django-tagging.googlecode.com/svn/trunk/ mytest [r1] None: Initial directory structure. [r6] jonathan.buchanan: Initial import
[r7] jonathan.buchanan: Moved template tag module to avoid comflicts
[r8] jonathan.buchanan: Added verbose_name properties to model inner Meta classes
... [r183] brosner: New version handling
[r185] brosner: Doh — forgot to update this file before releasing
pulled 142 revisions
updating to branch default 24 files updated, 0 files merged, 0 files removed, 0 files unresolved

[Bolt:~/test] ⌘ cd mytest

[Bolt:~/test/mytest] mytest 141(141) ⌘ hg strip 138 4 files updated, 0 files merged, 0 files removed, 0 files unresolved saved backup bundle to /Users/jason/test/mytest/.hg/strip-backup/e94ddc4b0507-backup.hg

[Bolt:~/test/mytest] mytest 137(137) ⌘ hg pull pulling from http://django-tagging.googlecode.com/svn/trunk/ no changes found

[Bolt:~/test/mytest] mytest 137(137) ⌘ }}}

Have I configured something wrong?

Ahhh... Actually I just dug a little more through the documentation and found {{{hg svn rebuildmeta}}} Which re-establishes the synchronization:

{{{ [Bolt:~/test/mytest] mytest 137(137) ⌘ hg svn rebuildmeta http://django-tagging.googlecode.com/svn/trunk/

[Bolt:~/test/mytest] mytest 137(137) ⌘ hg pull
pulling from http://django-tagging.googlecode.com/svn/trunk/ [r176] brosner: Not even going to touch 0.96 any longer [r177] brosner: Updated CHANGELOG with Django 1.2 fix
[r183] brosner: New version handling
[r185] brosner: Doh — forgot to update this file before releasing
pulled 4 revisions
(run 'hg update' to get a working copy)

[Bolt:~/test/mytest] mytest 137(141) ⌘ }}}

But shouldn't hgsubversion detect this somehow and do automatic rebuilds when these things are out of sync? eg when calling {{{hg pull}}} You have control and should be able to look at hashes or something to detect that things are missing.

Comments (3)

  1. Augie Fackler repo owner

    Run hg svn rebuildmeta $svnurl after a strip. I'm pretty resistant to making it automatic unless you have some provably-correct low-overhead way of triggering it. I think I could see providing some sort of hint to the user via an abort.

  2. Jason Harris reporter

    I can handle this in MacHg, ie run a rebuildmeta after every history altering operation, but what if the user does something with MQ or something similar from the command line?

    I see two possibilities:

    1. Make all the other history editing operations know about hgsubversion
    2. Have hgsubversion do caching of changeset hashes as follows:

    When you first do the hg clone svnrepo, hgsubversion records the changeset hashes of all the heads (there should be only one). Call this hash svntiphash

    The next time a pull is initiated if svntiphash is not in the hg repository then rebuildmeta is automatically called. After the pull the new svntiphash is recorded.

    And then the next time a pull is initiated, again if svntiphash is not in the hg repository then rebuildmeta is automatically called. And so on...

    This shouldn't be computationally expensive. Thus why would you not do this? After the strip the changesets are really missing and pull should really bring them in...

    But likely you have thought of this already? So what am I missing here?

    Cheers & Thanks, Jas

  3. Augie Fackler repo owner

    If you want to have a discussion about this, move it to the list. I'll miss things here, and others should have the opportunity to participate.

  4. Log in to comment