FreeBSD Begins Switch to Subversion

An anonymous reader writes "The FreeBSD Project has begun the switch of its source code management system from CVS to Subversion. At this point in time, FreeBSD's developers are making changes to the base system in the Subversion repository. We have a replication system in place that exports our work to the legacy CVS tree on a continuous basis. People who are using our extensive CVS based distribution network (including anoncvs, CVSup, cvsweb, ftp) will not be interrupted by our work-in-progress. We are committed to maintaining the existing CVS based distribution system for at least the support lifetime of all existing 'stable' branches. Security and errata patches will continue to be made available in their usual CVS locations."

CVSup

[bsDaemon (87307)]

I don't have any experience with Subversion, so I don't know if this is going to be "better" or not -- but will CVSup still work more or less the same once the migration is complete?

Re:

[Hatta (162192)]

It will be replace with SVNup.

Re:

[cperciva (102828)]

For the forseeable future, yes. Commits to SVN are being replicated into CVS, so all the existing CVS infrastructure will continue working.

Re:

[MavEtJu (241979)]

If you are still using CVS, or CVSup, for updating your ports tree, I suggest you have a look at portsnap(8):

PORTSNAP(8) FreeBSD System Manager's Manual PORTSNAP(8)

NAME
          portsnap -- fetch and extract compressed snapshots of the ports tree

Re:

[kv9 (697238)]

Likely, all you will need to do with subversion is this: > cd /usr/ports > svn update ... come back later to an updated portage tree.

heathen!

Re:

[bsDaemon (87307)]

yes, it is sort of a slow-ass bitch. I'm just dealing with it for right now. I'll probably fix it this weekend.

GIT?

[liquidpele (663430)]

Wonder why they went with subversion over GIT?

Re:GIT?

[bark (582535)]

They don't use git because FreeBSD development has traditionally been "centralized". They use a model where patches are fed to a group of core developers with "commit permission" to the tree, and all source changes are vetted and fed through that funnel. Subversion's centralized source control methodology works well with the FreeBSD development process, and the decentralized aspects of git is not needed.

However, of course, there is still some distributed coding going on at the edges, but they tend to be peripheral and experimental. The developers working on these experimental branches can choose to use whatever source control system they wish. Many FreeBSD developers prefer perforce for their experimental work, but they can use git or mercurial if they wish.

Re:GIT?

[LurkerXXX (667952)]

Subversion has an Apache/BSD type license. GIT does not.

Re:

[compass46 (259596)]

That wasn't any factor in the discussions about the switch as I remember. It was mostly, "What do people like and what will satisfy the most people."

Re:

[krelian (525362)]

http://reddit.com/r/programming/info/6lzue/comments/c048e6q [reddit.com]

There are other informative comments by that guy over there if you are interested.

Re:GIT?

[AKAImBatman (238306)]

GIT lost the version control war early on. Its focus on Linux development with little to no support for Windows and Mac made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. GIT was developed to meet the needs of the Linux Kernel Project. If it happens to meet the needs of other projects, great. If it doesn't, that's just as fine.

In any case, Mercurial [wikipedia.org] ended up being the "best of breed" solution. It offered all the features of the competing version control systems, was portable across platforms, had a significant toolchain appear practically overnight, and is used by HUGE OSS companies like Sun and Mozilla. I've used it in my own projects and have found that it is much easier and more dynamic than the classic, monolithic model of CVS.

Oh really?

[krog (25663)]

Thanks for promptly settling the SCM dispute! Now I'd love to hear your ideas on which text editor is the best.

Re:Oh really?

[0xABADC0DA (867955)]

VI lost the editor war early on. Its focus on text files with little to no support for email or shell prompts or playing text-mode hangman made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. VI was developed to meet the needs of text editing. If it happens to meet the needs of other activities, great. If it doesn't, that's just as fine.

In any case, EMACS ended up being the "best of breed" solution. It offered all the features of the competing editors, was portable across platforms, had a significant tools (and games) appear practically overnight, and is used by HUGE OSS icons like RMS. I've used it in my own projects and have found that it is much easier and more dynamic than the classic, command/insert model of VI.

har, har...

Re:

[bsDaemon (87307)]

EMACS isn't an editor. It's a LISP machine implemented in software that happens to have a text editor program for it.

Re:

[krog (25663)]

EMACS isn't an editor. It's a LISP machine implemented in software that happens to have a text editor program for it.

