I see. I for my part do not check out source code; instead I do apply my own secondary patchsets on top of the source code that is in SVN. You can see this from my uname message:
sendbug waiting since 12 years for somebody to read them, among others. Therefore it is necessary that I do maintain these on my own.Hm, sorry, I forgot. It just works. Must look into the code.
svn update or switch (from the config, the date and other options). It analyzes the result, and then decides upon a proper patchset, caring for jails and crossbuilds. svn patch to apply the individual patches, verifies the result, requires interaction on conflicts, and finally uses svn stat and svn diff to store the state of affairs back into a new version of the patchset. svn revert, then the whole stuff is put into zfs snapshot, and that will be used for buildworld and portbuild.
Ok, I see.
You're right. Probably somebody has to create an off-topic threat for GitHub related discussions.
Yes, I was told that already, repeatedly.
Please don't do that, cause this is now far from any sane discussion. Just for the records, paranoia is not only used as a term for a "mental defect" but much more often for being afraid of things for close to no rational reasons, and it should be *pretty* clear. Furthermore, nobody ever forced you to register with github (which is NOT "doing business" as long as you use just their free services). Of course, if someone decides to have his issue tracker on github, you just can't use it in this case. I think this is a pretty simple thing to grasp. Again, this whole thing has nothing to do with FreeBSD, as FreeBSD sources are ALREADY mirrored on github and nothing will change. The "master" repository will not be on github.
Well, I can use their issue tracker very well, only they can't use my fixes, because they won't get them. It's a very simple thing to grasp: it doesn't hurt me at all, because I have the same work with fixing the crap in any case, and so I just save the additional work of packaging the results in order to give them back to the community - and that's not my fault, because they are the ones who have decided to lock themselves up in an ivory-tower.
Great! That is good news for the src tree, and gives indeed ample time to adapt.
In German it would be "millionen Fliegen fressen ..."
Well I rather hope to postpone this for a while - I have just yesterday decided to finally tackle the IPv6 matter, and that will probably require quite a bit of rewriting in my firewalling toolchain.I'm reading that as the Q2 branch will be the last on SVN, but that's just interpretation. Would be interested as well. In fact, that's where I probably benefit the most, cause I do a LOT more changes on ports than on base
I'm reading that as the Q2 branch will be the last on SVN, but that's just interpretation. Would be interested as well. In fact, that's where I probably benefit the most, cause I do a LOT more changes on ports than on base
| End of March, 2021 | Ports repo slated to transition to git |
git clone https://git.FreeBSD.org/src.git -b stable/12 /usr/freebsd-src
git clone -b stable/12 --depth 1 https://git.freebsd.org/freebsd/src.git src.git --depth 1 because I don't care about all the history; I just want the source code. Without that, it takes a whole lot longer to download, but the result, currently, is smaller than the SVN equivalent.root@lt1:/usr # du -sk /usr/src /usr/src.git
4180812 /usr/src
1723368 /usr/src.git$ [b]git clone -b stable/12 --depth 1 https://git.freebsd.org/src.git /tmp/src-12-git[/b]
$ [b]du -ks /usr/src /tmp/src-12-git[/b]
1·405·256 /usr/src
1·682·332 /tmp/src-12-gitgit command does two things: First it retrieves a so-called “shallow” copy of the repository that contains only the stable/12 branch without history information, i.e. only the “head” of that branch. The repository is compressed by default, so it doesn’t take too much space. It’s stored in the .git subdirectory:$ [b]du -ks /tmp/src-12-git/.git[/b]
293·033 /tmp/src-12-git/.gitgit command checks out the actual source tree from the repository that was just retrieved. This is called a “work copy” in Git terms. As you can see, the total space used (~ 1650 MB) is the sum of the size of the usual source tree (~ 1370 MB) plus the size of the shallow repository for this particular branch (~ 280 MB).And all you need to set up your own server is two machines with ssh access. There's really no concept of client and server in git(1), but let's call the machines "workstation" and "server" for clarity.
mkdir myrepo
cd myrepo
git init
vi foo.txt
git add foo.txt
git commit -m "Foo is important"git clone --bare ssh://workstation/~/myrepogit remote add origin ssh://server/~/myrepo
git push -u origin master
Branch 'master' set up to track remote branch 'master' from 'origin'.
Everything up-to-dateAlthough I like github (and similar services and also similar software for on-premise installation) for the nice extra features they provide (and I couldn't care less what Linus thinks about that)…
github.com
you can create private repo(e.g. fork FreeBSD into it) in GitHub for no cost and invite collaborators(which have a GitHub-account). afaik you also can in gitlab. there are paid services although I didn't get to the moment where I would need them(probably depends on size of project, `don't know).
while it's possible to create your own GitHub mirror of src-main-tree TODAY (I did it like that), I guess that's only for us impatient who really rely on compiling with it right away.
github.com
