Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Software Book Reviews IT Technology

Pragmatic Version Control Using Subversion 235

Posted by timothy from the subvert-your-own-intentions dept.
Dean Wilson writes "When it comes to software development the Pragmatic Programmers are widely recognised as masters of their trade, but with the release of their award-winning Starter Kit Series they've begun to gain a reputation for writing, editing and finding book authors that are as talented as they are. Pragmatic Version Control Using Subversion by Mike Mason is an excellent example. The book itself is an introduction to using Subversion (focusing on the command-line tools), but while it clearly covers all the essentials: basic commands, tagging, branching, etc. it also delves into some of the related, but often overlooked areas of version control. When it comes to version control systems, CVS has long been the workhorse of the Open Source and Free Software movements -- but with the release of Subversion, it's time to put the old nag to rest; and this book tells you what you need to do it." Read on for the rest of Wilson's review.
Pragmatic Version Control Using Subversion
author Mike Mason
pages 224
publisher The Pragmatic Programmers
rating 8
reviewer Dean Wilson
ISBN 0974514063
summary An excellent guide to version control with Subversion for developers and sysadmins

Chapters on repository layouts, integrating third party code (into your source tree and products) and conflict resolution all help raise this book from just being a single application tutorial into a best practices guide that you'll come back to long after you've gained confidence with Subversion itself.

Pragmatic Version Control Using Subversion is very similar to Pragmatic Version Control Using CVS, but this is in no way a criticism! The previous book was the best introduction to CVS that I've read, and this related volume manages to retain the winning formula while adding useful sections, such as CVS hints, to help people migrating across.

While the book has a broad appeal, the ideal audience are those developers who know they should be doing version control but have heard it's too complex, have been burnt by previous mistakes, or just don't know where to start. Seasoned developers will also find this book useful, but in different ways. For instance, using it as an easy to scan and follow reference, handing it down to less experienced colleagues, or even just for quickly bringing themselves up to speed when moving from CVS to Subversion.

Considering the book's slim size (or quick download, if you purchase the PDF version) it packs in surprisingly wide coverage of the important topics. The first two chapters provide an overview and sell the benefits of using a version control system. They cover what should and shouldn't be under version control, and clearly explain the terminology required to understand both the technology in general and the book's later chapters.

Chapters 3, 4, and 5 get you working from your own Subversion repository and introduce the essential commands. They show how to create, add and import your projects in a clear, easy-to-understand way. Once you have some files to work with, they take you through a well-paced tour of the simple operations; checking out, committing and accessing the files in different ways.

Following these, Chapter 6, "Common Subversion Commands," shows some of the more complex but essential tasks you'll want to perform in Subversion; setting properties, looking at changes and their associated history and how to handle merge conflicts. These are all presented in short sections that provide enough information to be useful on a day-to- day basis while not leaving beginners bogged down in the minutiae.

Jumping ahead slightly, we leave the part of the book that everybody using Subversion should read and move onto the more powerful, and complex, functionality such as "Using Tags and Branches" (Chapter 8) and the more abstract topics of "Organising Your Repository" (Chapter 7) and dealing with "Third Party Code" (Chapter 10).

Chapter 8 stands alone in the second half of the book due to its coverage of a very technical subject; chapters 7, 9 and 10 are more abstract. Tagging and branching are one of the more notorious areas of version control, but this book -- much like the CVS book before it -- manages to explain not only when and how to use both tags and branches, but also provides enough guidance to allow the reader to 'smell' when something's wrong and adding them would make it worse.

Chapters 7, 9 and 10 logically combine to cover the issues surrounding setting up your own project, including the project's structure, the integration of third party code, external projects, and binary libraries such as Nunit or Java mock libraries. Considering the amount of maintenance coding (as opposed to new projects) that happens in the world, these chapters might not be immediately useful to a fair chunk of the readership. I don't think they should be removed, though -- better to leave them in and show best practices and experience-driven common sense than remove them and let people make the same mistakes over and over again.

It's worth noting that the appendices are a lot more useful than the filler material typically found lurking at the back of a book -- they cover a couple of topics that don't fit elsewhere and help round out both the book's coverage and appeal.

Appendix A is more relevant to system administrators than developers. It shows how to install Subversion on the server. It then gives a brief introduction to configuring, serving (using either the native svnserve, svn over SSH or via Apache) and adding basic security to your repositories. It finishes off with a short, but useful, digression into backing up your hard work.

This appendix provides a valuable, quick guide to getting a Subversion install in place. It's a good starting point for anyone who needs to actually run and maintain a Subversion server.

The remaining appendices vary in usefulness. Appendix B is a concise introduction to migrating a CVS repository to Subversion; this is something you either need desperately or won't care about. Most of Appendix C shows how to perform common tasks using the TortoiseSVN extension for Windows Explorer; this won't appeal to the Unix/Linux crowd but might help sway Windows developers away from the hell that is Visual Source Safe.