You make it sound so haphazard! Emacs needed a text-editor; otherwise, how could it be completely self-hosting? Any program that can't bootstrap itself can fuck itself.

Re:

[hawk (1151)]

EMACS has an editor?

I guess we can finaly put away the old complaint about being a great OS in need of a good editor . . .

hawk

Re:

[ari_j (90255)]

Emacs only has an editor because the default keybindings, purely by luck or possibly because that seemed convenient at the time, happen to implement one. The problem is that none of the Emacs developers can come to any kind of agreement on better default keybindings.

Re:Oh really?

[WK2 (1072560)]

Yes, EMACS has an editor. Vi runs in EMACS.

Re:

[mTor (18585)]

GIT lost the version control war early on. Its focus on Linux development with little to no support for Windows and Mac made it unpopular. That's a situation that has changed (somewhat), but the stigma is still attached to it. Which is not really a problem. GIT was developed to meet the needs of the Linux Kernel Project. If it happens to meet the needs of other projects, great. If it doesn't, that's just as fine.

Huh? Git didn't have windows support very early on but very soon you could compile it with Cygwi

Re:

[by Anonymous Coward]

Debian's popcon agrees with this synopsis.

Basically, in the first year or so of the "distributed SCM revolution" in 2005, Mercurial was in the lead. However in mid 2006 git passed it by, and took off exponentially. At the moment Mercurial usage is about half that of git. It looks like within a year or so git will pass rcs and soon after that cvs, to become the second most popular scm after svn.

It seems that in general, Mercurial is chosen by comities (Solaris, Mozilla etc.) as it offends the least number

Re:

[AKAImBatman (238306)]

If you go by Debian's popcon, Subversion has already kicked both our asses and we should all go home:

http://people.debian.org/~igloo/popcon-graphs/index.php?packages=darcs%2Cgit-core%2Cmercurial%2Cbzr%2Csubversion%2C+cvs&show_installed=on&want_legend=on&want_ticks=on&from_date=2003-10-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 [debian.org]

Re:GIT?

[AKAImBatman (238306)]

To reply or not to reply? I suppose replying probably won't assuage your holy quest, but here we go.

As for Hg, it's lost the war. Git has won. If you want proof, try some searches for "git tutorial" and "mercurial tutorial" and see who's winning.

Ready?
Googlefight! [googlefight.com]

git tutorial: 512,000 results
mercurial tutorial: 1,100,000 results

Winner: Mercurial!

Also, Google Code now provides Git repos for almost ALL of the projects.

Google doesn't provide JACK for GIT. GIT uses SVN. In order to use GIT with Google, you need to have a GIT->SVN translator:
http://nigel.mcnie.name/blog/using-git-for-your-sourceforgegoogle-code-project [mcnie.name]

Git didn't have windows support very early on but very soon you could compile it with Cygwin.

Installing a Cygwin environment is not a supportable solution for most corporations. They needed native solutions. Something which has begun to appear.

Target audience were Linux hackers so having support for various other systems wouldn't have done much at all.

I agree with you wholeheartedly. The target audience is Linux hackers. They are the ones using GIT. The business world, OTOH, has chosen Mercurial. Such is the way of things.

Re:GIT?

[mTor (18585)]

You should ALWAYS use quotes for specific phrases. if you've done some SEO work or actually tried paying for AdWords, you'd realize how important phrase searches are on Google.

Re:

[macshit (157376)]

in short, Git has already won and expect it to be the biggest source code versioning system in less than two years from now.

Indeed. Hg had an early boost from large organizations (e.g. sun), apparently because of it's better windows support at the time, but it seems clear that git has the majority of mindshare these days, especially in the FOSS world.

Here's a graph of scm system on usage on debian [debian.org] which made the rounds recently (note this is based on "popcon" statistics, which measure use of each tool). The top two descending lines are CVS and SVN; the third-from-the-top ascending line is git; the rest of the lines incluc

Re:GIT?

[Fweeky (41046)]

Path of least resistance; it works much like CVS, it fits in with existing infrastructure, and everyone knows how to use it.

git isn't terribly well suited to very large monolithic projects; you need to split into multiple smaller projects since it tracks entire trees rather than single files. When your tree is 1.3GB+ and has upwards of quarter of a million files that's rather painful either way.

