Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Oct 2012 15:26:15 +0100
From:      Jamie Paul Griffin <jamie@kode5.net>
To:        freebsd-questions@freebsd.org
Subject:   Re: Trouble updating Sources via subversion?
Message-ID:  <20121004142614.GA70000@kontrol.kode5.net>
In-Reply-To: <alpine.BSF.2.00.1210041536200.26151@mail.fig.ol.no>
References:  <031201cda233$f7fd3210$e7f79630$@leadmon.net> <alpine.BSF.2.00.1210041536200.26151@mail.fig.ol.no>

next in thread | previous in thread | raw e-mail | index | archive | help
[ Trond Endrestøl wrote on Thu  4.Oct'12 at 15:46:54 +0200 ]

> On Thu, 4 Oct 2012 09:27-0400, Howard Leadmon wrote:
> 
> > 
> >   OK, I have over the past few years updated and tracked various source
> > using cvsup, and with freebsd progressing to where it now uses subversion it
> > seemed time to move over.
> > 
> >  I seem to be running into a problem doing this, and I wanted to see if
> > anyone had a cloo they could offer on how to resolve this, so that hopefully
> > I can get my collections of FBSD boxes back where they need to be on
> > updates.
> > 
> >  First off, let me say I have tried to different ways of grabbing the
> > sources (after the announcement of ports dropping cvsup and moving to svn),
> > which do both seem to work.  I have used the following:
> > 
> > svn co svn://svn.FreeBSD.org/ports/head /usr/ports
> > 
> > I have also tried:
> > 
> > svn co https://svn0.us-east.FreeBSD.org/ports/head /usr/ports
> > 
> > 
> > Both seem to retrieve the sources very happily, so I don't seem to have a
> > problem in that aspect, where I run into issues is when I go to grab
> > updates.    As an example let's say I wait a couple hours, and then cd down
> > to my /usr/ports directory, and run 'svn update', it will happy come back
> > and tell me it's updating ., and then spit out something like this (yes the
> > issues reported will vary):
> > 
> > # svn up
> > Updating '.':
> > Skipped 'www' -- Node remains in conflict
> > Skipped 'x11-wm' -- Node remains in conflict
> > Skipped 'net' -- Node remains in conflict
> > Skipped 'x11' -- Node remains in conflict
> > At revision 305233.
> > Summary of conflicts:
> >   Skipped paths: 4
> > #
> > 
> > 
> > So then I waited about another hour, and I ran 'svn update' again, and now I
> > get:
> > 
> > # svn up
> > Updating '.':
> > Skipped 'net' -- Node remains in conflict
> > Skipped 'x11' -- Node remains in conflict
> > Skipped 'www' -- Node remains in conflict
> > Skipped 'x11-wm' -- Node remains in conflict
> > Skipped 'dns' -- Node remains in conflict
> > Skipped 'devel' -- Node remains in conflict
> > Skipped 'sysutils' -- Node remains in conflict
> > Skipped 'lang' -- Node remains in conflict
> > Skipped 'polish' -- Node remains in conflict
> > Skipped 'security' -- Node remains in conflict
> > Skipped 'editors' -- Node remains in conflict
> > Skipped 'net-p2p' -- Node remains in conflict
> > Skipped 'games' -- Node remains in conflict
> > Skipped 'Mk' -- Node remains in conflict
> > Skipped 'java' -- Node remains in conflict
> > Skipped 'palm' -- Node remains in conflict
> > Skipped 'multimedia' -- Node remains in conflict
> > At revision 305253.
> > Summary of conflicts:
> >   Skipped paths: 17
> > #
> > 
> > 
> >  As you can see, the longer I wait, the more entries I get, till eventually
> > every time I run update, it will pretty much bitch about every directory in
> > the tree.   Sure I can run the resolve command and try and clear some of it,
> > but that has to be done by hand and one at a time, and with a batch of
> > machines I could see that taking hours to resolve.
> > 
> >  I have never had a source tree where this just seems to happen constantly,
> > I have completely removed my /usr/ports, /usr/src, and /usr/doc and done
> > fresh checkouts many times over, yet still the issue returns.
> > 
> >  I am all for using subversion to handle updates to the various sources, and
> > was trying to see if we could even offer to mirror for the FreeBSD project,
> > but at the moment I can't even seem to get a stable source tree in hand
> > unless I completely delete all sources and check out free every time, which
> > is a huge waste of time and bandwidth for sure.
> > 
> >  Can anyone offer any suggestions or ideas on how to resolve this issue??
> 
> Are you running some form of automated CVSup updating in parallel with 
> Subversion?
> 
> If not, you should attempt these two commands:
> 
>   cd /usr/ports
>   svn revert
> 
> The second command will revert all locally modified files back to 
> their current state as registrered in the repo. Actually the files are 
> restored from the /usr/ports/.svn directory.
> 
> Try again to update your working copy, i.e.:
> 
>   svn up /usr/ports
> 
> If you are still getting error messages as shown above, try this 
> drastic approach:
> 
> If you have any local stuff in your /usr/ports hierarchy, you better 
> have copies of said stuff elsewhere. Next, delete everything inside of 
> /usr/ports, including the .svn directory. Retry the checkout operation 
> using the master server, or your favorite mirror, and your protocol of 
> choice, e.g.:
> 
>   svn co svn://svn.FreeBSD.org/ports/head /usr/ports
> 
> Then, just for kicks, try to update /usr/ports:
> 
>   svn up /usr/ports
> 
> If you're still getting error messages, make sure no one else is 
> logged in as root/toor.
> 
> Now, you can restore any local stuff in /usr/ports.
> 
> HTH.

Yes, just to add to that, I simply wiped /usr/src and /usr/ports then recreated those directories and used the svn commands as demonstrated by Trond to pull everything in. I didn't have anything I needed to keep and restore in those directories. Some recommend keeping/moving /usr/ports/distfiles and /usr/ports/packages to somewhere else before getting rid of /usr/ports/* so you might want to consider that. 

You would/might need to do `cd /usr/ports && make fetchindex` as well, either 'before or after' svn'ing the ports tree (not sure which). (Someone will confirm that I'm sure.)

Jamie



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121004142614.GA70000>