portsnap being retired - what's the alternative?

Status
Not open for further replies.
If you like it or not, it would be more effective beginning to use git rather than subversion control tools in the long run. Sooner or later FreeBSD will be migrated to git. For portsnap users why using subversion control tools now? In the mail no deadline for portsnap(8) is given. Maybe it can be used until then. If not, using git would be the logical choice instead of svn(lite)/svnup.

From the April, 2020 - June, 2020 FreeBSD Status report, Git Migration Working Group:

"We expect to be ready for the migration in the next quarter."
 
There are problems on both sides ... of the svn vs. git decision.

As memreflect said, the flaw in portsnap is it can only fetch HEAD. It can't do quarterly. I'd prefer a single tool that covered both. This could be fixed in portsnap. Worst case is it falls back to using libsvn to do a 'svn checkout' of quarterly.

git may be desired by ports maintainers and kernel coders - but it doesn't offer any benefit for read-only 'buildworld' users. The normal use case for users (those without a FreeBSD commit bit) is to get the latest (or latest quarterly branch) and build. You don't care about commit history or any other branches. 'git clone' pulls down the entire repository. This is very useful for some - but not so when all you want is a build of the current code. To avoid getting gigabytes of commit history you can use:

Code:
$ git clone -depth 1 -branch <branch-name> https://url.freebsd.org/some/path

This would still use more disk space than 'svn checkout' but may be good-enough.

A compromise path forward is to keep the svn tools in base. The server hosting the git repository can deploy tools to make a git repository look like a subversion repository (github does this today) - allowing svn and svnlite to continue to function. Folks with a FreeBSD commit bit would use the git interface to do branching, PRs, and merging.

For folks wanting to avoid GPL bits in base, A few OpenBSD contributors are working on a git inspired tool called 'got'. It could be made git compatible - like svnlite but for git. That would require some work.

If we do end up with 'git clone' as the way forward, here is one consolation prize. You can use your local clone to track your local changes (custom kernel or port build options). Just do a git pull whenever you want your local repository updated. This will on occasion require some manual edits for merge conflicts - but that is normal for both git and svn.

Edit: '-depth 1' implies '-single-branch' but you still need a branch name.
 
Since we're moving towards git (soonish) I somewhat doubt svn is going to be a viable solution/workaround in the long run...
As far as I know, there are plans to keep SVN servers running in read-only mode for an indefinite time after the switch to git, so net/svnup should continue to work. And apart from that, it’s also not unlikely that someone will come up with a similar BSD-licensed tool for git (let’s call it “gitup”).
 
Here is got.

I ported an earlier release to FreeBSD as a toy exercise.

 
Subversion in base is really handy. I don't think this is possible with Git.

Also, if you look at win32 ports, svn is tiny and portable. Just a few executables. Whereas Git is impossible to port and requires an entire Cygwin / Msys2 POSIX compatibility layer. Typical Linux shite frankly.

However, if the GitHub workflow is what the developers pine for then atleast GitHub (for now) provides support for Subversion.

i.e the following works:

svn co "https://github.com/osen/emscripten-devel.git/trunk" emscripten

And once Microsoft drops subversion support, hopefully the OpenBSD guys will have completed their GoT (http://gameoftrees.org/) client that perhaps we can include in base.

Edit: That it looks like unitrunker has already made great progress with :)
 
Another thing that bothers me about git is that Linus created that over one weekend and ran with it. Sure, it has had improvements and additions over the years but I would have an uneasy feeling about someone building the foundation of my house so fast over the weekend.
 
I don't wish to rain on anyone's parade, but the ports mailing list says Subversion is going away too in FreeBSD's migration to git.
 
gpb From your same source I presume:
took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git. took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git.
That's not the same source I read. I read about it on the mailing list when he first introduced git way back when. He said something along the lines of, "I knew I could do it over the weekend and I did!"
 
I don't wish to rain on anyone's parade, but the ports mailing list says Subversion is going away too in FreeBSD's migration to git.

I do find it fairly amusing that the following:

pkg install git

Happens to drag in subversion. Something in the FreeBSD Git port requires not just svnlite but the full fat svn.

So either they fix that, or we won't be saying goodbye to Subversion just yet!
 
I believe you can use git to work on a local repo and push commits to a subversion server. Git needs the SVN libs to do this.

All I ask is that 'git help' should not open a browser.
 
GIT uses a GPL2 license. I don't see how that's going into the FreeBSD base.

svnup can't do everything that svn or svnlite can do. I could only get ports and system updates from it. Perhaps the [defaults] section of the default freebsd.org host would have to be overriden in a subsection to use this with another host.

In /usr/local/etc/svnup.conf: each section is referenced, of which branch and target to use, so it doesn't have to be typed out each time as in svn or svnlite. The protocol can also be set from http to svn.

Code:
[defaults]
work_directory=/var/tmp/svnup
host=svn0.us-east.freebsd.org
protocol=svn
verbosity=2
trim_tree=0
extra_files=0

[release]
branch=base/releng/12.1
target=/usr/src

[ports]
branch=ports/head
target=/usr/ports

# To update only a specific directory
[net]
branch=ports/head/net
target=/usr/ports/net

What's in the parenthesis (except defaults) is used with svnup for that.

Using svnup with its configuration file is simpler than...
Code:
svn checkout https://svn.freebsd.org/ports/head /usr/ports
svn update /usr/ports
svn cleanup /usr/ports
 