It also isn't well suited to rewriting history, e.g. in the case when you have to remove a changeset because it violates someone's patent or copyright; you can rewrite the repository to remove it, but you end up renaming every commit afterwards, since their names are SHA1's dependent on every previous commit, generating tonnes of churn in many different places as the whole of history basically disappears and reappears elsewhere.

Many of git's advantages can still be leveraged with SVN; git-svn works pretty well, and it doesn't require massive upheavals in all areas of the project.

Re:GIT?

[Chemisor (97276)]

Well, if you believe Linus, it must be because they are ugly and stupid :)

Re:

[norkakn (102380)]

http://video.google.com/videoplay?docid=-4400856579609253323&q=structure+of+freebsd&ei=k-VGSJH-DZT44gK5-YmZDA [google.com]

Towards the end he talks about it.

Why GIT?

[argent (18001)]

FreeBSD's development model isn't all that similar to Linux, so why do you think they should use a tool designed to support a very different model?

Re:

[tuffy (10202)]

Emacs is also GPLed, but that doesn't mean everything I write with it is also automatically GPLed. Unless the BSD people are planning to become Git developers, the source license makes no difference. Try reading it sometime.

Re:

[Calinous (985536)]

You can use a GPL licensed product in any way you wish.
  GPL imposes limits on you only if you distribute GPL code (or the result of its compilation)

Subversion, eh?

[cwsulliv (522390)]

That headline will undoubtedly draw the attention of the FBI to the FreeBSD gang.

Re:

[mini me (132455)]

SVN really is dead. While I could understand the move a few years ago, SVN is antiquated technology now. I'm not sure why anyone would want to use it in a new rollout when there are newer and significantly better options available now.

Re:

[FictionPimp (712802)]

such as what?

Seriously, We are looking at setting up SVN for our source code management.

Re:

[AmaDaden (794446)]

Git. It's Linus Torvalds fix for his own software management nightmare with the Linux Kernel.
A talk he did on it [youtube.com]
http://en.wikipedia.org/wiki/Git_(software) [wikipedia.org]

SVN is better for FreeBSD development

[bigsmoke (701591)]

Contrary to Linux, FreeBSD uses a centralized development methodology which SVN is very well-suited for. (Now, if only they hurry up with the stable release of their merge-tracking, I could say that Subversion is perfect for a centralized development model.)

Then, there's the obvious licensing issue. GIT is released under the GPL, which, I'd guess, is a little too restrictive for BSD-style people. :P

Re:

[Lost+Found (844289)]

Isn't GCC under the GPL as well? :p

Re:

[bigsmoke (701591)]

Good point... :P

Re:dead...

[AKAImBatman (238306)]

