Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
subversion 1.0 is releasedsubversion 1.0 is releasedPosted Feb 23, 2004 21:17 UTC (Mon) by dh (subscriber, #153)Parent article: subversion 1.0 is released
Hi,
(Log in to post comments)
improvements over CVS Posted Feb 23, 2004 22:17 UTC (Mon) by ncm (subscriber, #165) [Link] Two key features are missing from CVS, and fixed in svn and arch: atomic updates, and renaming. Both are quite severe problems, and have justified a lot of work. Having done the work, they find various other things much easier to fix than they would have been in the CVS codebase.Not to be neglected, though, is that the CVS code is terminally insecure. It's amazing a lot more breakins don't happen through CVS, although maybe they do and we just don't notice.
subversion 1.0 is released Posted Feb 23, 2004 23:06 UTC (Mon) by mag (subscriber, #12697) [Link] I don't understand how you can base your judgement on comments from Linus, I'm pretty sure not many projects are of that magnitude and pace. As for Eclipse plugin, subclipse integrates svn into Ecplipse. I've used it and it worked pretty good.Most people are moving from CVS, and the CVS lookalike command interface is a great win here. Subversion works in a completly different way under the hood, and that makes it many times better than CVS. Mag
subversion 1.0 is released Posted Feb 24, 2004 1:06 UTC (Tue) by piman (subscriber, #8957) [Link] In addition to what ncm mentioned, svn supports versioned directories, versioned metadata, and binary diffs (particularly important for one of my projects that has a lot of images and music). In addition, SVN's output is generally much nicer than CVS (more readable svn status output, diff -u by default, and so on).As for setting up a server -- what server? I use Subversion over SSH and didn't have to set up a single new daemon or background process (I use suEXEC + ViewCVS, which supports SVN, to allow anonymous downloads). If you don't want to bother with Apache 2 and DAV, you can use svnserve which is roughly equivalent to CVS's pserver functionality. Or, you could just use DAV, which is probably the most secure option. This isn't to trash Arch - I have a friend that swears by it, and a lot of free software projects like Rhythmbox seem to be doing great with it - but Subversion has many advantages over CVS, and doesn't have nearly the documentation and usability problems Arch has.
subversion 1.0 is released Posted Feb 24, 2004 9:52 UTC (Tue) by veelo (guest, #4694) [Link]
And what does the subversion homepage say (just checked again): "Currently, Subversion's merge support is essentially the same as CVS's." Mind currently. To be fair, one should mention that this quote is taken from the feature list that is planned for after 1.0. The full quote reads: In other words, this is one of the things the subversion team will be working on from now on. To focus on implementing most CVS features (besides stability, documentation and all the improvements on CVS) for 1.0, and leaving others for later was a good decision I think. Having come this far, I have no doubt that the project will go on and implement these other nice features too. The most important thing to be aware of though is that Arch and Subversion differ in fundamental ways. Arch works in a decentralised way, while Subversion is designed on a client/server model. Indeed with Arch you can start coding and using version control without first applying for access to the server. However, the mergence of your code with the main branch has to be done by the one project maintainer. It is the Linus way of doing c/q leading development. To throw in an other quote [Hudson]:
Development with Subversion (and CVS for that matter) is centralised in the sence that there is just one repository, but it is actually more decentralised in a social sence since there are as many code integrators as there are developers with write access to the repository. In short, one could say that Arch is centralised around a code integrator, and that Subversion (like CVS) is centralised around a repository. You decide what fits best. If you are a heavy user of CVS, like Dirk is, chances are that Subversion actually fits your needs best.
Bastiaan.
subversion 1.0 is released Posted Feb 24, 2004 11:21 UTC (Tue) by anselm (subscriber, #2796) [Link] In short, one could say that Arch is centralised around a code integrator, and that Subversion (like CVS) is centralised around a repository. This is an oversimplification. With Arch, you can use a tool such as arch-pqm to let several people merge changes into an archive. In fact, merge requests can even be submitted using GPG-signed e-mail.
subversion 1.0 is released Posted Feb 25, 2004 16:17 UTC (Wed) by walters (subscriber, #7396) [Link] You don't even need that. You can share a single archive with arch in exactly the same way that CVS and Subversion do. (speaking as the author of arch-pqm)
Centralized vs decentralized Posted Feb 24, 2004 15:26 UTC (Tue) by lm (guest, #6402) [Link] With respect to Mr Hudson's comments about the decentralized model versus a centralized model, I have a few comments.1) As Mr Hudson pointed out, the BitKeeper model is a superset of the Subversion model. In other words, you can use BitKeeper the same way you might use Subversion, it has that capability, but you can't use Subversion the way you might use Bitkeeper, Subversion doesn't have that power. I'm not making this up, read the Subversion mailing lists, they have freely admitted that SVN will never do what BK can do. 2) Given that Mr Hudson works on Subversion, his statements are far from unbiased. In fact, they could be compared to a buggy manufacturer touting the advantages of the horse and buggy when presented with the automobile. Of course he thinks his product is better but that doesn't mean it is. The same can be said of my comments, so salt heavily. The difference is he's working on the buggy, we're working on the car. Take your pick. 3) His claims that the BitKeeper model as used by the Linux kernel team is inferior are simply not substantiated. Since switching to BitKeeper, the Linux development pace has gone up by more than 2x, no matter how you measure it. Mr Hudson claims that the model used by Apache, for example, is better than the Linux model. Hmm. When the Apache team can review and integrate changes at the rate of 18,500 patches a year (more than 50 a day) then perhaps he might have a point. Until then we are left to wonder if maybe the Apache team is working on a far easier problem. 4) Mr Hudson might want to stop to consider that every time there is parallel development with a tool like SVN information is lost. If you have N way parallel development you lose N-1 events in SVN. You lose none in BitKeeper. Anyone who has had to "unmerge" their work from some previously integrated bad code knows what I mean. Let's review. The Subversion team admits that BitKeeper can do what Subversion can but Subversion can't do what BitKeeper can do. The kernel uses BitKeeper and the development pace doubles. This leads us to the obvious conclusion that the BitKeeper model is somehow inferior for open source work. Maybe it's just me, but I'm not following the logic.
Bitkeeper, the universe, and everything Posted Feb 24, 2004 17:19 UTC (Tue) by dh (subscriber, #153) [Link] Larry??? Is it you???:-) Well, no-one here actually talked about Bitkeeper so far. Knowing CVS and having read about Bitkeeper, it's clear to me (and should be clear to anyone else having similar experiences) that there are lightyears of difference between those two regarding capabilities - and possible working sets. We just learned that Subversion is "CVS done correctly", so this comparison stands for Subversion the same. Everyone digging a little bit into capabilities of revision control should see that (a) the huge difference is "one repository - many repositories" and (b) a system granting "many repositories" can always emulate a system managing only one repository. Because of (b), I cannot follow those who claim arch being inferior to subversion due to not having a centralized repository. For me, it seems as if those people haven't fully understood the concepts. Anyway, comparing Bitmover to CVS or Subversion or any other single-repository-system is like comparing steam engines to moon rockets. It's boring, because you know the results... For me, a comparison between Bitkeeper and, say, arch would be much more interesting. Most interesting, of course, if it comes from a person neither involved with Bitmover nor with arch... Best regards, Dirk
Bitkeeper, the universe, and everything Posted Feb 24, 2004 19:20 UTC (Tue) by lm (guest, #6402) [Link] Hi Dirk,I can't do the comparison to Arch objectively because we produce a product with a similar model. I suspect, however, that an objective comparison would come up with things like:
Personally, I am starting to think it is great that Arch et al exist. They get people away from the licensing discussions and get them focussed on the model. We like the distributed model, it clearly works better, and if you have to use open source tools we'd rather have you learning about the model we think is better. The difference between Arch and BK is going to be a lot like the difference between GCC and Microsoft's compiler. I just timed compiling BK on windows with gcc vs Microsoft's compiler: 10m41s vs 4m40s. They both do the same thing at some level, one just works better. You pays your money and takes your choice and the old adage you get what you pay for still applies.
Bitkeeper, the universe, and everything Posted Feb 24, 2004 21:06 UTC (Tue) by ballombe (subscriber, #9523) [Link] You know better than comparing compilation time of compilers.
Bitkeeper, the universe, and everything Posted Feb 24, 2004 21:26 UTC (Tue) by khim (subscriber, #9252) [Link] I just timed compiling BK on windows with gcc vs Microsoft's compiler: 10m41s vs 4m40s. They both do the same thing at some level, one just works better. Have you tested it with Intel Compiler ? Last time I checked Intel compiled required few times more then even gcc. And it's still cost extras and it is better. It's stupid to compare compiler on speed.
Bitkeeper, the universe, and everything Posted Feb 24, 2004 23:10 UTC (Tue) by piman (subscriber, #8957) [Link] Hi Larry,You put the rest of us in something of an unfair position. The BitKeeper License (as I find it at http://www.bitkeeper.com/bkl.txt) clause 3c prevents those developing products similar to BK (i.e. other SCMs or SCM-related software) from using BitKeeper under its free license. Thus, the Subversion, Arch, or Monotone developers can't try out BitKeeper to compare features, speed, and so on. Whereas since those are all released under a free software license, you are free to try them out and evaluate them even though you are competing with them. Thus, no free SCM developers can provide a fully informed (if biased) critique of BitKeeper in the same way you can provide a fully informed (if biased) critique of Arch or Subversion. If you are so sure about BitKeeper's capabilities compared to the competition, perhaps you should remove clause 3c. Your baiting comment about compilers is disappointing; given the amount of software development you've done, you should know better than to provide such a useless benchmark.
Bitkeeper, the universe, and everything Posted Feb 24, 2004 23:26 UTC (Tue) by aya (guest, #19767) [Link] Hi!It's convenient that you mention speed, Robert Collins has been working on code lately to speed up arch by cutting down on system calls for file info. This probably won't be merged until 1.3, though. (The current release is 1.2-pre2.) I guess I'm not qualified to say anything about BK's merge capabilities; I'm not going to use the free version, since I may hack arch in the future if I have time, and I'd rather not budget a commercial license. (Please note, this isn't a license flame. It's your software, it's your license, and I'm fine with that. In any case, I know better than to try to resurrect a horse that's been kicked to a million deaths already ... Besides, I'm glad the kernel team is using something better than the previous process.) I do know that I don't really have a handle on arch's merging features, though, so at the very least your comment about documentation rings true. UI and documentation are commonly cited as GNU Arch shortcomings. Still, from what I've seen, arch's merge operations aren't *that* far off from BK's, though I suspect BK's are easier to use overall. The general use pattern is the same; develop in a local branch/repository of a project, filter changes into an integration branch, and have the project lead merge from your integration branch. I will say this about the license, though: the BKL doesn't seem to be linked from any page on bitmover.com anywhere anymore. To read it, you seem to have to download and run Bitkeeper. I realize people bitch about the thing all the time, but that's not good for people who want to read the license to see if they can use BK before downloading it ...
Bitkeeper, the universe, and everything Posted Mar 30, 2004 2:57 UTC (Tue) by ghudson (guest, #20530) [Link] I'm not sure where Larry got the idea that "HP paid for the development" of Subversion; it sounds like he thinks some big company felt charitable one day and decided to dump a few EFTs into open source SCM development.Subversion development is hosted and partly funded by CollabNet (which I have no financial association with), which as I understand it is a startup company whose business model is to sell a commercial product which either does now or will soon integrate Subversion, among other components. By making Subversion open source, I believe they hope to be better able to compete with the heavies like IBM/Rational than they could either by integrating CVS or by developing a proprietary SCM system.
Centralized vs decentralized Posted Feb 27, 2004 4:12 UTC (Fri) by brouhaha (subscriber, #1698) [Link] Subversion can in fact do one thing that BitKeeper can't. It can be used for development of new and improved free software (or open source) version control systems.On multiple occasions the ability to patch CVS and Subversion has been useful to me. And in general, I try to run as little closed source software on my computers as possible. If I really needed the decentralized model, I think I'd investigate GNU Arch before switching to BitKeeper. Years ago, I attended a talk you (L.M.) gave at SVLUG about BitKeeper. I was fully prepared to dislike it due to its being based (at that time) on SCCS. But you did such a good job of explaining the reason for that decision, the advantages of it, and the advantages of the decentralized model in general, that I left the talk feeling like I'd been fully converted to the BitKeeper religion. But when I tried to push BitKeeper at my job, I immediately ran into trouble. Emailed requests for pricing and other licensing information went unanswered. And the per-seat pricing information that was available on the web site was ludicrous. The per-seat price went UP as the number of developers increased. My company was near one of the quantity thresholds, and we were concerned that if we added just a few more developers, we would cross that threshold and suddenly have to pay not just a higher price for the new seats, but possibly to "upgrade" the old seats as well. Yet no one at BitMover cared to even answer questions about these policies. By comparison, when I investigated Perforce, I had no difficulty finding out about their pricing and licensing. Ultimately the company chose to stick with CVS. Were the decision to be made today, Subversion probably would be a serious contender. In fact, I'm trying to encourage my current employer to switch from CVS to Subversion. I fully recognize that BitKeeper is a much more powerful system, and I even agree with your arguments as to why free software isn't likely to match it any time soon. But eventually free software will catch up. It wasn't that many years ago that people didn't think free software would match Excel, and I'm not sure it does 100% even now, but it's close enough.
Centralized vs decentralized Posted Mar 30, 2004 2:25 UTC (Tue) by ghudson (guest, #20530) [Link] I just found this comment, and want to raise a few objections.(1) I wouldn't say Subversion developers "have freely admitted that SVN will never do what BK can do." Some Subversion developers are very keen on having good support for distributed development. (I'm not one of those people, and for all I know, Larry may be right that a tool like SVN can never evolve into a tool as good as Bitkeeper for distributed development. But I don't think it's a foregone conclusion.) Moreover, the logic here seems a bit simplistic. I could probably name some feature of Subversion that Bitkeeper can't currently match (exporting a repository for read-write via WebDAV, just as a wild guess) and make the same claim in reverse, but that's only important to people who want that feature. (2) I certainly have my biases (perhaps there should be a disclaimer in the essay in question; I'll think about it), but I have no vested interest in Subversion and work on it only out of personal interest. I would argue that my conclusions about version control systems have led me to contribute to Subversion, not the other way around. I'm also not a very big Subversion evangelist, despite my role in its development; at work, we still use CVS. (3) "Since switching to BitKeeper, the Linux development pace has gone up by more than 2x, no matter how you measure it" only establishes that BitKeeper is better than manual patch management for projects already organized around the pyramid system. I have no doubt that this is true, but it misses the thrust of my essay. (Also, though my essay mentions the Apache model, there are projects like Mozilla and the *BSDs which have a similar pace of development to Linux, and they do alright with centralized SCM.) I'll confess to not fully understanding point (4); if it's just about a lack of merge history tracking, that's a known (and hopefully temporary) weakness of Subversion. Merge tracking is not directly related to distributed functionality or the pyramid model, although there are some tie-ins. The point of my essay is not to denigrate Bitkeeper's quality--on the contrary, everything I hear suggests that it's a very polished product ("polish" being one of those intangible, subjective, and crucially important features of any piece of software). I only question its necessity for open source projects.
Centralized vs decentralized Posted Mar 30, 2004 2:41 UTC (Tue) by kfogel (guest, #20531) [Link] This mostly fails to address the points Greg Hudson was making.Point number (1) above, and the final paragraph, are not particularly compelling. Being a formal superset is not the same as being a *convenient* superset. Imagine a discussion about the relative merits of two programming languages, where someone says "Well, language X is Turing-complete, and so is language Y, therefore Y clearly can't claim any advantage." Anyone who's tried to write large, modular applications in (say) both Lisp and C would probably disagree -- sure, they are formally equivalent, and you could even paint C as a "superset" of Lisp, in that one is much more likely to implement Lisp efficiently in C than vice versa. Yet many people prefer Lisp, for the kinds of tasks they face. Likewise, Greg is making the twofold claim that a) a certain kind of development process is more likely to succeed, and b) BitKeeper is not as well-suited to that process as centralized-repository systems. The comparison of Linux's pre-BitKeeper and post-BitKeeper change incorporation rates is somewhat spurious. Greg isn't arguing that BitKeeper wouldn't help a single integrator do his job better; he's arguing that that's not a good model in the first place. I'm not saying he's right or wrong, just asking that his argument be addressed, not evaded. A more useful analysis would have rebutted Greg by saying that the way the Linux kernel project uses BitKeeper is not the way Greg claimed they would (if that's the case -- I don't know). Greg's essay was written in such a way as to make quality disagreement easy. He provides obvious hooks on which to hang competing claims; he makes clear, specific statements which could turn out to be wrong or incomplete, and he left doors open for that eventuality. It was well-written and thoughtful, and deserved a response in kind. I don't feel it got one here :-(.
|
|||||||||||
