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."
CVSup (Score:2)
Re: (Score:1)
Likely, all you will need to do with subversion is this:
> cd
> svn update
CVS would probably be that simple, but for it's need for you to 'log in' and some strange (to me) syntax. CVSup eliminates that weirdness.
Of course, I'm sure that CVSup does a lot of extra stuff I don't know
Re: (Score:1, Offtopic)
PC-BSD will auto-detect and install nvidia; it started the nvidia crap when i put up a livecd on my laptop the other day, but i didn't install it 'cause I don't want to fuss with removing all the KDE stuff.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3, Informative)
PORTSNAP(8) FreeBSD System Manager's Manual PORTSNAP(8)
NAME
portsnap -- fetch and extract compressed snapshots of the ports tree
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Funny)
Re: (Score:1)
Re: (Score:1)
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?
Yes. For now, they're automatically pushing all SVN commits into CVS. That way, the old CVS distribution infrastructure will continue to work. An insightful email from the guy doing the conversion can be found here [freebsd.org].
Re: (Score:2)
Re: (Score:3, Informative)
Re: (Score:1)
FreeBSD is dying? (Score:1, Redundant)
Maybe not...
Here's hoping they have better luck than some of the switchovers I've had the "privilege.
Comment removed (Score:5, Interesting)
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: (Score:3, Informative)
Re: (Score:2)
There are other informative comments by that guy over there if you are interested.
Re:GIT? (Score:4, Interesting)
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? (Score:5, Funny)
Re:Oh really? (Score:5, Funny)
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: (Score:2)
Re: (Score:2)
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: (Score:3, Funny)
I guess we can finaly put away the old complaint about being a great OS in need of a good editor . . .
hawk
Re: (Score:2)
Re:Oh really? (Score:4, Funny)
Re: (Score:2)
Oh wait, did I just say that on a FreeBSD thread?
Re: (Score:2)
I don't much care for LISP, honestly.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3, Interesting)
Huh? Git didn't have windows support very early on but very soon you could compile it with Cygwi
Re: (Score:2, Interesting)
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: (Score:3, Interesting)
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: (Score:2)
Granted, Debian popcon does not account for all the windows VCS installs, which you claim is Mercurial's strong territory.
Nevertheless, it's interesting that in the Unix world, Git is the strongest up-and-comer, so the fight isn't as clear-cut as you claim it is.
Re: (Score:2)
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: (Score:1, Informative)
git tutorial: 589,000 Results
mercurial tutorial: 680,000 Results
"git tutorial": 5,890 Results
"mercurial tutorial": 647 Results
Re: (Score:1, Insightful)
Re:GIT? (Score:4, Informative)
Re: (Score:1, Interesting)
To give an example, this will be found with "git tutorial" in quotes:
"Click here for a git tutorial!"
However, it's rather clunky english. This sounds much better...
"Click here for a tutorial on mercurial"
Statistics != SEO != Adwords
Re: (Score:1, Informative)
'No results found for "tutorial on mercurial".'
"tutorial on git": 323 Results.
Re: (Score:1)
Re: (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: (Score:2)
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: (Score:1)
But it's okay, implying that Mercurial had early Windows support is almost as laughable. When did TortoiseHg begin development, December?
Re: (Score:1)
Cheers,
Roger
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:GIT? (Score:5, Funny)
Re: (Score:2)
Towards the end he talks about it.
Why GIT? (Score:2)
Re: (Score:1)
Re: (Score:2, Informative)
Re: (Score:3, Informative)
GPL imposes limits on you only if you distribute GPL code (or the result of its compilation)
Re: (Score:1)
FreeBSD currently distributes two tools to update the ports tree: csup and portsnap. With SVN, they could get the efficiency of csup with the simplicity of portsnap, while also adding all the features of proper source control. But if their tools of choice aren't BSD licensed, they can't include them in the distribution.
(There is one very good reason they
Re: (Score:2)
If your logic was correct, then playing music through a sound card with GPL drivers would make the music GPL, and compiling programs with a GPL compiler (like GCC) would make them GPL, and writing a book in a GPL text editor would make it GPL. That's not the case.
GIT's GPL license applies to GIT itself, not the code it distributes.
Perforce (Score:1)
Re: (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 capabilitie
Subversion, eh? (Score:2)
Re: (Score:2, Insightful)
Re: (Score:2)
Seriously, We are looking at setting up SVN for our source code management.
Re: (Score:3, Informative)
A talk he did on it [youtube.com]
http://en.wikipedia.org/wiki/Git_(software) [wikipedia.org]
SVN is better for FreeBSD development (Score:3, Interesting)
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: (Score:3, Interesting)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Thanks for your elucidation. I've also been using Git a bit recently (for the same reasons you state) and have found it very satisfactory so far. Of course it'll take some time to familiarize myself with it to the same level of familiarity that I have with svn.
Re: (Score:2)
Re: (Score:2)
Thanks for the tips. I'll put them down for later reference.
I've been mostly introduced to it by the following Google Techtalk by Linus: http://www.youtube.com/watch?v=4XpnKHJAok8 [youtube.com] This is also very much a recommendation.
Re: (Score:2)
My bad. I see you already linked to that techtalk in your original reply.
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: (Score:2, Interesting)
I greatly prefer that sty
Re: (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 b
Re: (Score:1)
I agree with you on the distributed source control bit - that sounds like a nice
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Now, again months later, you are at rev 3000 on the trunk and again want to update the branch with all changes to the trunk that are not in the branch, ie, revs 2001...3000. Subversion ought to remember that this branch was brought up to rev 2000 changes, but it doesn't. Since I no longer use
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Integrates in windows explorer. Setting up a server might take a bit of fiddling, but if you have a linux box svn+ssh just works.
Re: (Score:2)
I think with more than two hours you could do things the way you wanted, or discover a better way of doing things that Visual studio will allow. Visual Studio is one of the better microsoft products.
Re: (Score:2)
I discovered by accident that if you brought up help on something, there were sometimes links to click which added stub code to a source file. Then you would edit that source file to add the filling.
Now I don't like lots of windows open, so I wanted to get rid of these source windows when I had added the filler, but there was no
Re: (Score:2)
If you use the svnmerge script (shell or python versions exists), 1000-2000 will be marked merged. One can also block revs not to merge.
It works reasonly fine, but the problem is that it doesn't work properly on windows. Or at least in a straightforward way if you are using e.g. tortoise + plink.
SVN 1.5 would lay the foundations for merge tracking in the repository, but in how quickly this will be usable and an improvement (read: support all functionality of svnmerge in tortoise) I don't know yet.
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
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: (Score:3, Interesting)
Re: (Score:2)
Subversion is the best horse buggy you can get, much
Re: (Score:2)
Seriously, We are looking at setting up SVN for our source code management.
Basically, you need to decide how much you value distributed development (using git or the others like Hg) as opposed to more centralized SCM tools like Subversion.
For us, SVN is the natural fit when moving from VSS/SourceOffSite to something better. A centralized repository is a strong feature for us as it simplifies management, is easily understood by less technical end-users, and we don't do a lot of merging.
Re: (Score:2)
Re: (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 ava
Re: (Score:2)
We are going to investigate git before we make a decision, but from what I'm reading SVN might be best for us. We have a lot of users who are more comfortable with dreamweaver then a terminal, so SVN's gui tools will fit them better.
Re: (Score:2)
I have a project hosted on Google Project Hosting, and that uses subversion. It's pretty darn good as far as I can tell. It's stable, has a decent base of applications that you can use with it, and there's plenty of documentation out there.
There certainly are plenty of version control systems out there, but, especially when it comes to version control, newer does not mean better automatically.
What matters ultimately is how well liked and widely used they are.
Re: (Score:1)
I don't think anyone would question FreeBSD switching to Subversion in 2006 either. But it's 2008 now. Things have changed significantly on the VCS front.