FreeBSD src repository has transitioned from Subversion to Git

https://cgit.freebsd.org/src/commit/?id=5ef5f51d2bef80b0ede9b10ad5b0e9440b60518c

by cnst • 6 years ago

123 58 6 years ago

cgit.freebsd.org

I use SVN at my job and I gotta say I kind of prefer it to Git. Feels much lighter and the commands make a lot more sense to me

alkonaut2• 6 years ago

That is until you start branching and merging a lot. If you just develop on trunk and basically only do update and commit, then of course svn is more ergonomic. The problem is all the drawbacks of trunk based development: difficult code reviews, no gating so trunk build can break.

CraigJPerry• 6 years ago

> until you start branching and merging a lot

SVN has 3 way merge too so this isn’t the issue it was in other VCS’s

> The problem is all the drawbacks of trunk based development

Those were all addressed reasonably well by about 2014, e.g. upsource (my preference by far) or crucible. TeamCity’s merge after private build feature etc.

Ironically these days i see a big push to use git in a way that would work pretty well in svn too.

The biggest hassle with svn was long lived branches. Back then we encouraged devs to branch and then somehow smoosh it all back together (painful). Then we said ok do it more frequently in atomic commits (i liked that model) then DVCS took off largely in the open source world and now major dev houses (well i guess except google with p4 - but they do provide a git interface) all have come along for the ride.

Ironically with products like Stash/Bitbucket and Github Enterprise, we’re back to an SVN like model.

zadokshi• 6 years ago

Yep, SVN is simpler and easier for single developer / simplistic projects. GIT is much easier for larger multi developer concurrent development.

I like being able to commit while I am on a plane. (Not that this happens everyday, it’s more about the orinciple)

studius2• 6 years ago

Git is actually simpler, here's why:

No central server to setup or required, period.

Whether it's doing it on your own or sharing with 100 random strangers, you don't have to setup an account for them.

Yes, SVN can handle patching, so you could email those patches also, but it's based on client-server, so someone has to setup the server and add new accounts.

Googlers have used it internally a lot as a client when their central server wasn't that, even though git itself struggled with the scale, which is why they hadn't changed over to it exclusively even server-side. If it was that complex, why would they do that?

ptx• 6 years ago

What makes Subversion easier for single developer projects?

I only remember having to manage a server being annoying. If you're not pushing anywhere, isn't the Git workflow essentially identical, minus the server management chores?

tpoacher2• 6 years ago

so commit on a local repo and merge upstream later. imcrementally if prefered. i don't see the problem here.

pulse7• 6 years ago

SVN is also better at handling (large) repos with (large) binary files than GIT. So if you decide to store your scanned business documents in a version control system SVN is a better solution than GIT. So I use GIT for software projects and SVN for business documents.

SEJeff2• 6 years ago

Indeed. Subversion stores history on a per-file basis and not a per-project basis. This is one of the precious few areas where Subversion does best git.

hannob• 6 years ago

I used to think like that, but have eventually given up.

SVN is easier to learn and much more intuitive to use. But even if you're not a power user you get to its limits quickly. (E.g. svn afair does not support bisecting by itself, though there are external tools.) Given the world uses git you inevitably will have to learn git if you do anything with software.

kergonath4• 6 years ago

I prefer git’s model but you’re right; git commands don’t make any sense. Simple things (push, pull, commit, etc) are simple enough but it gets very quickly quite difficult to use without looking up a similar case on Stack Overflow.

coldpie• 6 years ago

They do make a lot of sense if you understand the underlying model (read gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7)). Its UI could be better, but it's good enough and some tools just require training to use effectively.

d21d3q• 6 years ago

https://xkcd.com/1597/

dunce2020• 6 years ago

I've only ever really used git as a locally hosted SVN.

climb_stealth• 6 years ago

IMO the best part about SVN is that you can use git-svn to run it through git locally.

If only that was a thing for Perforce. There are some scripts but not really with proper streams support. Sigh.

darthrupert• 6 years ago

Welcome to 2010s, FreeBSD!

Avamander4• 6 years ago

Maybe getting rid of annoying to use mailing lists and git-email will be next? Who knows.

cnst7• 6 years ago

What's wrong with mailing lists? Is there anything better for general discussion than the mailing lists?