Mercurial [wikipedia.org] is the solution currently in use at Mozilla, Sun, and quite a few Linux projects. (Though not the main kernel branch. That's GIT. Think something more along the lines of ALSA.)

Mercurial is interesting because it encourages teams to work together, pushing and pulling source code from each other. When the source reaches a stable point, you can push that to a central repository for building and archiving.

The interesting aspect about this design is that it actively encourages branching! Rather than treating branches as a special thing that needs to be done under a certain set of circumstances, it treats every copy of the repository as a branch. So developers can work independently. When they come back together, the tool is able to auto-merge most projects back into a single whole.

Mercurial is able to do this because it tracks the point of divergence. With that information, it can see if any of the changes truly conflict. 95% of the time, there is no conflict and Mercurial is able to merge the files auto-magically. The other 5% of the time, Mercurial will launch a merge tool and make you answer YES/NO to each difference. This process is amazingly smooth.

The key thing to keep in mind with Mercurial is that you won't want to keep all your source in one repository. (Like most companies do with CVS.) Keep a separate repository for each project or module. You can keep the repositories all in the same path, but it's much easier to work with only the code you need rather than copying around a 10GB source tree from developer to developer.

If you do decide to try Mercurial and are given a Windows development machine, I highly recommend TortoiseHG [sourceforge.net]. You'll occasionally have to run 'hg update' from the command line (the tool will prompt you), but it's otherwise a very slick way of working with Mercurial repositories.

Oh, and don't use the CVS->Mercurial conversion tools. It leaves CVS-style droppings all over creation. Just import the latest codebase and keep CVS running in read-only mode for as long as you need historical data.

Re:

[PotatoFarmer (1250696)]

I've never used Mercurial before, so I don't know if the comparison fits exactly, but the branch/merge style of development you've described can be done very easily within CVS and SVN. That sort of thing is much cleaner in SVN as you're branching from a base repository revision rather than from a tag that can be moved/reapplied, but it's possible if you're careful in CVS as well. From there, it comes down to personal preference with regard to whatever merge tool you care to use.

I greatly prefer that sty

Re:

[Ian_Bailey (469273)]

It is definitely possible to do branch/merge work with CVS/SVN, but you need to track the merge points yourself, and be aware not to merge the same changeset twice. Git and Mercurial make the process far easier by tracking merge points for you.

Also, one big thing distributed source control gives you is the ability to "clone" or "fork" your own copy of the repository. This lets you make small, incremental changes that you can roll-back and merge back as you like, and then you can "push" all of your commits b

Re:

[A nonymous Coward (7548)]

Unless it has been fixed recently, subversion does NOT track merge points. If you branch at revision 1000, merge the head into the branch at revision 2000, and want to do it again at revision 3000, you yourself have to remember to tell it to start at revision 2000, otherwise it will remerge all those already merged revisions from 1000-2000. It's a major pain in the butt and utterly inexcusable to have to manually track that, whether you do it in subversion comments, notes in external files, or postits.

Re:

[liquidpele (663430)]

Wait, what? If you're merging again into the branch at revision 3000, it would merge with whatever level that branch was at... I'm not following what you're trying to say here.

Re:

[Timothy Brownawell (627747)]

I think any distributed version control system (ie, pretty much all the new free ones except SVN) will encourage branching, lack of a central authority just about requires this.

Re:

[amrik98 (1214484)]

Mercurial [wikipedia.org] is the solution currently in use at Mozilla, Sun, and quite a few Linux projects. (Though not the main kernel branch. That's GIT. Think something more along the lines of ALSA.)

ALSA does not use Mercurial any more, they switched to GIT on 2008-05-20.

Re:dead...

[Jason Earl (1894)]

If you are used to CVS then Subversion is definitely a step up, and it will be very familiar to your users. What's more it is well supported by IDEs and has piles of other tools like Tortoise that makes it easy for non-developers to use. Heck, if push comes to shove it can even be used as a WebDAV share with the advantage that it will automagically version your files.

The downside of Subversion is that it isn't very good at merging. Merging branches in current versions of Subversion is a manual process that is ridiculously painful. This can be mitigated somewhat using the svnmerge Python script, but even with the script merging still isn't as easy as any of the distributed version control systems. For people like Linus Torvalds that's basically a showstopper for Subversion. To them merging is basically the whole point of a version control system.

It's quite possible, however, that you have different needs than the Linux kernel. For example, none of the distributed version control systems deal well with large files. If you want to store multi-media files along with your source then Subversion is basically your only option. Likewise, if you plan on having designers or random office workers use your repository then you can forget about the distributed tools.

Re:

[Jack9 (11421)]

Everyone we hire is either already experienced with SVN or picks it up in about 5 minutes. I don't know what the OP is smoking.

Re:

[A nonymous Coward (7548)]

Any distributed one. The first time I tried one (darcs), it blew me away how much easier and stress-free it felt. Like a fresh breeze on a hot muggy day. Darcs has a remaining problem (some specific kinds of actions can take waaaay too long) so altho I still use it for myself, I would not recommend it for massive projects (yet; they are working on it), but git or any number of other distributed systems are so much easier and friendlier than subversion.

Subversion is the best horse buggy you can get, much

Re:

[cduffy (652)]

Windows or Unix shop? How large do you expect your repository's history to get (in terms of revisions per year)?

For a UNIX shop with a very deep history, you're going to be best off with Git.

For a UNIX shop without an exceptionally deep history, Bazaar (Canonical's revision control system) is worth considering. It works well on Windows, but the GUIs there are immature -- so if you're not a UNIX shop and your Windows folks are revision control power users who hate the command line (for whom the currently ava

Re:

[MavEtJu (241979)]

There are different tools for different purposes:

CVS is (was) what the central repository uses to store the software.

Perforce is a central repository for internal development. That way the limitations of CVS for this part of the job don't limit the developers.
But Perforce is commercial software and you can't push it on to the community.

Subversion is a free software which has the capabilities which are set as a requirement for the FreeBSD project. It has some capabilities of Perforce, it has some capabilitie