In short, whether you're new to version control in general or just Subversion itself, this book is highly recommended. Clear, concise and crammed full of useful, important and dare I say, pragmatic, advice and information. An excellent book in its own right and a worthy addition to the Starter Kit Series.

Dean Wilson is a System Administrator at Outcome Technologies. His personal site is unixdaemon.net. You can purchase Pragmatic Version Control Using Subversion from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
This discussion has been archived. No new comments can be posted.

Pragmatic Version Control Using Subversion More

Pragmatic Version Control Using Subversion

Comments Filter:

  • Another subversion book (Score:5, Informative)

    by halosfan ( 691623 ) on Thursday February 10, 2005 @06:31PM (#11635721) Homepage
    For those looking for Subversion documentation, there's also an excellent Subversion book, with electronic copy available for free, at http://svnbook.red-bean.com/

  • Lots of folks are switching over... (Score:5, Informative)

    by tcopeland ( 32225 ) * <tom AT thomasleecopeland DOT com> on Thursday February 10, 2005 @06:31PM (#11635722) Homepage
    ...Subversion support is one of the most requested features [rubyforge.org] on RubyForge.

    Is there a StatCVS [sf.net]-type reporting tool for Subversion? I suppose StatCVS could be modified to support Subversion... there's been some discussion of it on their mailing list...

  • I need to practice reading... (Score:3, Funny)

    by 4ginandtonics ( 455958 ) on Thursday February 10, 2005 @06:31PM (#11635723)
    Did anyone else misread

    Pragmatic Version Control Using Subversion

    as

    Pragmatic Version Control Using subterfuge ?

    Maybe I've just been doing too much sneaky stuff today...

  • Is it better than the Subversion Book? (Score:5, Informative)

    by dmh20002 ( 637819 ) on Thursday February 10, 2005 @06:31PM (#11635730)
    The Subversion Book [red-bean.com] seems to have most of what you need to know and its free as in speech and beer.
    from the review it does seem to have a couple of chapters about general project organization that aren't in TSB. Otherwise it the list of topics seems to be right out of the oreilly book.

  • Their reputation (Score:4, Funny)

    by spludge ( 99050 ) on Thursday February 10, 2005 @06:33PM (#11635745)
    they've begun to gain a reputation for writing, editing and finding book authors

    Good for them, how do you edit a book author though? Remove a finger or two if they don't send you their rough draft?

  • Anyone considering switching to SVN... (Score:5, Informative)

    by greppling ( 601175 ) on Thursday February 10, 2005 @06:33PM (#11635747)
    ...might find this thread [svn.haxx.se] in the svn development list on the switch of Mono to Subversion worth a read. This transition did not go as smoothly as it could have gone, if the Mono guys had prepared this move a little better.

    Executive summary:

    • The only technical regression from CVS to SVN is that 'svn blame' is still a lot slower than 'cvs annotate'.
    • Let me just quote: No project should ever jump into a new version control system without experimenting with it first, or assessing the general impact it will have on development policies. Switching VC systems is never "just" about learning the syntax of a new program -- it always involves re-evaluating and re-creating all of your project's procedures.

    By the way, the GCC team is starting to make experiments with svn, and it looks like they might switch in 2 or 3 months.

  • why is this better than cvs? (Score:3, Interesting)

    by Anonymous Coward on Thursday February 10, 2005 @06:34PM (#11635756)
    So as a crusty old fart who hates changing tools just because they are new and cool, and am pretty much happy with CVS, what is it that subversion does better than CVS that should make me want to switch?

    And this is a real question asked for the puposes of gaining information, just just a snide "here is a nickel go buy a real computer" kind of remark.

    • Re:why is this better than cvs? (Score:5, Informative)

      by dingbatdr ( 702519 ) on Thursday February 10, 2005 @06:56PM (#11635958) Homepage
      From the document:
      Subversion's Features

      When discussing the features that Subversion brings to the version
      control table, it is often helpful to speak of them in terms of how they
      improve upon CVS's design. If you're not familiar with CVS, you may not
      understand all of these features. And if you're not familiar with
      version control at all, your eyes may glaze over unless you first read
      Chapter 2, Basic Concepts, in which we provide a gentle introduction to
      version control in general.

      Subversion provides:

      Directory versioning

      ~ CVS only tracks the history of individual files, but Subversion
      implements a virtual versioned filesystem that tracks changes to whole
      directory trees over time. Files and directories are versioned.
      True version history

      ~ Since CVS is limited to file versioning, operations such as copies
      and renameswhich might happen to files, but which are really changes to
      the contents of some containing directoryaren't supported in CVS.
      Additionally, in CVS you cannot replace a versioned file with some new
      thing of the same name without the new item inheriting the history of
      the oldperhaps completely unrelated file. With Subversion, you can
      add, delete, copy, and rename both files and directories. And every
      newly added file begins with a fresh, clean history all its own.
      Atomic commits

      ~ A collection of modifications either goes into the repository
      completely, or not at all. This allows developers to construct and
      commit changes as logical chunks, and prevents problems that can occur
      when only a portion of a set of changes is successfully sent to the
      repository.
      Versioned metadata

      ~ Each file and directory has a set of propertieskeys and their
      values associated with it. You can create and store any arbitrary
      key/value pairs you wish. Properties are versioned over time, just like
      file contents.
      Choice of network layers

      ~ Subversion has an abstracted notion of repository access, making it
      easy for people to implement new network mechanisms. Subversion can plug
      into the Apache HTTP Server as an extension module. This gives
      Subversion a big advantage in stability and interoperability, and
      instant access to existing features provided by that
      serverauthentication, authorization, wire compression, and so on. A
      more lightweight, standalone Subversion server process is also
      available. This server speaks a custom protocol which can be easily
      tunneled over SSH.
      Consistent data handling

      ~ Subversion expresses file differences using a binary differencing
      algorithm, which works identically on both text (human-readable) and
      binary (human-unreadable) files. Both types of files are stored equally
      compressed in the repository, and differences are transmitted in both
      directions across the network.
      Efficient branching and tagging

      ~ The cost of branching and tagging need not be proportional to the
      project size. Subversion creates branches and tags by simply copying the
      project, using a mechanism similar to a hard-link. Thus these operations
      take only a very small, constant amount of time.
      Hackability

      ~ Subversion has no historical baggage; it is implemented as a
      collection of shared C libraries with well-defined APIs. This makes
      Subversion extremely maintainable and usable by other applications and
      languages.

  • The book sounds very interesting, but the way it is described makes it seems like it only goes through the basics. What if you want more in-depth reading on tagging and other simple necessities that you cant go without knowing about well?
  • The book isn't even available yet (see the link from bn.com). One must presume the reviewer got an advance copy from the publisher, who may have given it away expecting a favorable review.

    What reason do we have to to believe that this review isn't complete astroturf? What is his relation that caused him to get an advance copy?

    It may well be an honest review, but I'm inclined to be a lot more skeptical. Especially since there is no mention in the review of the fact that he got an advance copy.
  • Comment removed based on user account deletion
    • Did you miss:

      In addition to that, read:

      which outlines some of the properties you want in a version control system. Tools like CVS and VSS don't capture all the information they could, which means you don't actually have an accurate history of what happened.
      There are also a few rants by Greg Hudson and Tom Lord about changeset vs tree-history. Search google :)

    • Re:Benefits of Subversion's revisioning system? (Score:5, Informative)

      by aardvarkjoe ( 156801 ) on Thursday February 10, 2005 @06:57PM (#11635961)
      With Subversion, how is it beneficial to have a file that hasn't changed have its revision number incremented on every check-in? Doesn't that make it very difficult to track changes to one source file?

      The general idea is that in a given set of interrelated files, it does not make sense to think about revisions on the file level, as a change to one file is really a change to an entire project. Simply assigning revision numbers on a repository-wide basis simplifies the revision number system and does away with one bit of weirdness in CVS. It's a bit strange if you're coming from a system that works with per-file rather than per-repository versions, but it makes a lot of sense when you get used to it.


      As to difficulty tracking the files -- no, it's not difficult. Finding the revisions associated with changing a file is easy, so tracking the changes is no more difficult than in CVS.

    • It depends on your goals. I prefer SVN's revisioning system (having used both CVS and CMVC, which use the same revisioning). The nice thing about it is if you extract revision n, you'll know all the files you extract from the repo are as the repo looked when revision was made. This is non-trivial with CVS or CMVC's revisioning system unless you know the version number of all the files in the entire repo and extract those version numbers.

      It's still easy to tell when individual files were changed using somet
      • This is non-trivial with CVS or CMVC's revisioning system unless you know the version number of all the files in the entire repo and extract those version numbers.

        If you have the foresight to tag your source tree, or you happen to know the
        date that you want to grab (cvs log foo.c, will greatly assist in this if you
        keep usuable logs). SVN does it better, but it's not really all that hard with
        CVS.

    • Re:Benefits of Subversion's revisioning system? (Score:5, Insightful)

      by avalys ( 221114 ) on Thursday February 10, 2005 @07:10PM (#11636069)
      It's much better to have repository-wide revision numbers, because it means that a revision number identifies the state of an entire project at a specific point in time, not just the state of specific file.

      This doesn't make it any harder to track changes to individual files. When you run "svn log" on a file or directory, you only see the log messages/revisions listed where that file or directory was changed.

      It's really quite an elegant system.
      • Comment removed based on user account deletion
        • It sounds like you're assigning meaning to the individual revision numbers on files. So you know that create_db.sql version 1.14 is special somehow and people understand these numbers mean something.

          That's fine, and if it's working for you you don't need to change it, but personally I find it hard to remember that in version 1.15 I added a new table and that branched version 1.2.4.15 corresponds to the current production code.

          In Subversion you'd use symbolically named tags, which are copies of directory t

  • Sample excepts (Score:4, Informative)

    by darkpurpleblob ( 180550 ) * on Thursday February 10, 2005 @06:42PM (#11635832)

    Sample excerpts from the book are available in PDF format from the book website [pragmaticprogrammer.com]. You can also download the full Using Tags and Branches chapter artima.com [artima.com] (free login required).

    <gripe>Most tech books these days have a page on the publishers website, and some offer a sample chapter for download. Book reviewers should include a direct link to this book page, and note what excerpts/chapters are available for preview, if any (and prevent people like me karma whoring).</gripe>

  • Conflicts and Merging vs Locking (Score:5, Interesting)

    by dmh20002 ( 637819 ) on Thursday February 10, 2005 @06:42PM (#11635834)
    We are switching from PVCS to subversion. Besides being pretty crappy and expensive, PVCS uses the lock/modify/checkin paradigm. Every time when I convert a PVCS user to Subversion they are scared because of the edit/conflict/merge idea. "OHMYGOD I have to lock my files or anything can happen". (Because I am not articulate) I have a hard time conveying the benefit of the CVS/subversion way.
    My rationale is that if two people need to modify a file the conflicts exist independent of the version control mechanism, its just that locking serializes modifications and and merging has you modifying in parallel and then fixing it all at once, which is more efficient than making someone wait. Not to mention the idiots who lock everything and then go on vacation.
    I usually just say 'try it and you will see that subversion is way easier to use and the rare conflicts are easy to merge'.
    Any recommendations?

    • Re:Conflicts and Merging vs Locking (Score:5, Informative)

      by mmurphy000 ( 556983 ) on Thursday February 10, 2005 @06:50PM (#11635916)

      FWIW, the lock/unlock model (a.k.a., "reserved checkouts") is on tap for Subversion 1.2, according to the roadmap [tigris.org].

    • Other justification... (Score:4, Insightful)

      by SuperKendall ( 25149 ) * on Thursday February 10, 2005 @07:02PM (#11635995)
      The way I like to put it to point out why ClearCase and others of its ilk are such a beast to work with compared to CVS, is that broken merges are fixed BY the people that cause them, BEFORE they screw up the repository.

      With the "normal" source control systems that use the reserve/checkin style, a programmer may work on several files - perhaps they even work on them unreserved to be nice to others (as is becoming policy here).

      You still have the issue of "The Merge" That is, the programmer doing the development is nt getting changes made to those files while he is working, and others are not seing his work.

      So when it comes time to check in all the files, a prigrammer checks most of them in - but then possibly runs into issues with merges in the last few files. Lots of commercial merge tools seem poorly designed to help the average programmer deal with issues, sometimes they simply automatically hose the merge without the programmer even knowing.

      Using a CVS system, the programmer is able to keep in sync all through development by constantly updating files. That means that issues caused by him will also be resolved by him on the fly, instead of someone else discovering a merge went wrong later. It makes the day of checkin no longer something to fear, since you are already synchronized and can be reasonably sure the system works BEFORE you do the checkin, instead of checking after and possibly having a broken build.

      Sure that checkin might cause someone else issues, but they will tend to be isolated to a developer and not affect the whole team at once.

      So basically CVS style operation encourages programmers to keep in sync with what other people are doing - I honestly believe that if it did not work this way and people were forced to deal with reserved files, the whole OpenSource movement would be a fraction of its current size and success.

      Yes I know ClearCase can kind of do something like that, but not very well and I have seen clear case totally bungle automatic merges before.
      • Yes I know ClearCase can kind of do something like that, but not very well

        No, it can do exactly that, and very well. If it is set up correctly, basically designers can create their own side-stream, and do repeated merges into it to keep up to date.

        and I have seen clear case totally bungle automatic merges before.

        I have seen *designers* totally bungle merges before. A perfect merge tool or process does not exist; but it nearly always works fine. Automated merge tools are nearly always a big help though.

        • No, it can do exactly that, and very well. If it is set up correctly, basically designers can create their own side-stream, and do repeated merges into it to keep up to date.

          So where can you find more information on ClearCase side streams and bringing in external changes? I have ever been frustrated by a lack of good ClearCase documentation, and whoever set up our ClearCase systems at work sure does not know about this.

          However, I still find setting up a sidestream (private branch? Google had nothing on
        • and I have seen clear case totally bungle automatic merges before.

          I have seen *designers* totally bungle merges before.

          The biggest problem with Clearcase is that developers (or designers if you prefer) do not want to take a 3 day course to learn how to use a tool that is peripheral to their core job. So they end up using a very small part of it (badly), so small (and so badly) that they might as well be using RCS.
    • I use pvcs and I'm looking into switching - were you using the promotion model, and if so, what did you replace it with?
    • The real concern we had in a similar conversion was trusting what actualy ended up as the last checked in code, and how to track contention on common code being worked on. In reality, even with decent sized teams, its easy to know in general who is working where in the code base - the managers and team leads should know, people paying attention to a check-in log should see the traffic too (assuming the change notices go to a distribution email list).

      For knowing what is last in still works as intended, upd
    • Every time when I convert a PVCS user to Subversion they are scared because of the edit/conflict/merge idea.... I have a hard time conveying the benefit of the CVS/subversion way.

      The fundamental argument is, "If it's so horrifying to be without [X], why doesn't the doom and gloom actually happen to people who try living without it?", followed by pointing out the large number of people living without it.

      This same argument can be applied to a lot of dogma that we've accreted over the past few decades... s
    • Here's the killer argument: file locking gives a false sense of security. Imagine: Developer A has foo.h checked out, while developer B has foo.c checked out. Developer A makes changes in foo.h that break foo.c. Notice that developers A and B both had locks on their respective files, and a conflict still arose. So locking is as bad a solution - or worse - than concurrent versioning. At least with concurrent versioning, developer A can change foo.h and foo.c at the same time, then merge his changes with
    • I've been doing the exact same thing you are over the past couple weeks, and it took me about 15 pages of documentation on lock-modify-unlock and copy-modify-merge (with branching) to get to where I believe I can convince everyone that Subversion is better (plus a good 50 pages or so on how to use Subversion). Start with the beginning of the Subversion book [red-bean.com]--it explains things well.

      Also, assuming you use Windows desktops, use TortoiseSVN.
    • Here is a great reason for using a non-locking system such as SVN or CVS... when you use automated refactoring such as available in eclipse and intellij, it touches many files to fix up the code. With a lock-style mechanism it prevents these auto-actions being taken.

      One argument I can already hear is 'by minimizing changes we can ensure quality/safety/etc/etc'... this is a false sense of safety. We know that minimal changes really never are safe, the classic 'one line fix' which breaks the world.

      The onl
  • Reasons subversion seems to be better (i.e. stuff CVS doesn't have):
    • Atomic Commits
    • Faster tagging / branching
    • Natively client/server
    • Directory structure versioning
    • File rename versioning
    • etc.
    Anyone have success stories in moving from CVS to Subversion? Any caveats?
    • Subversion uses alot of RAM for some operations (like 100MB+ for a "svn up" or "svn switch" on OpenBSD source tree). This makes Subversion somewhat hard to use on systems with little RAM or many concurrent users. I don't know if that has changed, but I think that the Subversion developers are working on it.

    • Re:Subversion better than CVS? (Score:4, Interesting)

      by wmshub ( 25291 ) on Thursday February 10, 2005 @08:05PM (#11636607) Homepage Journal
      A few months back I got a job at a place that had started using subversion. I liked it enough to switch my main project to subversion also.

      As expected, there were some hassles at first, due mostly to me not knowing subversion as well as I knew CVS. But in the end, my view is, it's much much better.

      Improvements are what you list. The only minus that I've found is that the "svn:externals" entry isn't as good in some ways as the CVS submodule system...that is, if I have a several projects in a repository that share some library code, the only real way to do this is to pull the shared code in via svn:externals. But when you do this, you have to do separate commits on the project and on each so-called "external" library, even though they are all from the same svn database. In CVS, this wasn't necessary, you can pull in submodules all you want and they commit with one command (of course internally CVS breaks them up into separate commands due to the CVS multi-directory problems, but at least it looks like a single checking). It's not a huge issue, but it's the only thing I can find where subversion is clearly worse than CVS.

      End result: the switch was definitely worth it to me. Love being able to move and/or copy files and have the history carry over. Love being able to truly delete a directory, not just blow away all files. Love the system wide version numbering. Love getting rid of the crufty x.y.z.p.d.q.r.s.t numbering system of CVS. Overall, once you have the system down, you'll be glad you switched. :-)
    • Take a look at Meta-CVS. This takes care of most the issues people have with CVS. The directory structure versioning in Meta-CVS is insanely better than Subversion's. Why? Because the directory structure is represented as text markup, and so it can be branched and merged. Plus a bunch of nasty corner cases are correctly handled (parellel edits and deletes, concurrent adds of the same file name in the same place, etc).

      Atomic commits? I proposed an algorithm for adding these to CVS in a straightforward way.

  • darcs (Score:2, Interesting)

    by mgoss ( 790921 )

    I've played with cvs, subversion, arch, darcs and I honestly think darcs is easiest to use and best of all of them I've played with.

    The only thing I would change in darcs is the way it handles binary files. It can't apply patches to binary files, it has to save full copies of them. Not very condusive to projects with lots of binaries.

    Subversion, on the other hand handles this better.

    But I still like darcs better... its features are sweet.

    • I switched to subversion from CVS to get the file renaming, but disliked the binary repositories, whether as a Berkeley DB or binary files, so I tried darcs, and it is just fine. I don't see it as any mind boggling revolutionary change, but it is more of a change than CVS to Subversion. I also like it having ordinary repositories, no special binary format that hides everything. There is something refreshing and liberating about the way it works. I could not go back to CVS or Subversion without feeling l
      • Subversion now has a file system version as well, so you aren't stuck with Bezerkly db if you don't like it.

        • Right, but ... (Score:3, Interesting)

          by A nonymous Coward ( 7548 ) *
          It's my understanding that the file system repository is also binary. I really like CVS's text repositories for two reasons. One, a vague sense of security, that if a file gets corrupted, I can at least make an attempt at manual repair. Two, I can do a quick read-only edit of a repository file to see some code, I don't have to waste time with checking it out, just go look. Grep also works on it. If I want to find some code that was put into Attic a long time ago, grep works wonders. I don't know how y

          • Re:Right, but ... (Score:4, Insightful)

            by the eric conspiracy ( 20178 ) on Thursday February 10, 2005 @11:02PM (#11637935)
            One, a vague sense of security, that if a file gets corrupted, I can at least make an attempt at manual repair.

            The problem is that sense of security is very misplaced. CVS doesn't do any integrity checking. So you can easily have corruption problems and not know it until it is way too late. And if you add a binary that you haven't configured CVS for, well, he's dead, Jim. A scrambled text file isn't going to be any more recoverable than a scrambled binary.

            You might not like binary formats. But I don't see how you can avoid them if you are really going to handle binary data well. Otherwise you are ducking the issue.

            As far as using grep on a repository, yeah, I have done that too. It's ok if you have small projects. But for larger projects that is not a useful benefit. My current employer has an 11GB SourceUnsafe Repo that has to be a disaster in the making. And of course a $0 budget to move it to something else.

            Subversion isn't the cureall either. It's got some bad design in it that has got me holding back from recommending it. What I want is stuff like keywork expansion in Unicode. Merge tracking. etc.

            But at least it isn't a one man project like darcs. That would never fly for any sane corporation.

    • While Sean Quinlan and Sean Dorward were at Bell Labs the developed a block level file system Venti [bell-labs.com].

      Multiple saves of indentical blocks of data are aggregated in the file system such that there is no replication of the actual bytes on the disk, a look up system is employed.

      It is currently only available for plan9, though ports are in progress through the plan9ports project.

  • CVS Admin's be afraid ... very afriad. (Score:5, Interesting)

    by JPyObjC Dude ( 772176 ) on Thursday February 10, 2005 @06:45PM (#11635867)
    Just install Subversion, configuration and maintenance is a breeze. Which makes me happy because I have to use it and administer it (or not in the case of svn:)

    I love it so much, I am actually considering installing svn on my families computer so they can keep track of their most beloved digital documents as well.

    JsD

    • love it so much, I am actually considering installing svn on my families computer so they can keep track of their most beloved digital documents as well.

      If you're using Windows, look into TortoiseSVN [tigris.org], a Subversion shell extension for Windows. The neat thing is that you it doesn't even need a server if you file access to the repository is available (and possibly in other cases as well). This means it's the only program needed.

      As for myself, I actually use it for school homework in addition to my program

    • Re:CVS Admin's be afraid ... very afriad. (Score:5, Interesting)

      by tootlemonde ( 579170 ) on Thursday February 10, 2005 @07:42PM (#11636381)

      configuration and maintenance is a breeze.

      No discussion of Subversion is complete without a considering the relative merits of the two types of the repository storage system, Berkeley DB and FSFS.

      The Subversion book at red-bean.com has an informed discussion [red-bean.com] in Chapter 5.

      It appears that FSFS, which is basically the regular file system like CVS uses, is better in every way. The books says, "In theory, it promises a lower barrier to entry for new administrators and is less susceptible to problems." New administrators should take note because diagnosing and repairing problems with the Berkeley DB and Managing Disk Space [red-bean.com] is a whole other level of skill compared to administering CVS.

      Unless you are going to administer a huge project, in which case you should NOT be a new administrator, the Berkeley DB offers nothing but potential headaches.

    • Except, most importantly, imoprting a large CVS repository is most certainly NOT a breeze. And by large, I mean decades old, having gone originally from RCS into CVS.

      I have a zero chance in convincing my coworkers to switch to svn if we cannot preserve CVS history. Period.

      I've been trying for months to get a test import into svn, and still doesn't work yet. That that it takes a few days to import doesn't make it any easier - by the time, if it doesn't bomb out, it's done I've totally forgotten about it

  • getting permission to switch (Score:3, Funny)

    by SecretSqrl ( 849892 ) on Thursday February 10, 2005 @06:51PM (#11635921)
    Yes, um, sir, we would like to switch to a new version control system. No, it's not because of a problem with SourceSafe. Actually we stopped using SourceSafe several years ago. Yes, sorry we didn't inform you. Yes, we realize that cvs is not sold by Microsoft. Yes we would like to switch now. The new tool? It's another open source tool. Actually, it's called "Subversion".

  • Will SourceForge move to Subversion? (Score:4, Interesting)

    by Necroman ( 61604 ) on Thursday February 10, 2005 @07:01PM (#11635989)
    I wonder if SourceForge will ever move from CVS over to subversion. Maybe they could setup a temp program to allow people choose which way they use. The benefits subversion brings to OSS soruce control is really amazing.

    But it is hard to say how well subversion would handle the load. I'm guessing sf.net has done a lot of tweaking to get CVS to handle the number of projects they currently have, and moving everyone over... or just supporting both, is greater than the effort they want to put in.

    Maybe some day...
    • From the Nov 2004 sitewide update email: "For year six [2005], we have a lot of exciting things planned, including UI updates, enhanced tools, new tools, and Subversion support (version control). It will be an exciting year. We can't wait to show you."

  • Speed compared to Perforce? (Score:4, Interesting)

    by Rikardon ( 116190 ) on Thursday February 10, 2005 @07:09PM (#11636065)
    I've been using Perforce for awhile for a personal project (their "trial version" is a perpetual 2-user free-as-in-beer license) and I have to admit, I'm hooked on the speed. CVS on the LAN at work is an order of magnitude SLOWER for edit/commit operations than Perforce on a 512K upstream DSL connection.

    I've thought about moving to Subversion just so it would be cheaper if I ever had to scale my "personal project" up past two people. But honestly, I think Perforce is well worth the US$750/seat for the sheer speed it offers.

    Anybody have any idea how SVN compares?

    • Re:Speed compared to Perforce? (Score:5, Informative)

      by Anonymous Coward on Thursday February 10, 2005 @07:31PM (#11636289)
      Perforce is undeniably better than SVN.

      It has the ability to collect changes for grouped check-in against an issue. And it has the excellent, albeit somewhat clunky GUI. I loved using Perforce and I recommended it.

      However, after trying SVN, I would have to say that Perforce is not $750 per seat better than SVN. SVN has most of the functionality I looked originally to Perforce to get (mostly the atomic commits) and it is slowly but surely maturing.
      The GUIs are coming along and even the ANT and Eclipse plugins. And eventually SVN will have a more fully implemented WebDAV interface (Perforce does not).

      I feel bad that now that SVN is getting up to speed that Perforce is going to lose out. However, this is something that is happenning across the entire Developer tools market. Everything in the developer tools market space will eventually go Open Source. (most already are)

      Perforce had their run and now they will need to branch out or make a new version of themselves by adding on significant new features. :-)

      Or otherwise they will disappear from the market. If so, they will be missed.
      • I think it might depend on how big of a deal speed is. We used SourceSafe and CVS for awhile, then tried Subversion and found it unreasonably slow. Since it was impacting our ability to produce, we moved to Perforce and haven't looked back. Perforce is, as advertised, very fast!
    • SVN over http is noticably slower than svn+ssh through svnserve in my experience. The "svn book" seems to lean towards http, since (IIANM) it was there first, but svnserve really is a simpler choice. (Useradd and you're set.)

      I've actually never had an svn repository local to me. (I used perforce locally for 3 years.) I suspect svn+ssh is within a factor of 2 or 3 of perforce..l. certainly fast enough for anyone used to cvs.

  • Windows users (Score:4, Informative)

    by Vicegrip ( 82853 ) on Thursday February 10, 2005 @07:18PM (#11636145) Journal
    Subversion isn't the only choice for people looking for relief from SourceUnsafe. CVSNT is an evolved and mature CVS that you should look at too.
    http://www.cvsnt.com/cvspro/ for the server
    and http://www.wincvs.org/ for a gui client

    Mergepoints in cvsnt are very cool and wincvs is a powerful client. Since cvsnt runs on Windows and many unixes, you also have your choice of platform as well.

    cvsnt is a project that has been around over five years (at my reckoning) and has a good following. Plus you can get commercial support for it from March... what more can you ask for from Free software?

  • Subversion? (Score:5, Funny)

    by the_mushroom_king ( 708305 ) on Thursday February 10, 2005 @07:29PM (#11636267)

    I perfer to use intimidation:

    "Touch my code and I will beat you with silly with a rolled copy of the original spec docs."

    Seems to work for me.

    -- TMK

  • With SVN people about, could someone answer... (Score:5, Informative)

    by HopeOS ( 74340 ) on Thursday February 10, 2005 @07:47PM (#11636434)
    Since SVN people are about, could some answer these two questions. How's the branch switching code looking nowadays and what's the status of read-only files in the repository?

    We tested Subversion in November against our working CVS system. It was fun, and we were all really happy with it until...

    When switching between two branches, a file that was moved caused the switch to fail. The local sandbox was broken to the extent that nothing short of re-rechecking out the repository would fix it. All subsequent commits, updates, or attempts to switch back would not work.

    The second thing that bit us really bad was that we have applications that set source code controlled files read-only. This is intentional and necessary; if they are not read-only, the files will be changed automatically when certain tests are run which is something we do not want. Despite this, there are times when those files need to be updated. SVN crashed and burned trying to checkout changes over read-only files. All the research reading mailing list indicated that the prevailing thought at the time was that read-only meant read-only from SVN.

    That's not how it works in CVS at all where we currently use watches and locks to get this functionality. Read-only is an attribute of the file. When some checks out the file, it must be read-only when it arrives in their sandbox. The file and the sandbox is managed by source control so aside from user permissions, the last word on whether a file can be modified is that of the sandbox manager, not the filesystem. In short, if CVS or SVN need to write over a read-only file they should be able to do it so long as the file is read-only when the job is done.

    With the read-only detail and the sandbox corruption issues open, we had no choice but to return to CVS. I am seriously looking forward to what Subversion has to offer in the future though.

    Hope
    • Try Meta-CVS! The robustness of the switching operations will astound you (back and forth between revisions, branch to branch, etc). The sandbox rearranges itself, adding, deleting and moving files, without skipping a beat.

      Local changes of the directory structure are merged against the repository delta. Fix them with a text editor, re-update, and all is well.

      There is no bug database for Meta-CVS. I do web searches for it from time to time and find out about people who are happy with it, and don't bother w
  • Has anyone considered the case where both CVS and SVN need to be supported in parallel?

    The biggest problem in changing source control is the fact you must block all dev work while the transition happens. If your software moves fast enough there might never be a window of opportunity to lock the archive, move the code and open the new archive.

    What would make any transition easier is somehow maintianing both. Knowing the basics of how both CVS and SVN work and only giving in a few minutes of thought (beca
    • One of the problem with ALL source control systems is the lack of portable change sets.

      I would love to be able to duplicate a project and then import their changesets into mine keeping it synced no matter what source control they are using. This would save bandwidth because I only need changes not the whole repository.

      To my knowledge there is NO standard for change sets and if there are it certainly is not actively being used.
  • So, does the Eclipse support still suck? Since the last time I looked, there at least seems to be a 100% Java SVN interface which replaces the hell that was JNI, but it doesn't seem to support all features...

    Jon.
    • It is coming along quite nicely... recently basic synchronize features were introduced, and the JavaSVN layer improves on a rapid pace (using it to avoid JavaHL). The installation thanks to a new update site by Alex Kiatev of the JavaSVN Layer is a breeze now, just point eclipse to it and watch getting it installed. But yes... the plugin has bugs, but there is only a handful of maintainers and getting everything to work correctly is a huge task (the devs definitely need a helping hand to get the rest of th

  • Great tool (Score:3, Informative)

    by KalvinB ( 205500 ) on Thursday February 10, 2005 @08:45PM (#11636940) Homepage
    I introduced the company I work for to Subversion. They now use it will all new projects. All prior existing projects still use CVS. I also created a full featured (including per project, directory level permissions with inheritence capabilities) web-based client in PHP that is tied into dotProject. Most web based interfaces to SVN that I found back when I started the project failed to consider that some people need restricted access.

    Most people just use Tortoise though. The web-interface is nice for browsing repositories and downloading single files but when you need more stuff done, then Tortoise is ideal.

    • It sat stagnant for so long I thought for sure it was a goner. Good to see it's back in action. Is the project seeking developers? There are a lot of user interface issues that could use some work in my opinion. Maybe we can contribute?

  • One switcher's experience... (Score:4, Informative)

    by nonmaskable ( 452595 ) on Thursday February 10, 2005 @08:54PM (#11637022)
    About two years ago, I switched a large project from CVS (three years of revision history) to Subversion.

    We were able to migrate it all easily. We have developers using both WinXP and Linux. The Eclipse client was kind of broken at first, but recent versions have been acceptable. I've been able to forget all the workarounds and weird issues that caused us headaches with CVS.

    Overall a very good experience - I would say Subversion doesn't add anything groundbreaking to revision control, but rather is CVS done really really well.

  • Binary file corruption???? (Score:2, Interesting)

    by Anonymous Coward
    The one thing that has me mystified is how svn seems to be corrupting my binary files.

    I do a

    svn add *

    and it recognizes that a particular file (a CAD file) is binary, but when I commit, I see that the file size has increased and now my CAD software can't read the file!

    What is svn adding to binary files? Surely not those properties you set with svn propset etc?

Slashdot Top Deals

A morsel of genuine history is a thing so rare as to be always valuable. -- Thomas Jefferson

Close