The problem with forums is that you can't really trust them. They're generally not archived well, UI is poor, editing of old messages can easily get abused (probably the reasons HN removes your ability to edit old messages shortly after posting).

Mailing lists are much less prone to censorship, are better for archival and preservation of knowledge (both for your own local archival, as well as the distributed global archiving of complete archives), interoperable, convenient and easy to use.

---

I mean, just take a look at GitHub issues. It's a total mess. Things get locked and deleted. Links get broken. Attracts thousands of useless comments on popular issues; never any sort of a summary for how the problem is resolved (if at all), the root cause of any issue, or why it won't be fixed. Any time I get a GitHub Issue as a hit, it's usually a total waste of time trying to make sense of it; much more so than the mailing list posts, which often have threading, less spam, and are easier to navigate. Yes, a special interface is a good thing in theory. But it's been a complete mess in practice.

the_only_law3• 6 years ago

Now can we get some of the other BSDs to trash CVS?

Gualdrapo• 6 years ago

Don't think that's gonna happen with OpenBSD. At least not any time soon.

[1] https://marc.info/?l=openbsd-misc&m=157819616927844&w=2

the_only_law3• 6 years ago

Wow this entire thread is just unreal to me. I’ve mostly interacted NetBSD and DragonflyBSD people who were mostly helpful and polite even of you asked what was considered a stupid question.

colejohnson66• 6 years ago

That reply could’ve been worded so much better. The fact that they went with the insult approach is quite off putting.

cnst7• 6 years ago

Which ones? DragonFly BSD has transitioned from CVS directly into Git back in 2008.

OpenBSD probably has no plans to transition.

NetBSD has been testing Fossil, Git, Mercurial, for about over a decade now, yet somehow as of 2020 the sight is currently set on Mercurial (even though the current Git export is done through Fossil, continuously since at least 2011); whilst CVS still remains the only official master repo. http://wiki.netbsd.org/github/

HugoDaniel• 6 years ago

Why? What are you missing from their current CVS usage that you think might be improved with git? Can you provide examples on their CVS usage that are proper arguments to why is it outdated or should be transitioned from?

the_only_law3• 6 years ago

Admittedly not really. It’s mildly annoying that CVS clients tend to be rather different across operating systems, whereas the standard git client is pretty consistent wherever I am, though.

cnst7• 6 years ago

Prior discussion from a week ago:

https://news.ycombinator.com/item?id=25460544

I'm glad it's finally been done!

Looks like GitHub still has the old export as of 2020-12-24T15:30Z, but 5ef5f51d2 dated 2020-12-23T04:27:27Z marks the start of Git history for FreeBSD src!

https://wiki.freebsd.org/git

Freaky3• 6 years ago

As the maintainer of FreshBSD.org, git gives me headaches regarding what to do with branch naming.

SVN and even CVS include branch information on each commit, but git couldn't care less - it's up to you to infer it by unspecified means if you really care.

It's telling that the conversion metadata includes tags indicating the SVN path identifying the branches a given commit was made from - because this otherwise wouldn't be available. In principle I can just use that, but I still need a reliable solution for new commits.

Not convinced I'll find one.

cnst7• 6 years ago

Isn't the reason for the problem is that multiple branches and tags may have any given commit? Same as in CVS? It seems like the problem is the UI that assumes that only a single branch may have any given commit.

---

BTW, whilst at it, any chance you can fix search by user-id? Currently freshbsd.org/search?project=freebsd&committer=phk doesn't produce the expected results.

Freaky3• 6 years ago

No. The problem is that to git, a branch is just a reference to the commit currently at the tip of that branch - the rest of the commit graph is completely anonymous sans its position in that graph.

Where in SVN it's implicit in the paths a commit touches and in CVS it's a specific field in the RCS metadata for a commit, in Git it's a big graph problem it isn't overly interested in solving.

And yes, people keep asking about the legacy username thing - I'll get to it :)

xxpor2• 6 years ago

git name-rev?

Freaky3• 6 years ago

Only handles a single symbolic name per commit, and doesn't necessarily pick one that's meaningful in that sense. It's what I'm trying to get away from.

e.g. projects/aio_writev has 8 commits, but if name-rev is allowed to name that branch, it'll gleefully use it to name thousands of commits to main as well.

FreeBSD src repository has transitioned from Subversion to Git

Related Stories