port-1.600: port sync fails with "please get a newer Subversion client"

[kimuraw@…]

I have some port trees under subversion. Today, I got the following error at "sudo port sync".

  % which svn
  /opt/local/bin/svn
  % /opt/local/bin/svn --version
  svn, version 1.5.0 (r31699)
    :
  % /usr/bin/svn --version
  svn, version 1.4.4 (r25188)
    :
  % sudo port -v sync
  Synchronizing local ports tree from file:///opt/dports.dev
  svn: This client is too old to work with working copy '/opt/dports.dev'; 
  please get a newer Subversion client
  port sync failed: Synchronization of the local ports tree failed doing an 
  svn update

I fixed this problem with changing the value of svn_path to "/opt/local/bin/svn" in /Library/Tcl/macports1.0/macports_autoconf.tcl. I think autoconf_hint is not so needed at in macports1.0/macports.tcl(line 1317) to detect the path of `svn' command.

[raimue@…]

Working copies of svn 1.4.x and svn 1.5.x are not compatible. Apple provides svn 1.4.x in /usr/bin/svn, MacPorts provides svn 1.5.x in ${prefix}/bin/svn. So once you used svn up on your working copy with the client from MacPorts it was automatically upgraded to svn 1.5.x.

Maybe we should stop hardcoding the path to svn in macports_autoconf.tcl and simply use the first svn in PATH, which usually is ${prefix}/bin/svn.

I don't see an advantage of hardcoding paths for svn and rsync. If ${prefix}/bin/{svn,rsync} does not work for whatever reason, there is still the possibility to deactivate the regarding port and use the system provided binary.

If we remove it, I would also add --svn-path and --rsync-path options to port sync, so it could be overwritten from the command line, like this:

$ port sync --svn-path /usr/bin/svn --rsync-path /usr/bin/rsync

Another solution would be to add an option to macports.conf for this, but comment it out by default as there is no common default value for Tiger and Leopard.

[ryandesign@…]

We need to fix this. I would be ok with just using whatever {svn,rsync} is found in PATH.

[raimue@…]

I removed the hardcoded svn and rsync paths from macports1.0 in the attached patch .

There is still some hardcoded stuff in port1.0/port_autoconf.tcl.in, I think mostly for fetching over cvs/svn/git. Should we do the same there?

Considering this ticket for 1.7.0.

[blb@…]

Replying to raimue@…:

There is still some hardcoded stuff in port1.0/port_autoconf.tcl.in, I think mostly for fetching over cvs/svn/git. Should we do the same there?

I sure can't think of a reason not to, since that makes port act more like when someone is otherwise using the command line.

[blb@…]

Is there any reason for both macports_autoconf.tcl.in and port_autoconf.tcl.in? Would it be simpler to bring those two together into, say, macports_autoconf as a package itself (like macports_util) and use it instead? Then, remove at least some of the *_path variables in that?

[macsforever2000@…]

Cc Me!

[blb@…]

Anyone see any issues with the attached patch? I've been running it for a few days now with no ill-effect. Note that src/registry1.0/registry_autoconf.tcl.in would actually be removed since it'll have nothing in it afterwards.

[macsforever2000@…]

The patch.diff patch works for me, although i see this:

patching file src/port1.0/portdestroot.tcl
Hunk #1 succeeded at 93 with fuzz 1 (offset 1 line).
Hunk #2 FAILED at 100.
1 out of 2 hunks FAILED -- saving rejects to file src/port1.0/portdestroot.tcl.rej

[blb@…]

Looks like bitrot already...will update soon.

[blb@…]

patch to remove various _path

[blb@…]

Patch updated.

[jmr@…]

I don't like this idea because it allows broken ports to break base, as illustrated by #18149. It seems like we should be using more full paths, not less. Subversion seems to be a special case simply because of the likelihood that people will operate on the working copy manually as well as via port.

[blb@…]

Then we need a list of those programs which must always be from the system and path those, since I think that would be the better direction than trying to list those which shouldn't be pathed. So bzip2, cvs, open, and rsync should be right? What about mtree and xar?

[jmr@…]

Stopped using autoconf for the svn path in sync, r47776 (trunk) and r47777 (1.7 branch). This fixes the specific bug reported here. We can work on the general issue more in future.