The future of CVS, Subversion 1.0.2, is now available in the source releases area.
Subversion 1.0.2 Available
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Why didn’t they design Subversion to do “Per File” versioning? I think everything else about it is great, but not having a version per file seems… wrong.
Now that I think about it–can you roll back a single file to any earlier point in time, as far as the scenario where a source file was created, checked-out/edited/checked-in a few times, then checked-out, edited, and the developer then decided to roll back to a previous check-in point, somewhere farther back than just the latest check-out? Can this be done, or is it on a “whole branch” basis?
yes.
CVS has always done that, Subversion extends to directory versioning, which, while not the Achilles heel of CVS, might be the Achilles tendon of it, from what I’ve heard.
CVS is a great example of an evolutionary design, and like all such, benefits from a experience-based re-design when feasible.
>can you roll back a single file to any earlier point in time
It is very easy. You can co only the file that need rollback at a special revision, and commit it to HEAD.
Honestly Subversion has done as little as possible to address the problems of CVS. Atomic commits are nice but that’s the bare minimum they had to do to fix the directory problem. No attention has been given to distributed development, but all attention has been given to Subversion as CVS’s successor.
When was the last time OSnews or anyone else did a report on Arch, GNU’s distributed development system which will one day replace BitKeeper for kernel development. If you ask me that’s a hell of a lot more impressive than the laundry list of projects using Subversion, of which I can think of… none.
And here we go again. At the mere echo of anything sounding like “Subversion”, someone has to plug Arch and make a God-vs-cockroach-like comparison.
Instead of bashing around over here, do something constructive and post on the Subversion mailing lists. Point out where you think the problems are, and extensions need to be done, and you’ll get a healthy, well-thought out reply from the developers themselves.
Who said Arch would replace Bitkeeper?
Certainly not Linus.
While Arch might be superior to SVN one drawback is that CVS users have to relearn the workflow. With SVN, most of the time the only thing to remember is to replace ‘cvs’ with ‘svn’ on the command line.
And I guess there are far more CVS than Arch users out there, and those are the targetted users.
@ Anonymous:
> Why didn’t they design Subversion to do “Per File”
> versioning?
Think about it, or better yet, experiment with it for some time. You will quickly realize the advantages of it. I did, and I won’t ever return to per-file versioning if I can help it.
As everything new, it requires some getting-used-to before the awkwardness goes away.
@ Mullighan:
> Honestly Subversion has done as little as possible to
> address the problems of CVS…
…which is very nice since it means CVS users can make the transition with a minimum of hassle.
> No attention has been given to distributed development…
Check out svk, which builds on top of Subversion.
PS: To anyone trying to push Arch whenever Subversion is mentioned anywhere, check out http://www.faqs.org/docs/jargon/A/Amiga-Persecution-Complex.html – you’re not doing your cause any good.
I read the Subversion Book at http://svnbook.red-bean.com last week, and I must say that I’m impressed with the possibilites of Subversion. All those little annoyances in CVS that I found within just a few minutes of using it (the mess with directories, binaries, etc.) are well done in Subversion.
Subversion will definitely get its place in my collection of software tools.
Is there a CVS to Subversion How-To document or FAQ anywhere? I’d certainly be more willing to try it if I had an easy guide to follow on how to migrate my CVS repository over. I don’t have time to read the 300 page Subversion book right now, I’m trying to get work done! 😉
– chrish
I recently evaluated both subversion and arch and chose subversion for my company. Probably the number 1 reason was the subversion book– arch is not documented as well as subversion. All I want a centralized repository where me and 2-3 other developers can collaborate. I don’t want to push the envelope on version control– the existing models work great for me and 99% of the open source projects out there. I don’t need to create branches while on an air plane. I do need to easily move files around in my repository. Subversion it is!
Hey Chris, don’t read all the 300 pages – the Table of Contents should suffice to point you to “Appendix A – Subversion for CVS Users”, http://svnbook.red-bean.com/svnbook/apa.html. It also points you to various ways to convert your repository automatically.
This may have changed, but when I was investigating arch recently it didn’t even have support for spaces in filenames. If you look on the arch website you won’t find any formal documentation.
My point is that while arch may have some impressive advanced functionality, it isn’t a viable solution until more basic issues are taken care of.
The version of the Subversion book I have printed out here basically referred me to the cvs2svn.py tool they’ve got, it didn’t actually include any helpful hints.
So we’ll see what the cvs2svn.py README file says…
– chrish
Since only a complete moron would put spaces in filenames a developer tool shouldn’t have to worry about them.
> Since only a complete moron would put spaces in filenames
> a developer tool shouldn’t have to worry about them.
Yeah_I_fully_agreee.__There_is_no_need_for_spaces_at_all.__Anyone_who_ says_otherwise_obviously_doesn’t_know_how_to_name_use_proper_punctuati on.__As_a_matter_of_fact,_I_have_re-mapped_my_space_key_so_that_it_doe s_advanced_offline_merging_and_branching_rather_than_entering_a_stupid _useless_space_key.__Arch_rules!!!!!