# SVN-able extracted src tree



## Seeker (Feb 2, 2013)

I'll be moving from 9.0 -> 9.1 shortly

Before I even start, I know:

```
svn co svn://svn.freebsd.org/base/releng/9.1 /usr/src
```
So don't give me this, as a solution!

I've deleted /usr/src and extracted 9.1's *src.txz* in it.
From this point on, I want it to be SVN-able (It doesn't have .svn/) in order to get patches.
Which svn command would scan and sync src tree, thus create .svn/ as a result.

Then I just:

```
svn up /usr/src
```
..., onward.


----------



## wblock@ (Feb 2, 2013)

Seeker said:
			
		

> I'll be moving from 9.0 -> 9.1 shortly
> 
> Before I even start, I know:
> 
> ...



For exactness, it is now recommended to use HTTPS and the closest mirror.  So that should be
`# svn checkout [url]https://svn0.us-west.FreeBSD.org/base/releng/9.1[/url] /usr/src`

or another mirror that is closer to you.



> I've deleted /usr/src and extracted 9.1's *src.txz* in it.
> From this point on, I want it to be SVN-able (It doesn't have .svn/) in order to get patches.
> Which svn command would scan and sync src tree, thus create .svn/ as a result.
> 
> ...



As far as I know, there is no way to do that.  svn(1) manages files, and trying to checkout over an existing directory causes problems.  If there was an archive file that contained all the SVN metadata, that would work.  I don't think those are available.  Even if they were, it would not be much different than a full original checkout.  Maybe less bandwidth due to compression, although svn(1) might do that internally also.

If you have another system with a full SVN checkout of the source tree, it can be copied to the new system, and svn up will work with it.


----------



## Seeker (Feb 2, 2013)

Thx for https hint.

I don't want to checkout over an existing directory. Actually, for this task, checkout mustn't be used at all!
.svn/ must be built, without checking out existing extracted files in src tree.
Is there some rebuild or sync svn command, so it only gets .svn/.

Point is, if I have to use svn checkout on empty /usr/src, then why should I ever download src.txz, if it can't be updated once extracted.
With CVS, this was possible via supfile.


----------



## kpa (Feb 2, 2013)

There's no other way than to have a .svn directory. In SVN and other similar revision control systems (GIT for example) the history information is stored in the .svn (.git in GIT) directory and the checked out copy is completely self contained. If there's no .svn directory the SVN client will not know what revision is the working directory and can not update it.


----------



## Seeker (Feb 2, 2013)

Well, CVS was able to handle it.

Hell then, with SVN, it is completely senseless to fetch src.txz, as you can't update it, to get security patches.
Now, you are frozen in time with src.txz.


----------



## kpa (Feb 2, 2013)

CVS was able to do it because the repository specification was external and the revisions were stored in the RCS/*,v files for every directory, SVN and GIT take a different approach that isn't less valid, just different.


----------



## wblock@ (Feb 2, 2013)

Seeker said:
			
		

> Well, CVS was able to handle it.



SVN is very different from CVS.  And more secure because of it.



> Hell then, with SVN, it is completely senseless to fetch src.txz, as you can't update it, to get security patches.
> Now, you are frozen in time with src.txz.



Yes.  If you want source updates, use svn(1).  If you want binary updates, use freebsd-update(8), which can also fetch source, but only for releases.

There is no SVN equivalent of csup(8) yet.  There are several efforts are under way, but none are ready yet.

There is one other alternative.  svn export can fetch all the files in a repository without the metadata.  However, these are all the files, not just changes.  So you can download the latest copy of the source, but it will take much longer and use more bandwidth than svn up.


----------



## Seeker (Feb 2, 2013)

Ok, I see.
So, now with SVN
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.1-RELEASE/
src.txz should be avoided.


----------



## Seeker (Feb 2, 2013)

wblock@ said:
			
		

> For exactness, it is now recommended to use HTTPS ...


Why?
A checkout/update over svn:// is approx 4-12 times faster than over http(s)://


----------



## wblock@ (Feb 2, 2013)

Seeker said:
			
		

> Ok, I see.
> So, now with SVN
> ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/9.1-RELEASE/
> src.txz should be avoided.



Yes.  Or rather, there's no point to downloading the tar file.


----------



## wblock@ (Feb 2, 2013)

Seeker said:
			
		

> Why?
> A checkout/update over svn:// is approx 4-12 times faster than over http(s)://



It prevents MITM attacks.  When I first tried HTTPS a while back, it was slower.  Does not seem to be noticeably slower now.


----------



## Seeker (Feb 2, 2013)

Ok, Then I'll use it too.
After checkout via HTTPS, will # svn up, auto use HTTPS afterwards?


----------



## wblock@ (Feb 2, 2013)

Seeker said:
			
		

> Ok, Then I'll use it too.
> After checkout via HTTPS, will # svn up, auto use HTTPS afterwards?



Yes, svn remembers the URL.  Existing checkouts can be switched from svn to https with the svn switch command.


----------



## Seeker (Feb 2, 2013)

That would be all.
Thx!


----------



## xtaz (Feb 4, 2013)

wblock@ said:
			
		

> Yes, svn remembers the URL.  Existing checkouts can be switched from svn to https with the svn switch command.



I tried to do this today and found that actually that doesn't work. It complains that the repository is different. It looks like if the base URL changes you actually have to use svn relocate which does the trick.


----------



## wblock@ (Feb 4, 2013)

`# svn switch --relocate http:// svn://`
is what I have used.  svn relocate looks to be a shorter version of that.


----------



## Seeker (Feb 5, 2013)

`# svn relocate svn https /usr/src`
I've got error: *" ... Unrecognized URL scheme ... "*
In order to use http(s), you need to compile it with 'neon' support!
Now it works, after recompilation.


----------

