Opened 10 years ago

Closed 9 years ago

#15868 closed defect (fixed)

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

Reported by: kimuraw (kimura wataru) Owned by: raimue (Rainer Müller)
Priority: Normal Milestone: MacPorts 1.7.1
Component: base Version: 1.6.0
Keywords: Cc: raimue (Rainer Müller), ryandesign (Ryan Schmidt), mf2k (Frank Schima), blb@…, jmroot (Joshua Root)
Port:

Description

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.

Attachments (2)

patch-macports-no-svn-rsync-from-autoconf.diff (2.8 KB) - added by raimue (Rainer Müller) 10 years ago.
patch.diff (9.2 KB) - added by blb@… 9 years ago.
patch to remove various _path

Download all attachments as: .zip

Change History (17)

comment:1 Changed 10 years ago by ryandesign (Ryan Schmidt)

Milestone: MacPorts base bugs

comment:2 Changed 10 years ago by raimue (Rainer Müller)

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.

comment:3 Changed 10 years ago by ryandesign (Ryan Schmidt)

Cc: raimue@… ryandesign@… added

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

Changed 10 years ago by raimue (Rainer Müller)

comment:4 Changed 10 years ago by raimue (Rainer Müller)

Milestone: MacPorts base bugsMacPorts 1.7.0
Owner: changed from macports-tickets@… to raimue@…
Status: newassigned

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.

comment:5 in reply to:  4 Changed 10 years ago by 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.

comment:6 Changed 10 years ago by blb@…

Milestone: MacPorts 1.7.0MacPorts 1.7.1

comment:7 Changed 10 years ago by 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?

comment:8 Changed 10 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… added

Cc Me!

comment:9 Changed 10 years ago by blb@…

Cc: blb@… added

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.

comment:10 Changed 9 years ago by mf2k (Frank Schima)

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

comment:11 Changed 9 years ago by blb@…

Looks like bitrot already...will update soon.

Changed 9 years ago by blb@…

Attachment: patch.diff added

patch to remove various _path

comment:12 Changed 9 years ago by blb@…

Patch updated.

comment:13 Changed 9 years ago by jmroot (Joshua Root)

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.

comment:14 Changed 9 years ago by 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?

comment:15 Changed 9 years ago by jmroot (Joshua Root)

Cc: jmr@… added
Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.