Cannot push changes to svn without a working directory

Create issue
Issue #86 wontfix
Former user created an issue

Not sure if this is expected behavior or not:

{{{ $ hg clone svn+http://... foo $ dir foo # Empty, svn clone doesn't do a checkout $ hg clone foo bar $ dir bar # Populated, hg clone does a checkout $ cd bar

... make changes ...

$ hg commit # Commit changes in bar $ hg push # Push changes to foo $ cd ../foo $ hg log # Changes are visible in the log $ hg push --svn searching for changes no changes found $ hg checkout $ hg push --svn

... changes are pushed to svn ...


Comments (6)

  1. Dan Villiom Podlaski Christiansen

    Personally, I don't like the way push is done, currently. I'd prefer pushing to behave like a regular push, and have the users themselves clean up changes if necessary. Both automatic rebase and the current strategy of replacing pushed changesets seem too risky and complicated to me. I'm not entirely clear on how we'd get rid of rebase, or whether we even could, but I'd like us to be able to push any changeset to Subversion without any destructive operations on the Mercurial side of things.

  2. Augie Fackler repo owner

    You definitely can't get rid of the rebase operation - commit semantics in Subversion are just wholly incompatible. Honestly, it'll take a lot of convincing to make me believe what we're doing isn't the simplest safe option.

    You could get rid of the automatic rebase if you were willing to only ever push a single changeset at a time, but that's completely unacceptable to me.

  3. Augie Fackler repo owner

    I should probably clarify: the reason rebasing is necessary is because svn does an implicit rebase during commit if you're committing against a non-HEAD revision but no files you edited were changed between your wc base rev and HEAD, and there's no way (short of editing every file in every revision, which we obviously can't do) to get svn to not do that.

  4. Former user Account Deleted

    On a related note, has anyone tried working with repos cloned from an hgsubversion repo? Cloning my source svn repo is slow (understandably - it has lots of history), so I've been experimenting with working in multiple repos cloned from a single hgsubversion repo. Unfortunately, things get confusing after a changeset from a clone gets pushed to svn & replaced - from the perspective of the clone, the replaced changeset looks like a branch in the DAG. Anyone have any strategies for dealing with this?

    In the short-term, I've just given-up on using clones of an hgsubversion repo.

    Many thanks, Tim

  5. Log in to comment