Karl Fogel from the Subversion project announced the release 1.0.0 of the CVS replacement version control system which we introduced a few days ago. Developers are recommended to try it over CVS.
Subversion 1.0.0 Released
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Arch: http://wiki.gnuarch.org/
enough said.
Why is arch so great that it has to be mentioned in every article about CVS or Subversion?
Now to be on topic…could someone tell me honestly what a developer like myself, who is quite content with CVS, would benefit from switching to another VCS such as Subversion, Arch, or something else? That’s not a troll, just an honest question. Better merge algorithms? Simpler/faster operation? Easier setup?
I know that Subversion adds the ability to delete directories and rename things easily, but is there anything else important that it adds?
Thanks.
Commits are atomic. This is the best feature over CVS.
better than CVS: directory/file moves/renames
CVS lacks a couple of things which, in my opinion, are quite nice and are present in other systems.
One is atomic commits, the other is ability to move/rename. There’s some other stuff but, for me, those are the most interesting ones.
The only thing about svn which I still don’t like is the setup.
Features for (Arch) (Subversion) (CVS):
Atomic Commits: (yes) (yes) (no)
File Renames Handled Cleanly: (yes) (yes) (no)
Advanced Merging Features: (yes) (somewhat) (no)
Easy Development On Branches: (yes) (somewhat) (no)
Automatic ChangeLog Generation: (yes) (somewhat) (yes with add-on software)
All Revisions Accessible As Regular Trees: (yes) (no) (no)
Distributed And Private Repositories: (yes) (no) (no)
Easy Server Administration: (yes) (no) (no)
Scalable Performance And Admin: (yes) (no) (no)
Web Browser Interface: (yes) (yes) (yes with add-on software)
Arch doesn’t seem to have binaries for Windows which doesn’t make it easier for me as a developer working on Win
i think you must read FIRST before writing:
http://wiki.gnuarch.org/moin.cgi/Native_20WIN32_20Support
Works in Windows: (no)(yes)(yes)
Why is it that every story about Subversion has a bunch of people posting anonymously about arch? Can’t people stand up for themselves, if they’re going to post off-topic stuff?
Not to mention, that the Subversion 1.0.0 release comes four years after its inception. The dev team has worked long and hard to produce a solid, stable, and functional release for people. Give them some credit for their hard work, rather than this blather about other SCMs.
[I have no personal opinion one way or another about arch. I just get sick of seeing arch supporters posting (off-topic) into svn forums all the time]
Hey guys, they are not posting about Arch Linux. That’s great distro, but not at all what they are refrencing. If you actually go to the link, you’ll see Arch is also another version control software. I don’t really know how great it is and all, I was just trying to keep the Arch Linux distro from getting a bad name from spamming off topic.
I think a lot of arch/tla promoters jump in to svn promotion because svn seems to get a lot of publicity in comparison, and I’m not convinced it’s deserved. I’ve tried really hard to like svn, but too many things have bothered me about it:
– being explicitly based on WebDAV seemed silly; why not something semi-generic that could easily interface with WebDAV, instead? And otherwise make use of things like SSH?
– why a flat db as a back-end? It would seem to be more hard work to implement a file-system/API on it, and I was quite impressed by Monotone’s use of SQLLite, which meant no loss of speed, but a huge jump in flexibility and trouble-shooting.
– it seems like the basic design wasn’t ‘there’, i.e. I’ve read many posts complaining of another redesign of svn’s API and under-lying structure.
– OK: it’s playing a lot like it’s arch vs. subversion. That’s not a bad thing, either as they both come at it from different angles, but a lot of people forget there’s quite a few Next Gen OSS VC/SCM systems being worked on, several worth paying attention to. I for one am putting a few bets on Monotone, just because the super-disconnected-repository design shows a lot of promise (and so-far it seems to work quite well) and the underlying design was meant to be OS-agnostic.
re: webdav. Note that SVN does have the ‘svnserve’ server option which can also be tunneled via SSH. You don’t have to use WebDAV or Apache 2.0. They will provide more features and options, but it isn’t the only solution.
re: Berkeley DB. note that SQLLite wasn’t released until *after* the SVN project started. It don’t know what the feature set at that time was, but we simply made a choice. BDB was known and stable, whereas SQLLite was a newcomer.
re: design. Please provide some specifics rather than hand-wavy references.
re: alternatives. Sure, but this topic is about announcing Subversion 1.0, rather than a discussion about SCMs.
>- being explicitly based on WebDAV seemed silly; why not >something semi-generic that could easily interface with >WebDAV, instead? And otherwise make use of things like SSH?
this is untrue. see http://svnbook.red-bean.com/html-chunk/ch06.html#svn-ch-6-sect-1 for details. you can use svnserve as well.
by the way: i think one of the killer features of subversion is its documentation which is simply one of the best you will ever find for an opensource project. in my eyes this is a major advantage over other versioning systems.
Hey guys, I posted the:
Features for (Arch) (Subversion) (CVS)
Post because I thought it was both relevant and interesting (it is useful to know how subversion compares), and I did not intend it to be a plug for Arch (neither was it one).
On the contrary, I use Subversion on FreeBSD and think the world of it and have no intention of using Arch.
Good job to all project developers. This is a huge accomplishment!
re: the ‘svnserve’ option is a new one to me. guess I gave up on svn long before something more useful like this arrived — the last time I had time to seriously look at it (and I believe it was only months, rather than years), there was only WebDAV via Apache (libneon?), and local-connection.
re: design. i’m afraid i don’t have any specifics book-marked, but I do remember the api changing frequently and fundamentally enough to imply no solid design before starting. I know you’re going to tell me this is what happens near the beginning life of any product, but I’m only bringing it up because it was happening for a long time after being proclaimed the ‘Successor to CVS’ — i.e. long before being anywhere near worthy of such a title — which made it seem kind-of naive and off-putting.
To be fair, it was just as off-putting to use ‘arch’ when it was written in Shell, until you realised that was all part of proving the design, and when ‘arch’ went 1.0, ‘tla’ (the C-version) appeared right on its heels.
One aspect of the design I’ve always been unsure about is the way it’s effectively a full representation of a file-system, in the database. For an VC/SCM system, this seems like over-kill and adds a chunk to the mix which may have been better left out for most things, and such a thing seems more useful to a _mountable_ VC file-system similar to a VAX.
But anyway, congrats on making 1.0, as it was definitely a lot of work to get there, and besides anything else, the discussion going around _all_ the OSS VC/SCM mailing-lists is very, very interesting and enlightening.
congrats to the developers…
I will use svn
I keep seeing this term everywhere, but I don’t understand what exactly are atomic commits and what’s the diffrnce from “normal” commits.
it’s like a transaction in the database field. if for some reason a commit fails, the repository remains unchanged. if something goes wrong during a cvs commit you have some updated files and some which are not – in the worst case a broken repository.
I’ve tried Arch, Perforce, BitKeeper, Source Unsafe, Subversion and some other stuff. First round I satisfied with a open source license to Perforce (nice ppl), but lately I want to protect some of my code and restrict what people have access to it, so I went out on a search.
I find that Perforce IS the best tool. It comes in binary packages to almost every platform. It’s has easy deployment, good documentation and easy administration features. The big problem is that it costs $750 per user if you don’t develop open source. I switched from perforce to subversion recently (0.37) and found that it behaves nicely. So far it’s easy to use and administrate. Setting it up was a bit more troublesome then perforce. Congrats people to the 1.0 release. It’s really nice.
I had arch as an alternative to perforce, but it forced a lot of stuff on you. You must use branches and stuff, long and complicated names. Subversion keeps it simple and does what you want without forcing a lot of stuff on you. Subversion has gained a lot of momentum lately and it will be nice to see how it progresses.
Once again, congrats to the 1.0, it will serve me nicely
I think using Apache is great compared to using its own server. CVS’s pserve is a known security liability. Apache, on the other hand, is well-tested and relatively secure. What’s the point of introducing yet another server when you’ve already got a nice, stable one that does what you need?
> – being explicitly based on WebDAV seemed silly…
> – why a flat db as a back-end? It would seem to be
> more hard work to implement a file-system/API on it…
Ehm… 😀 Note that WebDAV / DeltaV basically *is* a file system over the web. 😉
Besides, I think that the SVN designers showed some exceptional skill far too seldom seen in OSS development: reuse. Why the heck implement your own protocol, your own authentication (well, they did so anyway with svnserve… 😉 ), your own backend, when all that stuff already is available, and readily so on most machines?
Being able to use port 80 for checkin / checkout has also been a big win for me. Thanks SVN team, and looking forward for improved merge support!
I’m not sure how this compares to other SCMs, but on Subversion, every commit is associated with a revision number. As a result, it is very easy to see which updates go together, and you can tie these revision numbers to bugfixes, etc.
Can the Arch zealots who insist on touting Arch on every Subversion related article show me…
A Windows GUI utility with Explorer integration similar to http://tortoisesvn.tigris.org
A VS.net snap-in similar to http://ankhsvn.tigris.org/
A nice looking web frontend similar to http://websvn.tigris.org/ (see http://svn.pdtp.org/ for an example of how it looks deployed)
Basically, if you’re doing Windows development at all, Subversion is *clearly* the better choice as Windows is substantially better supported. With Arch it seems if you’re doing development outside of Cygwin, you’re basically SOL as the native port is no where near production quality.
I think using Apache is great compared to using its own server. CVS’s pserve is a known security liability. Apache, on the other hand, is well-tested and relatively secure. What’s the point of introducing yet another server when you’ve already got a nice, stable one that does what you need?
*Exactly*
When using WebDAV, all of the Subversion code is isolated behind Apache and mod_dav. Authentication is handled by Apache itself, and encryption is handled through mod_ssl. This means the complexity of the Subversion code itself is kept to a minimum, and since the WebDAV module itself is simply a wrapper around libsvn (and on the client side, libneon) the only Subversion-specific code is really libsvn itself. Furthermore, since libsvn itself sits on top of the Apache Portable Runtime and db4, all the low level mechanics had been abstracted, debugged, and tested extensively long before Subversion was even conceived.
The Subversion developers have done an excellent job with code reuse, and consequently have developed a robust and secure tool.
Well said!!
I’ve switched over from cvs to svn last week (using subversion 0.37). There are tools to convert repositories but I chose to start with a clean slate (throwing out my old cvs directory hierarchy which I’ve put up with for a while).
My first impressions are that svn is very easy to get up and running for cvs users.
Contrary to FUD out there, svn does NOT require Apache. svn can use either Apache (via mod_dav_svn.so) or it can use its own svnserve application to be the network server.
However, I chose to setup svn using Apache because I was already running it and I wanted to use ViewCVS on the same server. Turned out to be a great move since I can leverage all the existing authentication/users I had on Apache before using svn.
My favorite features of svn after switching from cvs:
1. Atomic commits with revision numbers per commit rather than per file.
2. Ability to move/rename both files and directories without losing history.
3. Cheap (constant time) copies/branches/tags!!! Since only diffs are stored, I can copy/branch/tag huge projects without doubling the size of my repository.
4. Directories and metadata being versioned too.
5. More benefits exist but those aren’t important to me.
6. Modular c api design and parseable output allowing 3rd party products to be created more easily than for cvs. This allowed projects like TortoiseSVN, WebSVN, ViewCVS, etc. to support svn pretty easily.
7. For people who want a distributed svn, projects like svk.tigris.org built on top of svn are going to fulfill that need as they mature.
Loyalty to technology is foolish. Loyalty to deserving people is what counts. If something better comes out and it makes sense for you, switch to it. I’ve been VERY happy with these recent switches but you won’t know if you’ll like it unless you try it out:
cvs -> svn
tortoiseCVS -> tortoiseSVN
perl5 -> ruby (but will check out perl6 in a few years)
ie6 -> mozilla firefox 0.8
outlook express -> mozilla thunderbird 0.5
visual studio 6 -> visual studio .net 2003
openoffice 1.1 –back-to–> ms office xp (will try 1.2)
Note: You can browse a SVN repository with ViewCVS even if using the SVN standalone server (i.e., not using the Apache module).
And not using Apache is as easy as ./configure –without-apache…