Somewhat off topic but in the same vein.
I did not realize that devel/git-lite was a FreeBSD only construct.
Recently I attempted to port a Linux software to FreeBSD and started by downloading the source from github to a Linux VM.
apt-get install git-lite did not work so I went looking for it and discovered it was only used on FreeBSD.
I used subversion instead to fetch the source.
 
I don't get it . The change to git only affects developers and people who want to contribute, I can't find the page but I read that one of the reasons was that it is very difficult to accept patches and merge patches with svn. It has nothing to do with end users.

Besides the topic title is about portsnap alternatives and it seems that it can be substituted by svnlite included in base or poudriere which is well documented.
 
Criosphinx - if that's the case that sounds good.

I don't mind picking up something new if I have to but don't want to jump from portsnap to svnlite and then have to move again to a git-based flow - for keeping-up-to-date with ports. So if moving to svnlite is going to work then I'll carry on.

I've waited overnight and there are some updates, so I've done svnlite update /usr/ports.

Code:
svnlite update /usr/ports
pkg version -vIL=
... nothing ...

I know from a machine that I'm using portsnap up that there's a new version of apache24:

Code:
portsnap fetch update
pkg version -vIL=
...
apache24-2.4.43                    <   needs updating (index has 2.4.46)

If I go back to my svnlite machine, this seems to do the same thing:

Code:
cd /usr/ports/
make index
...
pkg version -vIL=
apache24-2.4.43                    <   needs updating (index has 2.4.46)

Rummage through FMs and for -I (i for igloo):

Code:
If not specified then the ports index file will be used if it exists (-I).
 
You don't need it, unless there's a problem and svn complain that it's locked! Sometime for different reason (e.g. connection drop, ...) the process gets interrupted. SVN will complain, locked and you have run this command, and after that resume the process as usual.
 
Somewhat off topic but in the same vein.
I did not realize that devel/git-lite was a FreeBSD only construct.
Recently I attempted to port a Linux software to FreeBSD and started by downloading the source from github to a Linux VM.
apt-get install git-lite did not work so I went looking for it and discovered it was only used on FreeBSD.
I used subversion instead to fetch the source.

This is the same thing but built with the minimal necessary amount of compile time OPTIONS ON.
 
I don't get it . The change to git only affects developers and people who want to contribute, I can't find the page but I read that one of the reasons was that it is very difficult to accept patches and merge patches with svn. It has nothing to do with end users.

Besides the topic title is about portsnap alternatives and it seems that it can be substituted by svnlite included in base or poudriere which is well documented.
Of course, the change to git will affect normal users who use Subversion-based tools like svn, svnlite or svnup, as soon as the old Subversion servers have been switched off.

So, changing from portsnap to, say, svnlite now does not appear to be a particularly good idea …
 
By the way, another option is to simply download https://download.freebsd.org/ftp/ports/ports/ports.tar.gz (available via FTP, HTTP and HTTPS). This is one 60 MB blob, but if you do that just once per week or so, it shouldn’t be much of a problem, unless you’re seriously bandwidth-limited. If you have several machines, you can download it to one of them, and then rsync(1) or cpdup(1) it to the others.

The advantage of that approach is that it works independent from any CVS / SVN / Git / whatever, it will continue to work indefinitely, and it’s dead simple. (Only works for head, though. I’m not aware of quarterly snapshots available for download like that.)
 
So, changing from portsnap to, say, svnlite now does not appear to be a particularly good idea …
Full reverse thrust Mr Sulu!
The engines canna take any mair, captain!


Think the download of ports.tar.gz sounds like a good option to investigate, so will look at that next. One day I'll end up with poudriere I'm sure, but it always seems like a bit more work (and Larry Wall said programmers are lazy so I have an excuse!)
 
By the way, another option is to simply download https://download.freebsd.org/ftp/ports/ports/ports.tar.gz (available via FTP, HTTP and HTTPS).
...
(Only works for head, though. I’m not aware of quarterly snapshots available for download like that.)

You can get a zip compressed file for quarterly ports from https://github.com/freebsd/freebsd-ports/tree/branches/2020Q3 (look for the "Code" marked green button).

This is also valid for ports head, base system head, release, releng, stable. I used to download for a while this way ports and base source.

Maybe someone in this thread has mentioned it already, GitHub supports subversion clients, so one is not necessarily bound to git. I haven't downloaded from the FreeBSD GitHub web page for a while, I've forgotten that option:

 
You can get a zip compressed file for quarterly ports from https://github.com/freebsd/freebsd-ports/tree/branches/2020Q3 (look for the "Code" marked green button).

This is also valid for ports head, base system head, release, releng, stable. I used to download for a while this way ports and base source.

Maybe someone in this thread has mentioned it already, GitHub supports subversion clients, so one is not necessarily bound to git. I haven't downloaded from the FreeBSD GitHub web page for a while, I've forgotten that option:

Interesting. I wasn’t aware that Github had copies of the FreeBSD ports collection and the source trees. Is this an “official” service of the FreeBSD project that will be available indefinitely? And are these synchronized with the project’s SVN server instantly, or do they lag behind by a certain amount of time?

Regarding Github’s support for subversion clients: If that could be made to work with net/svnup somehow, that would be very cool.
 
Status
Not open for further replies.
Back
Top