Node conflicts in SVN

[Kevin Oberman]

On Mon, Nov 19, 2012 at 11:37 AM, Frank Seltzer <frank_s at bellsouth.net> wrote:
>
>
> On Mon, 19 Nov 2012, Kevin Oberman wrote:
>
>> On Mon, Nov 19, 2012 at 8:28 AM, Frank Seltzer <frank_s at bellsouth.net>
>> wrote:
>>>
>>> I run a nightly ports tree update and I have been getting the following
>>> errors the last couple of days.  I haven't seen this asked before so is
>>> this
>>> just me or is anyone else seeing this?  Have I fat-fingered something?
>>>
>>> Updating '/usr/ports':
>>> Skipped '/usr/ports/astro' -- Node remains in conflict
>>> Skipped '/usr/ports/devel' -- Node remains in conflict
>>> Skipped '/usr/ports/sysutils' -- Node remains in conflict
>>> Skipped '/usr/ports/audio' -- Node remains in conflict
>>> Skipped '/usr/ports/textproc' -- Node remains in conflict
>>> Skipped '/usr/ports/x11-fm' -- Node remains in conflict
>>> Skipped '/usr/ports/MOVED' -- Node remains in conflict
>>> Skipped '/usr/ports/games' -- Node remains in conflict
>>> Skipped '/usr/ports/mail' -- Node remains in conflict
>>> Skipped '/usr/ports/net' -- Node remains in conflict
>>> Skipped '/usr/ports/multimedia' -- Node remains in conflict
>>> At revision 307524.
>>> Summary of conflicts:
>>>   Skipped paths: 11
>>
>>
>> This usually indicates non-SVN updates to these items. If you have not
>> modified them intentionally, just 'rm -r' them and 'snv up /usr/ports'
>> again. I hit this after switch to svn when a cron job did a csup of
>> ports. Oops!
>> --
>> R. Kevin Oberman, Network Engineer
>> E-mail: kob6558 at gmail.com
>
>
> Nope, no non-SVN updates or manual changes.  I am getting this on 3 separate
> boxes and have disabled csup in cron on them all.
>
> Are you sure about 'rm -r'ing them?  IIRC, I reran 'svn co' instead of 'svn
> up' by mistake on 1 box and it pulled the entire collection again. Not sure
> about this as my memory ain't what it used to be.  You know what they say,
> The mind is the first thing to go!
>
> Thanks,
> Frank

In svn, "conflict" simply means that hte file on disk does not match
the one in the SVN repository. This is usually because a file has been
locally modified and svn won't blow away edits you have made in your
sandbox. I mmean, htat is normally what a sandbox is for. Of course,
if you are not a committer, this probably not the case, though you
might have made local changes to a port, in which case you just were
saved from foot-shooting.

On any case, "rm -r /usr/ports/x11-fm /usr/ports/MOVED
/usr/local/games /usr/local/mail /usr/local/net /usr/local/multimedia'
is safe as an update will simply pull down new copies of those files
from the repo. Or you can do them per-directory with 'svn up
/usr/ports/MOVED', etc.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6558 at gmail.com