Issue #271 wontfix

hg svn rebuildmeta prefers default-push to default, is this correct?

Denis Kasak
created an issue

Why does hg svn rebuildmeta prefer default-push to default when both exist? It seems more natural that default should be preferred (since it is used for pulling), at least from the point of my current workflow, which is as follows: I have a local hg clone of a remote svn repo which is set up as "default" and from which I'm pulling changes. I have also set up a BitBucket mirror to which I'm pushing changes (set up as "default-push" in the local clone). hg svn rebuildmeta (without using an explicit URI) fails because it tries to use default-push (which is a hg repository).

The "fix" for this, i.e. making hgsubversion prefer default, would be trivial but it might break some other workflows (clone a remote svn repo once, everyone else clones this repo but pushes back to the svn one).

Perhaps the right thing to do would be to use the path that starts with "svn+" (and continue preferring default-push if both do and it is preferred for some reason). I could write a patch if this is deemed acceptable.

Thoughts?

Comments (6)

  1. Jérôme Berger

    Two points:

    • The hg svn info command is also affected;
    • Rather than using default-push as the default URL, wouldn't it make more sense to define a default-svn path that would take precedence if defined? The order of precedence for the hg svn * commands would then be:

      1. Command line
      2. default-svn
      3. default

      IMO, default-push does not belong here at all.

  2. Jérôme Berger

    This patch replaces default-push with default-svn when looking for a default SVN path (for some reason, I can't seem to attach the patch as file, so since it is short I put it inline):

    diff -r b5b1fce26f1f hgsubversion/svncommands.py
    --- a/hgsubversion/svncommands.py       Sun Jun 23 18:16:13 2013 -0500
    +++ b/hgsubversion/svncommands.py       Mon Oct 07 17:20:41 2013 +0200
    @@ -49,7 +49,7 @@
         elif len(args) > 1:
             raise hgutil.Abort('rebuildmeta takes 1 or no arguments')
         uuid = None
    -    url = repo.ui.expandpath(dest or repo.ui.config('paths', 'default-push') or
    +    url = repo.ui.expandpath(dest or repo.ui.config('paths', 'default-svn') or
                                  repo.ui.config('paths', 'default') or '')
         svn = svnrepo.svnremoterepo(ui, url).svn
         subdir = svn.subdir
    diff -r b5b1fce26f1f hgsubversion/svnrepo.py
    --- a/hgsubversion/svnrepo.py   Sun Jun 23 18:16:13 2013 -0500
    +++ b/hgsubversion/svnrepo.py   Mon Oct 07 17:20:41 2013 +0200
    @@ -118,7 +118,7 @@
         def __init__(self, ui, path=None):
             self.ui = ui
             if path is None:
    -            path = self.ui.config('paths', 'default-push')
    +            path = self.ui.config('paths', 'default-svn')
             if path is None:
                 path = self.ui.config('paths', 'default')
             if not path:
    diff -r b5b1fce26f1f tests/test_utility_commands.py
    --- a/tests/test_utility_commands.py    Sun Jun 23 18:16:13 2013 -0500
    +++ b/tests/test_utility_commands.py    Mon Oct 07 17:20:41 2013 +0200
    @@ -70,7 +70,7 @@
             destpath = self.wc_path + '_clone'
             test_util.hgclone(u, self.repo, destpath)
             repo2 = hg.repository(u, destpath)
    -        repo2.ui.setconfig('paths', 'default-push',
    +        repo2.ui.setconfig('paths', 'default-svn',
                                self.repo.ui.config('paths', 'default'))
             hg.update(repo2, 'default')
             svncommands.rebuildmeta(u, repo2, [])
    
  3. Jérôme Berger
    1. Not adding a default-svn is your call and I can understand it. I only did it this way because it is way easier than looking for the path that starts with svn+;
    2. Not fixing the issue is also your call, but I don't understand it. In particular, svn rebuildmeta and svn info deal with incoming data and therefore have no reason to use the default-push path;
    3. Putting the patch here ensures that anyone interested in the problem will find it (all the more important since you won't fix it);
    4. If anyone is interested but doesn't want to apply the patch themselves, I've forked the repos with the patch applied here.
  4. Augie Fackler repo owner

    If you want to keep having this discussion (and figure out how we can make this better and less confusing, which I'd love to do), the right place is the hgsubversion mailing list, not the issue tracker. FaceBook has a pretty large hgsubversion deployment, and their backwards compatibility needs are a good proxy for what most users will likely expect.

  5. Log in to comment