SVN-able extracted src tree

Seeker

Seeker

I'll be moving from 9.0 -> 9.1 shortly

Before I even start, I know:
Code: 
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:
Code: 
svn up /usr/src
..., onward.
 
Seeker said:
I'll be moving from 9.0 -> 9.1 shortly

Before I even start, I know:
Code: 
svn co svn://svn.freebsd.org/base/releng/9.1 /usr/src
So don't give me this, as a solution!
Click to expand...

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.

Then I just:
Code: 
svn up /usr/src
..., onward.
Click to expand...

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.
 
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.
 
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.
 
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.
 
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.
 
Seeker said:
Well, CVS was able to handle it.
Click to expand...

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.
Click to expand...

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 said:
Why?
A checkout/update over svn:// is approx 4-12 times faster than over http(s)://
Click to expand...

It prevents MITM attacks. When I first tried HTTPS a while back, it was slower. Does not seem to be noticeably slower now.
 
Ok, Then I'll use it too.
After checkout via HTTPS, will # svn up, auto use HTTPS afterwards?
 
Seeker said:
Ok, Then I'll use it too.
After checkout via HTTPS, will # svn up, auto use HTTPS afterwards?
Click to expand...

Yes, svn remembers the URL. Existing checkouts can be switched from svn to https with the svn switch command.
 
wblock@ said:
Yes, svn remembers the URL. Existing checkouts can be switched from svn to https with the svn switch command.
Click to expand...

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.
 
# svn switch --relocate http:// svn://
is what I have used. svn relocate looks to be a shorter version of that.
 
# 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.
 
You must log in or register to reply here.
Back
Top