svnup freezes

R

rihad

Yesterday I updated my 10-CURRENT from almost a year ago via the usual make update, but didn't rebuild anything. Today I wanted to make update just one more time before rebuilding, but got this:
Code: 
--------------------------------------------------------------
CVS_UPDATE and SUP_UPDATE are no longer supported.
Please see: [url]https://wiki.freebsd.org/CvsIsDeprecated[/url]
--------------------------------------------------------------
*** [update] Error code 1

Stop in /usr/src.
*** [update] Error code 1

Stop in /usr/src.

So I read the wiki, grab net/svnup, but still can't update anything by running svnup current

Here's my /usr/local/etc/svnup.conf (without the unmodified branch sections).
Code: 
work_directory=/var/tmp/svnup
#host=svn.freebsd.org
host=svn0.us-west.freebsd.org
#host=svn0.us-east.freebsd.org
#protocol=https
protocol=svn
verbosity=2
trim_tree=0
#extra_files=0
extra_files=1

The default protocol=https or protocol=svn runs, but sits there and does nothing. protocol=http starts spitting out some info, but then chews up CPU seemingly for an indefinite amount of time (with no disk/network activity).
 
This is just an educated guess; I don't have experience with svnup nor do I know exactly what protocols are supported by the mentioned servers above.

Having said that I can't help wonder if changing the protocol from svn back to the default https won't help here. The reason for this theory is the way I checked out the source tree (though using svn); using https:

Code: 
root@smtp2:/usr/src # svn info
Path: .
Working Copy Root Path: /usr/src
URL: https://svn0.us-east.freebsd.org/base/releng/9.1
Relative URL: ^/releng/9.1
Repository Root: https://svn0.us-east.freebsd.org/base
(I'm aware our versions don't match, that's not the point nor does it matter here)

As such my suggestion; try again with https.
 
Just for fun, I tried svnup() with HTTPS, (using CURRENT). It didn't work for me. Increasing verbosity by adding -v 3 showed that it never even connected to the SVN server. Changing the protocol back to SVN made it work for me. I agree that whether one is using CURRENT or 9.x shouldn't make a difference. Some very cursory googling indicates that there might still be issues with svnup and HTTPS.
 
The default svn.freebsd.org has HTTPS port 443 closed, so it isn't surprising it doesn't work. The other domains listed, like svn0.us-west.freebsd.org, do appear to have port 443 functioning, but it still hangs there for an hour or so doing nothing. Same thing for protocol=svn and http.

It's a bit frustrating update functionality is no longer abstracted away with a simple make update

One of those times I wish make had a -f (force) knob ;) make -f update
 
When all else fails I'd recommend removing svnup and simply grabbing devel/subversion instead. I realize that Subversion has more dependencies than svnup but I also think it may save you a lot of hassle. Another possible advantage is that Subversion is also usable for managing your ports collection.

Should you decide to go this route then I can really recommend looking into Section A.5 of the handbook which explains the basic steps of using Subversion (and also how to check out the source code with it).
 
Thanks, @ShelLuser, I'll go that route as a last resort. I already have my ports taken care of by portmaster.
 
Last edited by a moderator:
Subversion is very useful; howsoever some of the fixes in its usage are not frequently mentioned.
Code: 
# checksum mismatch? works most of the time
cd /usr/ports/misc/pciids
svn update --set-depth empty
svn update --set-depth infinity
svn clear /usr/ports
# conflict? This seems to work, I don't know if it is correct
[tc] which I think means "theirs-conflict"
Hope this helps.
 
jb_fvwm2 said:
[cmd=]subversion[/cmd] is very useful; howsoever some of the fixes in its usage are not frequently mentioned.
Code: 
# checksum mismatch? works most of the time
cd /usr/ports/misc/pciids
svn update --set-depth empty
svn update --set-depth infinity
svn clear /usr/ports
# conflict? This seems to work, I don't know if it is correct
[tc] which I think means "theirs-conflict"
Hope this helps.
Click to expand...

Most people using Subversion for ports or source should do full checkouts and not mess with the default depths unless they are modifying source. Partial checkouts just make for more work and more things to go wrong (like conflicts, as you show).
 
Ok, svnup current with protocol=svn finally started working today and successfully updated the tree (host=svn0.us-west.freebsd.org). protocol=https still chews up 100% CPU and just sits there.

Question: would the [release] tag successfully grab errata updates?
Code: 
[release]
branch=base/releng/10.0
target=/usr/src

(once 10.0 gets released, that is)

You know, the difference between the old RELENG_10_0 & and RELENG_10_0_RELEASE in a SUPFILE. We want the effects of the former.

It starts freezing again on subsequent runs. I wonder why it's so fragile and shaky.

P.S. running again, but slowly:

Code: 
  1324 of 58729 (  2.3%)  /usr/src/contrib/tcp_wrappers/BLURB

make update was so fast fetching only whatever changed from the last run. I hope it will go slow only on the first run.
 
I really don't know why you are trying to complicate your life. Just read http://www.freebsd.org/doc/handbook/svn.html, install devel/subversion, set[]up your local source tree with svn co [url=svn://your-closest-svnmirror.freebsd.org/base/whateverversionyouwant]svn://your-closest-svnmirror.freebsd.or ... ionyouwant[/url] /usr/src and then just update it whenever you want with svn up /usr/src.

It's really that fast and simple.
 
You must log in or register to reply here.
Back
Top