×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

FreeBSD Begins Switch to Subversion

timothy posted more than 5 years ago | from the subvert-the-dominant-paradigm dept.

Data Storage 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

120 comments

dead... (0)

Anonymous Coward | more than 5 years ago | (#23656143)

etc. Let's just get it out of the way.

Re:dead... (2, Insightful)

mini me (132455) | more than 5 years ago | (#23656271)

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:dead... (1)

FictionPimp (712802) | more than 5 years ago | (#23656439)

such as what?

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

Re:dead... (2, Informative)

AmaDaden (794446) | more than 5 years ago | (#23656561)

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 (2, Interesting)

bigsmoke (701591) | more than 5 years ago | (#23660281)

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:SVN is better for FreeBSD development (2, Interesting)

Lost+Found (844289) | more than 5 years ago | (#23660891)

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

Re:SVN is better for FreeBSD development (1)

bigsmoke (701591) | more than 5 years ago | (#23661525)

Good point... :P

Re:SVN is better for FreeBSD development (0)

Anonymous Coward | more than 5 years ago | (#23666527)

As I've understood it, it's tolerated for the lack of good alternatives. Don't be surprised if one of the alternative compilers get official support (and maybe at some point gets imported into base) sometime in the future. :)

I seem to remember that NetBSD wanted to move to PCC (which happens to be BSD-licensed, though the main reason was that it seemed easier to keep support for all their architectures in the same compiler version with it). I haven't looked at the status of that, but if it works well I imagine Free- and Open- might be interested.

Re:SVN is better for FreeBSD development (0)

Anonymous Coward | more than 5 years ago | (#23662219)

Git can be treated as a centralized repository as well, without all the problems (not just merging) that comes with Subversion.

Re:SVN is better for FreeBSD development (1)

AmaDaden (794446) | more than 5 years ago | (#23667205)

Linux uses a kind of centralized development methodology. The Linux Kernel we get is really Linus' branch. He does not write code anymore he only checks it and merges it in to his branch. The trick with git is you commit it to the person above you and not to a repository. This way your boss can pick and choose what fixes and updates from you and others at your level get pushed up to your bosses boss. In the end it all gos to one place. If you really wanted to every one could just use the same person as there boss so it would all just get lumped together and work just like SVN or CVS. As I understand it git was also designed to allow for you to do commits to an SVN or CVS repository.

Any programmer who does not know about git should look in to it. I get the feeling it's what people will be moving to.

Re:dead... (4, Informative)

AKAImBatman (238306) | more than 5 years ago | (#23656709)

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:dead... (2, Interesting)

PotatoFarmer (1250696) | more than 5 years ago | (#23657385)

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 style of development myself, as it tends to keep the trunk much cleaner, and allows a code reviewer to concentrate on specific changes in a given branch rather than worrying about the stability of the codebase as a whole. Of course, old branches can be a bitch to merge if you've got really active development, but there's probably no way around that no matter what tools you're using.

Re:dead... (2, Informative)

Ian_Bailey (469273) | more than 5 years ago | (#23658081)

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 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:dead... (1)

PotatoFarmer (1250696) | more than 5 years ago | (#23658613)

I'm not sure what you mean by tracking the merge points yourself - the act of branching in SVN automatically bumps the version number for the entire repository, both trunk and branch. That version is then automatically assumed to be your base point for your diff and subsequent merge. It's messier in CVS, but unless I'm misunderstanding what you mean by merge point I don't see how SVN is different from what you've described.

I agree with you on the distributed source control bit - that sounds like a nice advantage over more traditional repositories.

Re:dead... (1)

A nonymous Coward (7548) | more than 5 years ago | (#23661965)

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:dead... (1)

liquidpele (663430) | more than 5 years ago | (#23662717)

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:dead... (1)

A nonymous Coward (7548) | more than 5 years ago | (#23664147)

You create a branch at rev 1000. At rev 2000, months later, you want to update the branch with all changes that have been applied to the trunk since the branch was made or last updated. So you merge in 1001...2000.

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 subversion branches because of this nonsense, I cannot tell you now whether it merges in since 1 or from the branch start (1000) but I do know that it doesn't know squat about rev 2000, and it ought to. You have to manually tell it to only merge from 2001 up, not 1 or 1000.

If you screw it up, some revs get merged twice or not at all. Suppose you tell it to merge from 2002 on up -- the changes from rev 2001 will not be applied. Or tell it 2000 and it will merge that rev twice.

Re:dead... (1)

liquidpele (663430) | more than 5 years ago | (#23666747)

I see you're point, and you are correct that if that's the way it's done, it's retarded. I'll have to test that out today and see if it fucks up... Thanks for the explanation!

Re:dead... (1)

A nonymous Coward (7548) | more than 5 years ago | (#23666901)

When I (have to) use Subversion, and need the equivalent of a branch, I just cp -a my checked out trunk and switch between the copies. They aren't really branches, but they are close enough most of the time as long as it's just me working on them. They do no good for letting other people access my "branch". I really detest Subversion branches.

Re:dead... (1)

marcovje (205102) | more than 5 years ago | (#23665633)


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:dead... (0)

Anonymous Coward | more than 5 years ago | (#23658871)

Can you explain that better? We use Perforce where every project gets its own branch from the main-line and it is the responcibility of the project owner to keep it up to date. Integration is easy - you just resolve any conflicting changes and the repository keeps track of the versions. We then allow the SCM team to control the trunk and integrate project branches in when they are ready to go into the next release/QA train.

That approach is really nice for a centralized corporate SCM. My understanding of distributed SCMs was mostly that forking and version history was cleaner so you can fork off someone else's branch, integrate back into a different branch, etc and not have dependancy hell due to where the parent came from.

Re:dead... (2, Insightful)

Timothy Brownawell (627747) | more than 5 years ago | (#23657581)

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:dead... (3, Informative)

amrik98 (1214484) | more than 5 years ago | (#23663281)

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... (4, Informative)

Jason Earl (1894) | more than 5 years ago | (#23658055)

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... (2, Interesting)

Jack9 (11421) | more than 5 years ago | (#23660231)

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:dead... (0)

Anonymous Coward | more than 5 years ago | (#23665695)

Very good point. SVN has finally pulled a lot of VSS people over to open source RCS in a way that the others never could.

What I've seen of git seems to indicate it is not for the feint of heart (iow, if you are not in Linus league, don't start with it)

Re:dead... (1)

A nonymous Coward (7548) | more than 5 years ago | (#23661923)

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 better than CVS, which is a major step up from the handcart that is RCS. But distributed systems are like cars compared to subversion.

Re:dead... (1)

WuphonsReach (684551) | more than 5 years ago | (#23663849)

such as what?

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. Plus we work with a lot of binary files (50-200MB at times), which SVN handles very cleanly and efficiently. Our users pick up TortoiseSVN very quickly, and there are options such as WebDAV or other ways to access the repository.

(And merging is getting better treatment in the 1.5 revision of SVN which is due out any day now. The SVN team just notified the user base of Release Candidate #8 for v1.5 this week. There are more plans in 1.6 for continuing to improve merge functionality.)

Our major complaints with SVN are (mostly) being addressed in the upcoming 1.5 release.

Re:dead... (1)

FictionPimp (712802) | more than 5 years ago | (#23666309)

Yea, we really like the TortoiseSVN. Plus we have a need to store a lot of graphics and other binary files in our repo as well as code (we do a lot of web development and want to keep all resources together). I think SVN is still our best bet.

Re:dead... (0)

Anonymous Coward | more than 5 years ago | (#23657065)

SVN really is dead.
Does netcraft confirm it?

Re:dead... (1)

thermian (1267986) | more than 5 years ago | (#23666287)

If it's so dead, why do Google use it?

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.

CVSup (1)

bsDaemon (87307) | more than 5 years ago | (#23656149)

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:CVSup (1)

X0563511 (793323) | more than 5 years ago | (#23656527)

It should - the operation CVSup performs is a core function of version control, but wraps some CVS details up.

Likely, all you will need to do with subversion is this:
        > cd /usr/ports
        > svn update ... come back later to an updated portage tree.
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 about - I haven't looked at it much and have only used FreeBSD in passing (damn nvidia drivers don't work in freebsd 64-bit - some kernel "bugs")

Re:CVSup (0, Offtopic)

bsDaemon (87307) | more than 5 years ago | (#23656589)

I haven't even bothered trying to mess with the nVidia driver -- generic vga displays just fine. Then again, I'm using WindowMaker and have no intention of messing with compiz. i tried it on mint, but it kept crashing... i don't even care if i'm wasting 512mb of video ram...

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:CVSup (1)

X0563511 (793323) | more than 5 years ago | (#23658451)

Well, in my experience vga is just too slow, even for mundane stuff. Also, I like to mess with graphics and such - and even just updating the screen in a timely manner is nice (vga is ssllooww!!))

Re:CVSup (1)

bsDaemon (87307) | more than 5 years ago | (#23658521)

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.

Re:CVSup (2, Informative)

MavEtJu (241979) | more than 5 years ago | (#23660353)

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:CVSup (1)

X0563511 (793323) | more than 5 years ago | (#23667145)

Does portsnap grab whole copies of the tree, or does it only update individual files like I think CVSup does?

Re:CVSup (2, Funny)

kv9 (697238) | more than 5 years ago | (#23660485)

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:CVSup (1)

X0563511 (793323) | more than 5 years ago | (#23667085)

Whoops... well, ports and portage arn't really that different in form or function. Plus, portage is a cooler name :P

Re:CVSup (1)

phsdeadc0.de (1166597) | more than 5 years ago | (#23656675)

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:CVSup (2, Informative)

cperciva (102828) | more than 5 years ago | (#23661345)

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

Re:CVSup (1)

gfim (452121) | more than 5 years ago | (#23662695)

You shouldn't be using CVSup these days. Try csup instead. It's more efficient, doesn't require Modula, and is part of the base system. It's backwards compatible with supfiles too.

FreeBSD is dying? (0, Redundant)

Chas (5144) | more than 5 years ago | (#23656157)

Oh wait...
Maybe not...

Here's hoping they have better luck than some of the switchovers I've had the "privilege.

Re:FreeBSD is dying? (0)

Anonymous Coward | more than 5 years ago | (#23662755)

The End of FreeBSD

[ed. note: in the following text, former FreeBSD developer Mike Smith gives his reasons for abandoning FreeBSD]

When I stood for election to the FreeBSD core team nearly two years ago, many of you will recall that it was after a long series of debates during which I maintained that too much organisation, too many rules and too much formality would be a bad thing for the project.

Today, as I read the latest discussions on the future of the FreeBSD project, I see the same problem; a few new faces and many of the old going over the same tired arguments and suggesting variations on the same worthless schemes. Frankly I'm sick of it.

FreeBSD used to be fun. It used to be about doing things the right way. It used to be something that you could sink your teeth into when the mundane chores of programming for a living got you down. It was something cool and exciting; a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile.

It's not anymore. It's about bylaws and committees and reports and milestones, telling others what to do and doing what you're told. It's about who can rant the longest or shout the loudest or mislead the most people into a bloc in order to legitimise doing what they think is best. Individuals notwithstanding, the project as a whole has lost track of where it's going, and has instead become obsessed with process and mechanics.

So I'm leaving core. I don't want to feel like I should be "doing something" about a project that has lost interest in having something done for it. I don't have the energy to fight what has clearly become a losing battle; I have a life to live and a job to keep, and I won't achieve any of the goals I personally consider worthwhile if I remain obligated to care for the project.

Discussion

I'm sure that I've offended some people already; I'm sure that by the time I'm done here, I'll have offended more. If you feel a need to play to the crowd in your replies rather than make a sincere effort to address the problems I'm discussing here, please do us the courtesy of playing your politics openly.

From a technical perspective, the project faces a set of challenges that significantly outstrips our ability to deliver. Some of the resources that we need to address these challenges are tied up in the fruitless metadiscussions that have raged since we made the mistake of electing officers. Others have left in disgust, or been driven out by the culture of abuse and distraction that has grown up since then. More may well remain available to recruitment, but while the project is busy infighting our chances for successful outreach are sorely diminished.

There's no simple solution to this. For the project to move forward, one or the other of the warring philosophies must win out; either the project returns to its laid-back roots and gets on with the work, or it transforms into a super-organised engineering project and executes a brilliant plan to deliver what, ultimately, we all know we want.

Whatever path is chosen, whatever balance is struck, the choosing and the striking are the important parts. The current indecision and endless conflict are incompatible with any sort of progress.

Trying to dissect the above is far beyond the scope of any parting shot, no matter how distended. All I can really ask of you all is to let go of the minutiae for a moment and take a look at the big picture. What is the ultimate goal here? How can we get there with as little overhead as possible? How would you like to be treated by your fellow travellers?

Shouts

To the Slashdot "BSD is dying" crowd - big deal. Death is part of the cycle; take a look at your soft, pallid bodies and consider that right this very moment, parts of you are dying. See? It's not so bad.

To the bulk of the FreeBSD committerbase and the developer community at large - keep your eyes on the real goals. It's when you get distracted by the politickers that they sideline you. The tireless work that you perform keeping the system clean and building is what provides the platform for the obsessives and the prima donnas to have their moments in the sun. In the end, we need you all; in order to go forwards we must first avoid going backwards.

To the paranoid conspiracy theorists - yes, I work for Apple too. No, my resignation wasn't on Steve's direct orders, or in any way related to work I'm doing, may do, may not do, or indeed what was in the tea I had at lunchtime today. It's about real problems that the project faces, real problems that the project has brought upon itself. You can't escape them by inventing excuses about outside influence, the problem stems from within.

To the politically obsessed - give it a break, if you can. No, the project isn't a lemonade stand anymore, but it's not a world-spanning corporate juggernaut either and some of the more grandiose visions going around are in need of a solid dose of reality. Keep it simple, stupid.

To the grandstanders, the prima donnas, and anyone that thinks that they can hold the project to ransom for their own agenda - give it a break, if you can. When the current core were elected, we took a conscious stand against vigorous sanctions, and some of you have exploited that. A new core is going to have to decide whether to repeat this mistake or get tough. I hope they learn from our errors.

Future

I started work on FreeBSD because it was fun. If I'm going to continue, it has to be fun again. There are things I still feel obligated to do, and with any luck I'll find the time to meet those obligations.

However I don't feel an obligation to get involved in the political mess the project is in right now. I tried, I burnt out. I don't feel that my efforts were worthwhile. So I won't be standing for election, I won't be shouting from the sidelines, and I probably won't vote in the next round of ballots.

You could say I'm packing up my toys. I'm not going home just yet, but I'm not going to play unless you can work out how to make the project somewhere fun to be again.

= Mike

--

To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt

GIT? (4, Interesting)

liquidpele (663430) | more than 5 years ago | (#23656199)

Wonder why they went with subversion over GIT?

Re:GIT? (5, Informative)

bark (582535) | more than 5 years ago | (#23656295)

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? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23656325)

GIT is GPL. They can't use it without relicensing all their code under the GPL license as well. SVN is truly FREE software.

Re:GIT? (2, Informative)

tuffy (10202) | more than 5 years ago | (#23656433)

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:GIT? (2, Informative)

Calinous (985536) | more than 5 years ago | (#23656573)

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)

Re:GIT? (-1, Troll)

Anonymous Coward | more than 5 years ago | (#23658353)

You seem to be confised. GIT is used to distribute the code, which means the GPL applies. Due to the viral license, any code distributed with GIT is therefore licensed as GPL.

Re:GIT? (1)

DuckDodgers (541817) | more than 5 years ago | (#23667801)

You are either misinformed or obnoxious.

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.

Re:GIT? (1)

Skrapion (955066) | more than 5 years ago | (#23664751)

I doubt this is one of the primary reasons they chose Subversion, but there is a very real possibility that they would eventually want to distribute SVN.

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 would want to keep using something like portsnap, though: Subversion adds unmodified copies of all of your files to the directory, effectively doubling your required disk space. Granted, if doubling 700M is that big of a deal for you, you probably don't have a copy of the ports tree to begin with.)

Re:GIT? (5, Informative)

LurkerXXX (667952) | more than 5 years ago | (#23656337)

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

Re:GIT? (2, Informative)

compass46 (259596) | more than 5 years ago | (#23662239)

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:GIT? (4, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#23656435)

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? (5, Funny)

krog (25663) | more than 5 years ago | (#23656477)

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? (5, Funny)

0xABADC0DA (867955) | more than 5 years ago | (#23657203)

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:Oh really? (1)

bsDaemon (87307) | more than 5 years ago | (#23657459)

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

Re:Oh really? (1)

krog (25663) | more than 5 years ago | (#23657585)

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:Oh really? (2, Funny)

hawk (1151) | more than 5 years ago | (#23658411)

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:Oh really? (1)

ari_j (90255) | more than 5 years ago | (#23660129)

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? (1)

Brandybuck (704397) | more than 5 years ago | (#23664427)

Linux is nothing more than a bootloader for Emacs...

Oh wait, did I just say that on a FreeBSD thread?

Re:Oh really? (1)

bsDaemon (87307) | more than 5 years ago | (#23667641)

Well, pretty much... GNU is UNIX done the MIT way. MIT are LISP-addicts, which is why GNU stuff uses Scheme (via GUILE) for scripting and extensions, and EMACS is pretty much just a LISP machine in and of itself.

I don't much care for LISP, honestly.

Re:GIT? (2, Interesting)

mTor (18585) | more than 5 years ago | (#23657155)

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 Cygwin. As for Mac support... it got it very quickly. In fact, I'm willing to claim that not having very early Win support didn't do anything to adoption rate. Target audience were Linux hackers so having support for various other systems wouldn't have done much at all.

As for "changed (somewhat)", what do you mean somewhat? I use Git daily on my Mac laptop and have even used it under Vista without any issues.

Git is HUGE these days. Rails project, for example, has completely switched to Git. Same is happening to Pythin community as more and more things are moving to places like GitHub (which is amazing btw). Also, Google Code now provides Git repos for almost ALL of the projects.

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. Searches with " tutorial" appeneded are great because they indicate adoption rate and indicate that there are people out there who are trying to get started.

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

Re:GIT? (2, Interesting)

Anonymous Coward | more than 5 years ago | (#23657863)

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 of people due to its earlier better windows support. However, in projects run by a single benevolent dictator (like Wine, linux kernel and X.org) git tends to win due to its better technology and the lesser importance of political issues. (The fact that Linus originally wrote git will definitely hold back its usage in non-linux OS's due to politics. I can't see Microsoft using it, for example.)

Re:GIT? (3, Informative)

AKAImBatman (238306) | more than 5 years ago | (#23657903)

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? (1, Informative)

Anonymous Coward | more than 5 years ago | (#23658119)

Not quite...

git tutorial: 589,000 Results

mercurial tutorial: 680,000 Results

"git tutorial": 5,890 Results

"mercurial tutorial": 647 Results

Re:GIT? (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23658419)

Using quotes is asking for trouble. You are effectively assuming the rules of grammar in a complex language. Never use that for statistics. For that matter, never use Google Fights as evidence. As the fight above exemplifies, different Google users will get different results depending on their region and Google's last spider. The only consistent piece of information was that Mercurial had more search results.

Re:GIT? (3, Informative)

mTor (18585) | more than 5 years ago | (#23658485)

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:GIT? (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23658865)

Use quotes for statistics purposes? FAIL!

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" ...but won't be found with "mercurial tutorial".

Statistics != SEO != Adwords

Re:GIT? (1, Informative)

Anonymous Coward | more than 5 years ago | (#23658967)

"tutorial on Mercurial":
'No results found for "tutorial on mercurial".'

"tutorial on git": 323 Results.

Re:GIT? (1)

fafne (840092) | more than 5 years ago | (#23658421)

git tutorial: 592 000 hits mercurial tutorial: 1 080 000 hits Am I missing something?

Re:GIT? (2, Informative)

derago (582951) | more than 5 years ago | (#23661391)

Yes, try the same search with quotes. Not that it would matter anyways, as it's not a viable method for comparing the usage of both. Let me reinterpret these results:

"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? (1)

macshit (157376) | more than 5 years ago | (#23661733)

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 inclucde hg, bzr, darcs, etc. This data obviously isn't perfect, but it seems pretty much reflect the trends that I've observed.

Re:GIT? (1)

Skrapion (955066) | more than 5 years ago | (#23664899)

Huh? Git didn't have windows support very early on but very soon you could compile it with Cygwin.
So, your advice to Windows users is "use Linux"? I don't think that's going to fly, and I suspect your view might be a little myopic.

But it's okay, implying that Mercurial had early Windows support is almost as laughable. When did TortoiseHg begin development, December?

Re:GIT? (0)

Anonymous Coward | more than 5 years ago | (#23668201)

The command line tools were available for Windows long before TortoiseHg. Being based on Python, there was practically no porting required.

TortoiseHg merely offered an excellent UI under Windows.

Re:GIT? (1)

oojah (113006) | more than 5 years ago | (#23664987)

I'm sure that one could also argue that a difference in the number of hits for tutorial is indicative of the relative difficulty of the vcs :)

Cheers,

Roger

Re:GIT? (0)

Anonymous Coward | more than 5 years ago | (#23659951)

Is this supposed to be sarcasm?

I honestly can't tell, and I'm curious now, since your assertions do not seem to match my experience. Granted, my own anecdotal evidence is not more than that, but I not only occasionally come across (large/important) projects that use git (projects not related to Linux), I also have never seen anyone actually use mercurial.

I'm sure there's projects that do indeed use mercurial, of course, but the assertion that git "lost" (what war, anyway?) and that mercurial "won" is so completely at odds with reality as I perceive it that I can't help but wonder whether you're actually being serious.

Re:GIT? (0)

Anonymous Coward | more than 5 years ago | (#23665905)

Very untrue about mac.. I use it almost daily

Re:GIT? (4, Informative)

Fweeky (41046) | more than 5 years ago | (#23656475)

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? (0)

Anonymous Coward | more than 5 years ago | (#23658149)

Because they cannot upgrade from 1980 to 2008 all at once.

Why GIT? (1)

argent (18001) | more than 5 years ago | (#23659389)

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:GIT? (0)

Anonymous Coward | more than 5 years ago | (#23660265)

git is GPL'd and was written by Linux developers. FreeBSD using git would be like Microsoft switching to OS X for its web servers.

Re:GIT? (0)

Anonymous Coward | more than 5 years ago | (#23663409)

Good analogy, in both cases there is a clearly superior alternative ;).

Re:GIT? (1)

arensic (1302199) | more than 5 years ago | (#23662399)

Honestly, I'd be more interested in knowing why they chose SVN over the many options out there, and furthermore which options they considered in the first place. I hear about CVS, perforce, subversion, GIT, and mercurial all the time, but there are yet more options out there. For example, I recently discovered darcs, which I like as it happens to think about revisions the way I do (patches.) They all have their own qualities, and the more familiar the differences are, the easier it is to decide which tool matches the project best.

Perforce (1)

sqrammi (535861) | more than 5 years ago | (#23657509)

I thought core FreeBSD developers used Perforce: http://perforce.freebsd.org./ [perforce.freebsd.org] Is that not the case?

Re:Perforce (0)

Anonymous Coward | more than 5 years ago | (#23659243)

The CVS is there to get vetted changes to the users. Perforce is where all the development goes on.

Re:Perforce (2, Informative)

MavEtJu (241979) | more than 5 years ago | (#23660619)

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 capabilities of CVS and it can be integrated in the current distribution framework.

Oh, and it understood most of the FreeBSD CVS Repository :-)

Re:Perforce (0)

Anonymous Coward | more than 5 years ago | (#23660983)

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 ALL capabilities of CVS and it can be integrated in the current distribution framework.
There fixed.

*BSD is Dying (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#23662603)

It is now official. Netcraft confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin [amazingkreskin.com] to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...