FreeBSD Begins Switch to Subversion 120
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."
Re:GIT? (Score:5, Informative)
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? (Score:5, Informative)
Re:GIT? (Score:2, Informative)
Re:GIT? (Score:5, Informative)
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:dead... (Score:3, Informative)
A talk he did on it [youtube.com]
http://en.wikipedia.org/wiki/Git_(software) [wikipedia.org]
Re:GIT? (Score:3, Informative)
GPL imposes limits on you only if you distribute GPL code (or the result of its compilation)
Re:dead... (Score:5, Informative)
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:GIT? (Score:4, Informative)
Googlefight! [googlefight.com]
git tutorial: 512,000 results
mercurial tutorial: 1,100,000 results
Winner: Mercurial!
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] Installing a Cygwin environment is not a supportable solution for most corporations. They needed native solutions. Something which has begun to appear.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:dead... (Score:5, Informative)
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:dead... (Score:3, Informative)
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 back to another fork (presumably a dev trunk somewhere). As an example, check out this visual representation of the many forks of the Rails project on Github: http://github.com/rails/rails/network [github.com]
Re:GIT? (Score:1, Informative)
git tutorial: 589,000 Results
mercurial tutorial: 680,000 Results
"git tutorial": 5,890 Results
"mercurial tutorial": 647 Results
Re:GIT? (Score:4, Informative)
Re:GIT? (Score:1, Informative)
'No results found for "tutorial on mercurial".'
"tutorial on git": 323 Results.
Re:CVSup (Score:3, Informative)
PORTSNAP(8) FreeBSD System Manager's Manual PORTSNAP(8)
NAME
portsnap -- fetch and extract compressed snapshots of the ports tree
Re:Perforce (Score:3, Informative)
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 capabilities of CVS and it can be integrated in the current distribution framework.
Oh, and it understood most of the FreeBSD CVS Repository
Re:CVSup (Score:3, Informative)
Re:GIT? (Score:1, Informative)
"Git is easier to learn than Mercurial as evidenced by the sheer ammounts of Mercurial tutorials that seem to be needed"
(Disclaimer: This is not my personal opinion. Just to demonstrate the uselessness of this data. But flame away anyways if you have bad eyesight, I'll actually be doing something worthwhile in the meantime.)
Re:GIT? (Score:3, Informative)
Re:dead... (Score:3, Informative)
Re:dead... (Score:3, Informative)
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 available GUIs aren't adequate but the command line is unsuitable), that's something which will need to be taken into consideration.
For a Windows shop where you need the best available GUIs, Subversion has the stability you need right now -- but you're missing out on functionality which can save a lot of headaches later (when, say, you try to merge between a branch where you did a mass renaming and one where you didn't... though Git doesn't always handle this one well either, Bazaar takes care of it beautifully). SVN 1.5 will be slightly better along those lines, and bzr-svn (allowing Bazaar to integrate with Subversion repositories) can help your UNIX power users take advantage of distributed revision control's advantages while still keeping all the SVN shininess available for your Windows folks.
That said -- SVN set out to be the best replacement for CVS it could possibly be. It's a very nice, very polished replacement for CVS -- but that's not the same thing as "the best revision control system it could possibly be"; distributed workflows have some nontrivial advantages even in centralized environments; look at the PQM the Bazaar folks use to manage their own project for a prime example.