Four level of indirection to call a method with 9 parameters... really? Come on. This is what object-oriented programming looks like in C, when there's no C++ to make it pretty. You have function pointers and their associated "closure' context objects being passed around everywhere as pairs. And lots of tables of function pointers (vtables). So in this example, we have a local closure object (dir_baton) referencing a vtable within a parent closure object, and calling a function from that vtable.
Go look at GTK/GNOME: they have the same sorts of problems, though they tend to do things with a huge series of object-type macros to simulate inheritance.
The 9 parameters are there because it's a complicated routine used in different contexts. There are no 'optional' parameters like in python.
I'm shocked you say this -- for years I've heard nothing but compliments about how readable, well organized, well documented, and stylistically consistent Subversion's codebase is. There's a whole HACKING guide that explains the styles -- both semantic and syntactic. It's something we're quite proud of.
As a matter of fact, a guy doing a demo at an Apple Developer conference once used the svn codebase as 'something big to compile' when demonstrating the XCode IDE. When we asked why he used svn, he said that it was "the only open source codebase he'd ever seen which compiles with no warnings."
If you have specific criticisms about the codebase, we'd like to hear. Instead, your post just seems to be about how your personal wish-list of features has never been added, and therefore "the codebase must be really bad." I'm not sensing any logic to this conclusion.
svn 1.6 is going to likely have.svn/ metadata centralized in one place, the way DVCS systems do. It will also likely make the "extra copy" of files be an optional thing, as many have asked. And svn 1.5 fixes the 'svn mv * foo/' wildcard expansion behavior.
The fact is: we haven't added your pet features yet because we've been too busy working on other big fish, like FSFS, svnserve, locking, svnsync, SASL support, changelists, interactive conflict resolution, and oh yeah... automatic tracking of merges.:-)
The working copy code was designed in a specific way -- the scattered.svn/ areas and extra cached copies of files was deliberate, and considered a feature. Just because we can't write 100 lines of code and "magically" make it behave in opposite ways doesn't mean it's a bad codebase. Even the *best* codebases are based on certain foundational assumptions -- some things are abstracted, some aren't. The things you complain about weren't switches we thought we'd ever need to flip, so we put the abstractions in other places.
Re:How about a more rational debate, Linus?
on
Linus on GIT and SCM
·
· Score: 1
I agree with you. This is why I'm so interested in seeing svn 2.0 as a decentralized system.
The really hard question is: can we make it useable? Subversion prides itself on its very simple UI. So many decentralized systems have literally dozens and dozens of subcommands and even more switches, and they're daunting to even hard core technogeeks. Can Subversion 2.0 be decentralized at heart, but initially present itself as centralized? Can it keep the complexities of decentralization "hidden" for novice users, starting life centralized, and then allowing users to decentralize as they get more comfortable?
I have a lot of respect for Mercurial. It seems to be the most usable DVCS system out there, and we have a lot to learn from it. (I already know that Subversion is planning to use its 'revlog' repository format as a successor to FSFS.)
How about a more rational debate, Linus?
on
Linus on GIT and SCM
·
· Score: 2, Interesting
Ignoring Linus' heinous unprofessional attitude, massive ego, and completely insulting comments, there's a lesson to be learned here: you and your team need to decide whether you want centralized or decentralized version control. There are advantages and disadvantages to both methodologies. Anybody who gets up on a stage and tells you that "all centralized systems are garbage, decentralized is the one true way" isn't giving you the full picture. (And likewise, anyone who says the opposite is equally off their rocker!) 80% of software development takes place within corporations, and there's a reason centralized SCM has worked so well in that environment. Decentralized systems might be great for certain open source communities, but it's not what most organizations want or need. If you'd like another viewpoint on why centralized might sometimes be better than decentralized (even in open source projects), take a look at this essay I wrote a while back.
I'm one of the original designers/developers of Subversion, and even we (in the svn developer community) are well aware of both sides of the coin. We're seriously considering adding decentralized features to svn 2.0. We've also added true merge-tracking magic to the imminent svn 1.5 release (so svn is no longer "hand waving" merges, they'll be just as simple as in decentralized systems.)
If you truly believe that distributed SCM is the the Only Way of working in all situations, then I suggest you try to push these systems on corporate teams, and see how they fare. Distributed systems have a model that's much more complex for the average joe-user to understand, and as a result most existing distributed systems have extremely complicated UI's. If they're complex enough to confuse open source nerds, think about the rest of the world's programmers...
Keep an open mind about this stuff. No matter what Linus says, there's no magic SCM bullet.
We imitated this CVS behavior because it achieves two feature goals:
1) severability: you can 'break off' any part of a working copy, and it still functions as a standalone working copy.
2) portability: you can transport a working copy to different disks or machines, and it still functions.
That said, we're now re-evaluating the utility of these features... it seems that few people actually use them or care. In svn 2.0, we might just go for the 'all metadata in one place' design, much like svk and other systems do.:-)
By the way, you don't need to use slashdot to "get our ear", come post questions on the dev@subversion.tigris.org lists.
You're describing a pathological community, not a normal community.
Like most successful open source projects, the initial coders decide on standards: code must be formatted a certain way, algorithmic conventions followed, design principles and goals agreed to, and so on. This is not 'elitism', it's a charter for the project itself, and successful projects document it for all to see. Without these standards, you end up with a big ball of mud rather than a coherent piece of software.
If someone submits a patch, we welcome the participation with open arms, and do everything we can to get the person to join the community (by which we mean, "become a regular contributer of code and discussion"). However, if the person refuses to play by the same charter and rules as everyone else, that person's contributions aren't going to be accepted, it's that simple. We don't turn the person away in disdain, we actively give feedback and nicely try to coax the person to comply as best we can.
Please don't mistaken "healthy community with its own culture and practices" for "elite social group forcing people to prove themselves". Yes, it's *possible* that communities can devolve into that sort of ugliness, but unless you've participated in Subversion development, I find it insulting that you assume the worst. Our project continously welcomes new people, and has been continuously adding 'new blood' (as you say) since we started... so sign of stagnation in sight.
We didn't boot any person at all, we simply rejected the offered patch. The person wasn't a member of the community, just a drive-by patch contributor.... we didn't "throw him out", because he wasn't "in" to begin with! Patch contributions are great things, but if we can't come to an agreement, then that's the end of things. The person wasn't interested in resubmitting without his name attached to the patch, so we had to reject the patch. Our honest hope was that not only would he contribute his patch properly, but that he'd become a regular committer too. Instead, he was annoyed at us and walked away. C'est la vie, we're not going to change our code submission rules for a single visitor. Twas a shame.
Your xbox blog is legendary (http://xboxgamer.blogspot.com/). I know you still have a gaming PC for MMORPGs; why aren't they all running on the xbox Live network? What's it going to take before we give up gaming PCs for consoles? It seems like MMORPGs are the last holdout, but I can't figure out why they're holding out.
I actually know the actor with the glasses. He's not just a professional actor, but has been a D&D judge (GM) at Gencon for many, many years. Heck, he's even judged me.
In real life, he's quite a normal guy-off-the-treet, very quick witted and funny. Maybe this will be his big breakout film!:-)
(Btw, the organization that he and I both belong to is called NASCRAG, and we run a great goofy tournament every year at Gencon. No experience required, other than a good sense of humor.)
* Subversion deliberately uses a lot of working-copy disk space, because it's optimized for network use. (that is, it assumes that network is scarce, and disk is cheap.) It caches pristine copies of files so that lots of commands ("diff", "revert", "status") all work offline. It's a deliberate choice. Someday the developers hope to make this tradeoff configurable.
* Subversion is slower than CVS, yes, but not unusably slow. And it's faster than CVS at some things, like branching and tagging. The speed tradeoffs are amortized over the overall lifecycle of using the software. For example: it takes longer to checkout a working copy (because more data is being created on disk), but then after that, some common commands are faster than CVS as a result.
* Subversion has exposed BerkeleyDB's brittleness to end users, which is admittedly a mistake. But the Subversion team is now working closely with Sleepycat to fix these problems. And besides, there's now a whole non-database repository alternative that you can use. You can choose to avoid BDB altogether.
* You seem to be unaware that Subversion is not only able to use http://, but https:// as well, complete with server and client certificate negotiation. You can also tunnel the custom server protocol over ssh, using svn+ssh:// urls; no apache required at all, if you'd just prefer to use existing ssh accounts.
We haven't announced 1.0 just yet; we're going to do it sometime on Monday the 23rd. The Subversion team prepped the website and rolled a 'beta' 1.0 tarball over the weekend in preparation for Monday. We wanted to make sure there were no embarrassing bugs in the tarball itself (i.e. no "brown bag" releases due to a bad libtool or something!)
Thanks for all the nice comments. Stay tuned for the official announcement.
I hope you don't mind, I've saved your quote about trees. It cracks me up, along with other Subversion developers.
If you want a serious answer: we have several db tables. The values in the tables are lisp-like "s-expressions" that hold real data and keys to other tables. It's a way of getting "columns" when you don't have a real SQL backend. And by the way, it works extremely well.
(We do have future plans, however, to give the repository a real SQL backend someday.)
Keep in mind: you only need to build Apache 2.0 if you want to create a Subversion *server*, i.e. network your repository.
But you can just as easily build a Subversion client that has BerkeleyDB linked into it; you'd still be able to create and access a repository on local disk.
In other words, it's relatively simple to build and use Subversion for "personal" use -- say, on a box where you don't have installation privs. Just use it in your home directory.
Re:How about migration tools from CVS?
on
Subversion Hits Alpha
·
· Score: 5, Informative
We've got python bindings for parsing RCS files, and bindings to subversion libraries (via SWIG). As a result, we now have a good start on a 'cvs2svn.py' repository-converter script.
The script examines the cvs repository, deduces changesets, and commits them to an svn repository. It works right now.
However, it doesn't yet convert cvs branches and tags. We're working on it.
We've already got the beginnings of VC-mode support. The.el file is in the subversion source tree.
Unfortunately, the VC API doesn't exactly match up with subversion concepts. So people have been batting around ideas to revamp the API for pcl-cvs, or maybe inventing a new API.
Sorry, you caught us with our pants down. Apparently the scripts we use for keeping the book on-line failed recently, and of course we didn't notice till today.:) The HTML is back on-line, and the rest of the links should be working shortly.
Slashdot Mirror
(NULL, NULL, path,
textbase,
empty_file,
base_mimetype,
NULL,
baseprops,
dir_baton->edit_baton->callback_baton));
Four level of indirection to call a method with 9 parameters... really? Come on. This is what object-oriented programming looks like in C, when there's no C++ to make it pretty. You have function pointers and their associated "closure' context objects being passed around everywhere as pairs. And lots of tables of function pointers (vtables). So in this example, we have a local closure object (dir_baton) referencing a vtable within a parent closure object, and calling a function from that vtable.
Go look at GTK/GNOME: they have the same sorts of problems, though they tend to do things with a huge series of object-type macros to simulate inheritance.
The 9 parameters are there because it's a complicated routine used in different contexts. There are no 'optional' parameters like in python.
I'm shocked you say this -- for years I've heard nothing but compliments about how readable, well organized, well documented, and stylistically consistent Subversion's codebase is. There's a whole HACKING guide that explains the styles -- both semantic and syntactic. It's something we're quite proud of.
.svn/ metadata centralized in one place, the way DVCS systems do. It will also likely make the "extra copy" of files be an optional thing, as many have asked. And svn 1.5 fixes the 'svn mv * foo/' wildcard expansion behavior.
:-)
.svn/ areas and extra cached copies of files was deliberate, and considered a feature. Just because we can't write 100 lines of code and "magically" make it behave in opposite ways doesn't mean it's a bad codebase. Even the *best* codebases are based on certain foundational assumptions -- some things are abstracted, some aren't. The things you complain about weren't switches we thought we'd ever need to flip, so we put the abstractions in other places.
As a matter of fact, a guy doing a demo at an Apple Developer conference once used the svn codebase as 'something big to compile' when demonstrating the XCode IDE. When we asked why he used svn, he said that it was "the only open source codebase he'd ever seen which compiles with no warnings."
If you have specific criticisms about the codebase, we'd like to hear. Instead, your post just seems to be about how your personal wish-list of features has never been added, and therefore "the codebase must be really bad." I'm not sensing any logic to this conclusion.
svn 1.6 is going to likely have
The fact is: we haven't added your pet features yet because we've been too busy working on other big fish, like FSFS, svnserve, locking, svnsync, SASL support, changelists, interactive conflict resolution, and oh yeah... automatic tracking of merges.
The working copy code was designed in a specific way -- the scattered
I agree with you. This is why I'm so interested in seeing svn 2.0 as a decentralized system.
The really hard question is: can we make it useable? Subversion prides itself on its very simple UI. So many decentralized systems have literally dozens and dozens of subcommands and even more switches, and they're daunting to even hard core technogeeks. Can Subversion 2.0 be decentralized at heart, but initially present itself as centralized? Can it keep the complexities of decentralization "hidden" for novice users, starting life centralized, and then allowing users to decentralize as they get more comfortable?
I have a lot of respect for Mercurial. It seems to be the most usable DVCS system out there, and we have a lot to learn from it. (I already know that Subversion is planning to use its 'revlog' repository format as a successor to FSFS.)
Ignoring Linus' heinous unprofessional attitude, massive ego, and completely insulting comments, there's a lesson to be learned here: you and your team need to decide whether you want centralized or decentralized version control. There are advantages and disadvantages to both methodologies. Anybody who gets up on a stage and tells you that "all centralized systems are garbage, decentralized is the one true way" isn't giving you the full picture. (And likewise, anyone who says the opposite is equally off their rocker!) 80% of software development takes place within corporations, and there's a reason centralized SCM has worked so well in that environment. Decentralized systems might be great for certain open source communities, but it's not what most organizations want or need. If you'd like another viewpoint on why centralized might sometimes be better than decentralized (even in open source projects), take a look at this essay I wrote a while back.
I'm one of the original designers/developers of Subversion, and even we (in the svn developer community) are well aware of both sides of the coin. We're seriously considering adding decentralized features to svn 2.0. We've also added true merge-tracking magic to the imminent svn 1.5 release (so svn is no longer "hand waving" merges, they'll be just as simple as in decentralized systems.)
If you truly believe that distributed SCM is the the Only Way of working in all situations, then I suggest you try to push these systems on corporate teams, and see how they fare. Distributed systems have a model that's much more complex for the average joe-user to understand, and as a result most existing distributed systems have extremely complicated UI's. If they're complex enough to confuse open source nerds, think about the rest of the world's programmers...
Keep an open mind about this stuff. No matter what Linus says, there's no magic SCM bullet.
We imitated this CVS behavior because it achieves two feature goals:
:-)
1) severability: you can 'break off' any part of a working copy, and it still functions as a standalone working copy.
2) portability: you can transport a working copy to different disks or machines, and it still functions.
That said, we're now re-evaluating the utility of these features... it seems that few people actually use them or care. In svn 2.0, we might just go for the 'all metadata in one place' design, much like svk and other systems do.
By the way, you don't need to use slashdot to "get our ear", come post questions on the dev@subversion.tigris.org lists.
You're describing a pathological community, not a normal community.
Like most successful open source projects, the initial coders decide on standards: code must be formatted a certain way, algorithmic conventions followed, design principles and goals agreed to, and so on. This is not 'elitism', it's a charter for the project itself, and successful projects document it for all to see. Without these standards, you end up with a big ball of mud rather than a coherent piece of software.
If someone submits a patch, we welcome the participation with open arms, and do everything we can to get the person to join the community (by which we mean, "become a regular contributer of code and discussion"). However, if the person refuses to play by the same charter and rules as everyone else, that person's contributions aren't going to be accepted, it's that simple. We don't turn the person away in disdain, we actively give feedback and nicely try to coax the person to comply as best we can.
Please don't mistaken "healthy community with its own culture and practices" for "elite social group forcing people to prove themselves". Yes, it's *possible* that communities can devolve into that sort of ugliness, but unless you've participated in Subversion development, I find it insulting that you assume the worst. Our project continously welcomes new people, and has been continuously adding 'new blood' (as you say) since we started... so sign of stagnation in sight.
I think you misunderstood that part of our talk.
We didn't boot any person at all, we simply rejected the offered patch. The person wasn't a member of the community, just a drive-by patch contributor.... we didn't "throw him out", because he wasn't "in" to begin with! Patch contributions are great things, but if we can't come to an agreement, then that's the end of things. The person wasn't interested in resubmitting without his name attached to the patch, so we had to reject the patch. Our honest hope was that not only would he contribute his patch properly, but that he'd become a regular committer too. Instead, he was annoyed at us and walked away. C'est la vie, we're not going to change our code submission rules for a single visitor. Twas a shame.
Greg,
Your xbox blog is legendary (http://xboxgamer.blogspot.com/). I know you still have a gaming PC for MMORPGs; why aren't they all running on the xbox Live network? What's it going to take before we give up gaming PCs for consoles? It seems like MMORPGs are the last holdout, but I can't figure out why they're holding out.
I actually know the actor with the glasses. He's not just a professional actor, but has been a D&D judge (GM) at Gencon for many, many years. Heck, he's even judged me.
In real life, he's quite a normal guy-off-the-treet, very quick witted and funny. Maybe this will be his big breakout film! :-)
(Btw, the organization that he and I both belong to is called NASCRAG, and we run a great goofy tournament every year at Gencon. No experience required, other than a good sense of humor.)
I think your information is a bit old.
Point for point:
* Subversion deliberately uses a lot of working-copy disk space, because it's optimized for network use. (that is, it assumes that network is scarce, and disk is cheap.) It caches pristine copies of files so that lots of commands ("diff", "revert", "status") all work offline. It's a deliberate choice. Someday the developers hope to make this tradeoff configurable.
* Subversion is slower than CVS, yes, but not unusably slow. And it's faster than CVS at some things, like branching and tagging. The speed tradeoffs are amortized over the overall lifecycle of using the software. For example: it takes longer to checkout a working copy (because more data is being created on disk), but then after that, some common commands are faster than CVS as a result.
* Subversion has exposed BerkeleyDB's brittleness to end users, which is admittedly a mistake. But the Subversion team is now working closely with Sleepycat to fix these problems. And besides, there's now a whole non-database repository alternative that you can use. You can choose to avoid BDB altogether.
* You seem to be unaware that Subversion is not only able to use http://, but https:// as well, complete with server and client certificate negotiation. You can also tunnel the custom server protocol over ssh, using svn+ssh:// urls; no apache required at all, if you'd just prefer to use existing ssh accounts.
Hope this clarifies things.
I installed FC2-test2 in March, and it turned my MBR into oatmeal. I had no choice but to reinstall Windows from scratch, and I was *royally* annoyed.
Sure, it may be a 2.6 kernel bug, but still, how is it that this stuff isn't noticed earlier?
I'm gonna stay away from grub completely for the time being, and use XP's bootloader to boot Fedora.
We haven't announced 1.0 just yet; we're going to do it sometime on Monday the 23rd. The Subversion team prepped the website and rolled a 'beta' 1.0 tarball over the weekend in preparation for Monday. We wanted to make sure there were no embarrassing bugs in the tarball itself (i.e. no "brown bag" releases due to a bad libtool or something!)
Thanks for all the nice comments. Stay tuned for the official announcement.
I hope you don't mind, I've saved your quote about trees. It cracks me up, along with other Subversion developers.
If you want a serious answer: we have several db tables. The values in the tables are lisp-like "s-expressions" that hold real data and keys to other tables. It's a way of getting "columns" when you don't have a real SQL backend. And by the way, it works extremely well.
(We do have future plans, however, to give the repository a real SQL backend someday.)
Berkeley DB doesn't work over NFS. NFS can't supply the locking it needs. :-(
Keep in mind: you only need to build Apache 2.0 if you want to create a Subversion *server*, i.e. network your repository.
But you can just as easily build a Subversion client that has BerkeleyDB linked into it; you'd still be able to create and access a repository on local disk.
In other words, it's relatively simple to build and use Subversion for "personal" use -- say, on a box where you don't have installation privs. Just use it in your home directory.
We've got python bindings for parsing RCS files, and bindings to subversion libraries (via SWIG). As a result, we now have a good start on a 'cvs2svn.py' repository-converter script.
The script examines the cvs repository, deduces changesets, and commits them to an svn repository. It works right now.
However, it doesn't yet convert cvs branches and tags. We're working on it.
We've already got the beginnings of VC-mode support. The .el file is in the subversion source tree.
Unfortunately, the VC API doesn't exactly match up with subversion concepts. So people have been batting around ideas to revamp the API for pcl-cvs, or maybe inventing a new API.
Sorry, you caught us with our pants down. Apparently the scripts we use for keeping the book on-line failed recently, and of course we didn't notice till today. :) The HTML is back on-line, and the rest of the links should be working shortly.
As the review says, half of the book (the technical chapters) are GPLed and downloadable from http://cvsbook.red-bean.com
Especially all the subtle jokes/digs he made about Microsoft. Overall, though, he was quite gracious and fun to listen to.