Slashdot Mirror
Subversion 1.0 Released
Phil John writes "Subversion 1.0 has finally been released. The people who maintain CVS have given us a viable replacement for our de-facto (and aged) versioning system. If you're new to Subversion its feature list looks like fixes for everything that is wrong in CVS, renaming, directory structure and metadata version tracking, file deletion, proper management of binary files and it's pretty portable to boot." According to the download page, binaries may take a few days to appear.
What a strange statement. Do you use XFree86? OpenSSH? There's any amount of such software out there under similar licences, and if the original BSD TCP/IP stack hadn't been under such a licence, it's doubtful the internet would be as interoperable as it is today, and if X hadn't been under the MIT licence, we'd be stuck with a bunch of incompatible proprietary windowing systems.
It won't. Subversion is a traditional, centralized system. Linus wants a distributed system, which Bitkeeper is.
A deep unwavering belief is a sure sign you're missing something...
The question is, what kind of developer that would need version control relies on binaries, hmm?
Are you being serious?
It's very common to work on a piece of software that might rely on some third party library that you don't have source for. In order to get your source tree to compile you're pretty much going to need a copy of that library. Seems pretty convenient to keep it around in CVS.
But besides that, you might have some binary data file that needs to be part of your distribution, i.e. PDF documentation.
A "binary" does not ultimately mean an executable. A binary, as you probobly know, can be any binary file sutch as a PNG image or compressed text file. The defenition is monolithic, so I can already see a mod disagreeing with me.
Your assertions are totally unawarranted. Ifs are meaningless in History, except as a fun exercise.
One could say that to the contrary a copylefted X Window System would have had less forking (widgets, servers, extensions, drivers) and thus the main RI would have been richer, more useful.
And we would be totally unable to prove it either way.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
I think he meant: if you're a programmer that plans on using Subversion, surely you can compile the damn thing yourself, rather than waiting for somebody else to do it for you.
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
Are you saying GPL projects don't fork? For an early counterexample, see emacs/xemacs. Even with the linux kernel, every distribution now maintains its own version, and it's rather hard to drop a vanilla Linus kernel into Red Hat or SuSE or Mandrake and expect it to run the same. But forking wasn't the point. The point with the GPL is that commercial vendors would not have picked a windowing system based on it, because shipping it as part of their system would have meant GPL'ing every graphical program they wrote, thanks to the virality clause. Name a single counterexample of a GPL'd library shipped as part of a commercial OS.
Apparently Subversion 1.0 doesn't support "sharing", where the same file appears in more than one place in the source tree. That's a lack. Microsoft SourceSafe does that, and it helps avoid those annoying situations that result in long include paths.
How about a web interface to sudo for adding user accounts?
/dev/null, whatever. But still, my paranoia's inflamed. By giving them a user my system's at least recognizing their existence, and that makes me uncomfortable because I am uncertain my knowledge of UNIX is complete enough I've locked off all the possible manners in which they could take advantage of that.
You're suggesting I put up a web accessible chmod root script just so someone can run a version control system?
I can see that for some people's situations, using the unix account system would be very attractive. However, not everyones'. I, specifically, have been needing to set up a version control server of some sort. I will probably wind up doing so on a personal machine. It is concievable at some point I could give other persons access to this server. If so, I do not want anyone who has access to this CVS server to have any sort of other abilities on my system. Yes, yes, disable FTP, set shell to
From a security perspective, every moving part you add to a system is a chance for something to go wrong. A versioning system implementing its own internal security system adds a hell of a lot of moving parts, but they're all well contained off in userland, there's some vague notion of a sandbox there. A versioning system using the OS user system is adding a very small number of moving parts but those moving parts are in a much more dangerous area...
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
What worries me more is when people assume that all software being developed is open source.
Or am I wrong? Yes, I know VS is an unholy horror, but some of us are stuck with it for work. I use Jalindi igloo to interface with CVS, and would likely use subversion (heard nothing but good things about it) if I had 2 things:
1) the VS.NET source control plugin
2) a good way to "upgrade" an old CVS repository
I'm guessing #2 is supported, but #1?
Don't get me wrong, Arch is a very nice concept and it has some merits, but don't pretend there aren't advantages to Subversion's architecture. And the Subversion way of doing things is much more natural for a lot of existing professional software development teams. Arch is great for more distributed projects, but it's a bit less intuitive with respect to usage in a more traditional software development environment, and outright useless for cross-platform or non-Unix projects.
$1000 for one seat? What version are you getting and where are you buying it?
Microsoft Visual C++ Professional Edition, which seems to be the cheapest version with an optimizer in the Microsoft price list.
You can get Visual C++, which is all you need to compile most open source stuff, for $100 so
The version of MSVC available to the general public "for $100 or so" is Microsoft Visual C++ Standard Edition, which contains no optimizer. I've read that the performance of its generated code is so poor that one might as well use an interpreted language instead of MSVC Standard for new apps or run the UNIX version of an existing app in the Cygwin API translation layer rather than try to compile the Windows version in MSVC Standard.
I've heard this idea before, but I can't believe it's a good thing to check in code you haven't actually seen and tried out. Can you be absolutely sure the transformation is correct? A regession test won't catch everything.
This task is better performed by an IDE which would render the code in your own style. You won't see the final code, but at least you'll be debugging/testing on it.
Anyway, barely compiling for the last three weeks isn't exactly stable Windows support that I would feel comfortable rolling out into a corporate environment for professional software development work. Like I said before, Arch is a great concept, and I'd love to see more done with it, especially in terms of getting it to work out-of-the-box with Windows (i.e. I can roll it out to a development team with a single installer) so it was useful for cross-platform and Windows development. Until then, it's great for Open Source projects that themselves have a more distributed model of development which is nicely matched by Arch's capabilities.
Also, the BIOS's API has been totally open (and basically unchanged) ever since the original IBM PC.
There are 10 kinds of people: ones who understand ternary, ones who don't, and ones who think this joke is about binary
All files are binary. What most people mean when they say "binary file" is "non-plaintext."
There are 10 kinds of people: ones who understand ternary, ones who don't, and ones who think this joke is about binary
I think that some people can get angry when code under the bsd licence is used in a closed source project
Such people need to stop worrying about how other people's work is used, especially when they specifically permit that use.
However, I've been using Subversion for quite a while, and it has never yet lost any of my data.
I have had occasional RPM database problems, but as far as I can tell they have been due to RPM problems, not due to Berkeley DB problems. In my experience Berkeley DB is fairly robust.In principle, there is no reason why Subversion can't use your favorite relational database as the back end. The Subversion developers chose Berkeley DB as the first back end implementation, but there may be others in the future.
That's rather vague. What's better about Arch's core design? (I'm not trying to knock Arch; I just don't know much about it.)Then you can't complain that you can't install something that was released a couple of days ago!
Richard is happy that Free Software (GPL'ed or not) is sold commercially, either by itself or embbeded in services, what he isn't happy about is for software that has its users submit to the author.
All software should be free as in freedom, so I completely fail to see the problem here. Popularity is a shallow goal, so you should aim for freedom for everyone, instead of popularity. If you respect your users and your software is good, popularity will likely come.
However, if popularity is your goal, you will likely start disregarding many good choices because they can be seen by some as not so popular...
> Is it really common practice to develop in something other than the
> current tree? In my experience, everyone involved in a project is expected
> to work in the most current version of the tree, and to update their local
> working copy first thing every day (and several times throughout the day).
This expectation is problematic, because it effectively prevents anyone on
a dialup connection from being able to contribute. By the time they get
their CVS tree updated, it's well past time to start updating it again.
Cut that out, or I will ship you to Norilsk in a box.
I'm not quite sure how readily available binaries of subversion 0.37 help with the problem of waiting for binaries of subversion 1.0 ...
Secession is the right of all sentient beings.
One of the companies I worked for put the money out for Clearcase and I really liked using it. Granted the vob filesystem was kinda slow, but I could my unix tools against specific versions of the file, not just the latest. The thing that boggled my mind was that we threw it aside when we started using all open source development tools, and thus CVS. I think some of our deployment processes suffered since CVS is not as good at the configuration management that Clearcase was.
Brought to you by Team SPAM! where we believe: "Information in the noise!"
Not really. While the BIOS interfaces certainly have changed continuously over time, they always do so in a backward compatible manner. BIOS is part of the hardware and does not need to be provided in source form. Open source BIOS'es are useless.
If you can't load a kernel through the BIOS boot service, that machine should never have shipped. The BIOS code that does that does not change from system to system.
Because that's only one minor rev behind. There probably aren't that many big changes in 1.0 anyway, so 0.37 will probably be good enough for the days (or weeks? no idea how hard-working the subversion maintainer is...) while waiting for 1.0...
Stop thinking like a UNIX programmer and start thinking like a non-technical person.
What are you talking about? CVS isn't meant for non-technical persons. Never has been. It was designed as a tool for UNIX programmers.
That's rather vague. What's better about Arch's core design?
Well, for instance, it actually can support things like history-sensitive merges without substantial rearchitecting. After RMS asked for a revision control system with digital signature support, Arch's design was flexible enough that it had a finished implementation while the SVN folks were still debating over how they wanted to implement it. Those are just examples, though.
If you want something a bit better, let me point you to a missive by Tom Lord (the Arch maintainer), entitled Diagnosing SVN, and a refutation by Greg Hudson, Undiagnosing SVN. Note in particular Greg's response to Tom's "under-developed notion of version control" claim.