RELENG_9/cvs not deprecated...

RELENG_9 is now cvsupable. RELENG_10 may eventually only be by svn? Not so much wondering about getting the latter sources, as a link I should check about the topic, periodically or before some next buildworld, that would be quicker than reading all the posts to freebsd-stable... Or I misread some post earlier today.
 
jb_fvwm2 said:
RELENG_9 is now cvsupable. RELENG_10 may eventually only be by svn? Not so much wondering about getting the latter sources, as a link I should check about the topic, periodically or before some next buildworld, that would be quicker than reading all the posts to freebsd-stable... Or I misread some post earlier today.

It is my understanding that CVS will remain just for RELENG_9 only. So, for future releases, even FreeBSD-9.1 you will need to use svn.
 
And future branches? RELENG_10? 10-STABLE? I maybe could find the svn (though I think it takes a lot more disk space unless the precise CLI's are known...) if one particular webpage gave examples, details, the branch names and svn equivalent, etc...
 
jb_fvwm2 said:
And future branches? RELENG_10? 10-STABLE? I maybe could find the svn (though I think it takes a lot more disk space unless the precise CLI's are known...) if one particular webpage gave examples, details, the branch names and svn equivalent, etc...

Yes, a lot of work needs to be done in the handbook as well!

For now you can still use cvs for STABLE and HEAD. I don't think you will be able to use it for 10 though, once it is created.
If you want to start using SVN:

For FreeBSD 9.1-RC1

[CMD=""]svn checkout svn://svn.freebsd.org/base/releng/9.1/ /usr/src[/CMD]

For RELENG_9

[CMD=""]svn checkout svn://svn.freebsd.org/base/stable/9/ /usr/src[/CMD]

For HEAD

[CMD=""]svn checkout svn://svn.freebsd.org/base/head/ /usr/src[/CMD]
 
A full checkout includes history files, nearly doubling the size of /usr/src over CVS. If you rarely download source, svn export, which only downloads the files but not the history, may take less bandwidth overall.

There is still no svnsup/svnup, but the lack is being felt and this change may provide more incentive to get it going. CVS mirroring could be turned back on, too.
 
Hmmm...
Code:
 svn export
seems to want /usr/src deleted first... and is sort of terse as to the results of the "--force" parameter. "svn-export" (linux) doesn't appear to be in the ports tree... though some other port may mimic its actions. Searched a bit on that, no results...
 
Sure. Same thing with svn checkout, remove source first. The good thing with a checkout is that after the first big batch of data, it will only retrieve changes, including changes to history. It's pretty fast.

svn export just pulls the files out of the repository. All of them, not just changed ones. So which is more efficient will use more bandwidth depends on how often you update.
 
From a thread on the web, it appears
Code:
 svn export --force #modified as above
is what I'd maybe want to use in this case [ local non-src files would remain (custom kernel, etc.) ], except that files which cvs would delete, would *also* remain (making it not useful for an actual buildkernel probably.) So if that is indeed the case, cvs OR svn co when I next do a source upgrade... until only the latter of the two is possible.
 
It helps to put kernel config files in /root or elsewhere safe, then link them into the conf directory:
# ln -s /root/CUSTOMKERNEL /usr/src/sys/amd64/conf/

An svn checkout has another nice feature, not overwriting user-modified files. So keeping local source patches is easier.
 
Almost relevant question
Code:
svn co svn://svn.freebsd.org/ports/head/archivers /usr/ports/archivers
# .svn appears in /usr/ports/archivers
svn co svn://svn.freebsd.org/ports/head/shells/fd /usr/ports/shells/fd
# .svn appears in /usr/ports/shells/fd
failed:  (from the ports mailing list...)
svn co svn://svn.freebsd.org/ports/base /usr/ports
Which of the three forms is correct? Optimal? Recommended? Sort of like the many times I try to tar a subdirectory elsewhere and an extra directory appears in the target rather than the "same" result... (I put
the eventual good results in /motd... )
 
Back
Top