Pragmatic Version Control Using Subversion

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

Comments

gnu arch

[Anonymous Coward]

CVS ? SVN ?

Gnu Arch !

--
let the flame begin ;)

Re:gnu arch

[ikewillis]

I'll switch to Arch as soon as it supports something like TortoiseSVN on Windows, which provides shell-integrated access to Subversion repositories.

Re:gnu arch

[gullevek]

GNU arch, like in Thomas Loard Arch, TLA? That one where you need commands in the length of 200 words just to do something.
Seriously, I tried it out and it is nothing but a showstopper, I played around 2 days getting to nowhere, then I tried subversion, after one hour I could work with it.
subversion is just the best at the moment. Very easy to work with and very easy to learn.

Re:gnu arch

[Digital11]

TortoiseSVN is genius... I just started at a company last month who didn't have any organized form of SCM, with a couple developers using VSS on their own. Luckily several of us got forced on to a project which required intensive edit-merge-continue style SCM, so I was able to convince everyone to give SVN a try. After a day of using Tortoise they couldn't believe they suffered through VSS. Everyone involved in Tortoise & SVN deserves a hearty pat on the back.

Re:gnu arch

[Anonymous Coward]

You think that's bad? The company I work for uses VSS on purpose. I'm weaning them onto Subversion now, but it's not made any easier by the total lack of decent tools to migrate a VSS database to SVN. (VCP had never, ever, worked for me. P4->CVS, VSS->CVS, VSS->SVN, CVS->SVN..none of them)

Re:gnu arch

[mgoss]

darcs is based on arch (TLA). darcs incorperates the good stuff from arch as well as being very easy to use without those crazy commands or naming conventions, etc. from arch. Out of cvs, subversion, arch, and darcs, I found darcs to be the best.

Re:gnu arch

[gullevek]

I remember that darcs didn't have a dedicated server. That, and the fact that I already understdood and used subversion at that point, made me stay with subversion.

yawn

[Anonymous Coward]

of course, none of these claims of pragmatism stand up to the scientific method.

all of this inane speculation and wanking is why CS has become a self-parodying soft science.

Re:yawn

[Rakshasa Taisab]

It's a introduction to SVN, not a masters thesis. What's next, introductionary books to accounting shows how lacking math is in rigor?

Re:yawn

[nkh]

Subversion is just a f***ing tool, you don't need to read Knuth or Einstein on a daily basis to understand the value brought by such a program. You do apply all those algorithms and write programs so you need a place to store the source code!

Re:yawn

[LourensV]

Well, assuming that you're declaring computer science superior over the pragmatic approach, I've started wondering about that recently.

Let me start off by saying that I'm firmly in the scientific camp, intending to start a PhD in CS this (northern) summer. It seems that an awful lot of popular things in IT are despised by computer scientists. Linux, as a monolithic kernel, is a famous example, as is C++, and I recently saw something about Perl being evil as well.

Now, these scientists have good reasons to call these things ugly, but people still use them. That means that either people are stupid, or the computer scientists are missing something. I think that it's mostly the latter.

In my software engineering course I was taught that the first and foremost thing you do in a project is gather requirements. It seems to me that computer scientists need to get out and ask people who work in IT what they actually expect from their kernels, languages, and development systems. Then they can try and create theories of how it all works or should work to fulfill those wishes, and use those theories to improve those real-world systems.

The alternative, sitting in your ivory tower inventing things that you think are pretty and everyone else thinks are useless, doesn't seem to be working too well.

Re:yawn

[zootm]

That means that either people are stupid, or the computer scientists are missing something. I think that it's mostly the latter.

No. I'd say neither. Sure, new programming languages are technically better, but firstly people don't want to have to take time to learn new systems, and secondly there is a wealth of tools and familiarity in the older languages. They're still used for these reasons. Computer scientists aren't missing anything (at least in my experience, although technically programming languages tend to err closer to software engineering disciplines), as such. Many languages are based around the practical desires and requirements of software engineers - they just tend to be too new to be of much use, or people are just unfamiliar with them.

And never underestimate the presence of old-school programmers who are too stubborn to learn anything but C(++), basing their justification on largely unfounded "efficiency" concerns.

Re:yawn

[badmammajamma]

I'm no computer scientist, but I do agree with them that C++ is awful. It's one of the worst languages I've ever seen. I know people who use C++ every day and they will tell you it's ugly too. However, there is always more things at work than the sophistication of a language. Just about any Smalltalk programmer will tell you Java is ugly and a poor implentation of an OO language. Compared to Smalltalk, they are right. Too bad the sheer cost of Smalltalk doomed it to obscurity.

Perl is ugly too but you have to appreciate it's brutal efficiency. Never before could you do so much with so little code.

Re:yawn

[yerfatma]

I don't think it's the only tool under discussion right now.

Re:yawn

[thpr]

Interesting, but I think that's an unfair bashing of the computer scientists. Let me state that my background is both computer architecture (the hardware side) and business.

It's interesting to note that while many things are stated by computer scientsts as evil, they are also practical. There are reasons why these languages are 'efficient' in a business sense: Linux is a widely used and widely known free *nix kernel. C++ leverages the existing C knowledge base; Perl is wonderful when you're trying to analyze ad-hoc log files. Personally, I haven't learned Python or Ruby, because the amount of time I spend hacking perl (maybe 10-15 hours a year) isn't enough to ever justify learning a programming language to replace it. [note I'm not a programmer; thus don't rely on programming knowledge to hold a job; thus my self-education time is better spent elsewhere; otherwise this might be a useful broadening of my horizons]

What you have to realize is that something won't be (rapidly) adopted unless it is significantly better than a previous product (or has a near-zero learning curve). For example, one of the members of the IEEE that sits on some of the Ethernet standards committees mentioned to me that one of the reasons Ethernet jumps by magnitudes of 10X is to ensure the next generation provides significant benefit over the previous one (of course, there are other reasons, too).

The point is, you can find a significant number of languages in use, but few that have been displaced. Those that were widely adopted (Fortran, Cobol, C, Perl, Java) all have specialties (scientific, business, fast/portable, efficient scripting, the web) that significantly differentiate them from previous languages. The dynamics of Python and Ruby is actually an interesting case study of where Perl is being very slowly knocked out of some of its domains by a similar, less "ugly" language (or such is my perception [both Perl being knocked out and the others being less 'ugly']). However, that transition is, I would argue, a bit glacial.

Also, to say that computer science (and studying algorithms) has very little effect is not all that accurate. Developments in rendering 2D and 3D systems, graph theory, and countless other areas are the result of those individuals. Even my understanding of how to organize code to ensure my OO code is a directed acyclic graph is a result of those "CS" folks and having that knowledge filter down. It doesn't necessarily affect the languages, but it changes how we use them. More recently, we have seen discussion of aspects, though (personally) I still haven't figured those out [I actually think it's because I work in problem domains where aspects are not efficient].

In addition, continually pointing out the weaknesses of the existing systems helps those that will design the next set of systems avoid the same mistakes. Even though that advocate may appear to be in an 'ivory tower' and ignoring what is going on in the 'real world', if a few architects listen and learn (and apply to the next generation of systems), then the computer scientist has served a purpose.

One other note. In respect to: "It seems to me that computer scientists need to get out and ask people who work in IT what they actually expect from their kernels, languages, and development systems.", try it sometime. Many times, people have NO IDEA what they are looking for. That's the whole basis of prototyping - to get something in front of the person and get feedback. Many other times, you will get completely contradictory answers. Detailed-oriented people will want a revision control system, code tags, and everything javadoc'ed. Others will be hacking out code that hopefully self-documents, but only has a comment to identify the license and copyright of the code. The challenge when dealing with people is that you have wildly different learning mechanisms, personality types (e.g. Myers-Briggs), brain operation (e.g. Hermann), and Communication Styles (e.g. DiSC). These differences lead to d

Re:yawn

[downbad]

Most CS topics are essentially mathematics, which is as hard of a science you can get.

Other CS topics are dependent on physical devices with complex emergent behavior (computer systems and their constituent parts) and thus don't admit axiomatic proof; but are still "hard" in that repeatable controlled experiments can be conducted to generate solid empirical evidence.

However, many parts of "Computer Science" are dependent on economics and human behavior. It is at this junction that emotions are thrown into the mix and religion ensues.

"Hard" sciences do not have dependencies on soft sciences; the results of physics research do not depend on psychology or economics. Given this, I consider CS to be a soft science.

Re:yawn

[Col Bat Guano]

"In my software engineering course I was taught that the first and foremost thing you do in a project is gather requirements."

Well of course the first thing you should do it start coding :-)

Gathering requirements/building a business model are the first things you should do. It just that you shouldn't always do all of it straight away. Sometimes a little bit of exploratory programming is what's needed to understand the problem.

But don't tar all academics with the same brush please!

Re:yawn

[Aardpig]

Most CS topics are essentially mathematics, which is as hard of a science you can get.

Except that Mathematics isn't a science. Science is about describing the natural world, which mathematics has only a tangential link to.

Re:yawn

[Anonymous Coward]

you have to appreciate it's brutal efficiency

"its".

Re:yawn

[Anonymous Coward]

they can try and create theories

"try to create".

Re:yawn

[Anonymous Coward]

Funny; a lot of this so-called pragmatic stuff was invented by computer scientists. Linus certainly got his degree. C and C++ were invented by researchers, as was UNIX itself. The Internet. Even the Web, I suppose.

Computer scientists don't necessarily hate practical stuff; it's just that the stuff which is actually of interest to CS folks happens to be 10 in the future. What's cutting edge today has already been written about in papers 10 years ago, but it takes time for the state of the art to catch up with theory. And inevitably, a lot of good and bad ideas will both be proposed in the course of research. That's just life.

Re:yawn

[indifferent children]

And never underestimate the presence of old-school programmers who are too stubborn to learn anything but C(++), basing their justification on largely unfounded "efficiency" concerns.

And don't underestimate the amount of work that goes into maintaining old systems. When your project has over a million lines of C++ code in your version control system, how much Java do you really want to introduce? How will you tie this new Java code into your project, CORBA? And do you really want to end up with a project that contains 40 different flavor-of-the-month languages? That kind of miasma is why the DoD tried to standardize on Ada.

Re:yawn

[zootm]

Yeah, I meant to mention existing systems there too (I'm actually very surprised I didn't). The bottom line is that people and software existed before more-modern programming languages did, and that is a fairly natural reason that not everyone immediately uses them.

Re:yawn

[jrootham]

That is a reflection of the origins of CS and its practitioners. CS is almost entirely a mathematical science rather than a natural science.

Math depends on proof. Natural science depends on evidence. There is a large and mostly unconscious gap between them.

This also spills into the slow acceptance of evidence based project management, since the basic training of a lot of computer types is math rather than science they don't have evidence based reflexes.

Re:yawn

[smittyoneeach]

That means that either people are stupid, or the computer scientists are missing something. I think that it's mostly the latter.

I think the OR in your proposition points to the fact that two of the dimensions involved in the mad world of IT are the tactical world of business, and the strategic world of academia.
I submit that business and academia are communicating on different frequencies, really do make sense, and only start to get confusing when you tune into exactly one frequency and start viewing the resulting signal out of context.
It's Friday, and I'm posting something thougtful to /. Hmmm. Must be time to eject.

Pragmatic Masters??

[Anonymous Coward]

HA! Their kung-fu is no match for mine!

That's nice..

[Anonymous Coward]

.. but how does this book stack up to others on the same subject?

Re:what? WHAT?

[Timesprout]

Excellent, we are about to start a ditch digging project shortly and a pragmatic guide to ditch digging would be invaluable.

Another subversion book

[halosfan]

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/

Re:Another subversion book

[halosfan]

Clicky: Version Control with Subversion

Lots of folks are switching over...

[tcopeland]

...Subversion support is one of the most requested features on RubyForge.

Is there a StatCVS-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...

Re:Lots of folks are switching over...

[rmohr02]

I have never used StatCVS, but I believe if you open up a log dialog in TortoiseSVN you can select "Statistics". I've only used it once, but it gave results similar the the sample report the StatCVS site refers to. It's not formatted as nicely, but it's worth looking at.

Re:Lots of folks are switching over...

[corz]

There's MPY SVN Stats.

Re:Lots of folks are switching over...

[tcopeland]

Very cool, thanks!

I need to practice reading...

[4ginandtonics]

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...

Re:I need to practice reading...

[Genda]

Yeah I did the same thing...

I can see the advertising campaign by M$ now...

"Only Subversives use SUBVERSION!!!!"

Genda

Re:I need to practice reading...

[vsprintf]

"Only Subversives use SUBVERSION!!!!"

Since management already considers me somewhat subversive, I like the idea of using this just because of the name. Now to get some details . . .

Is it better than the Subversion Book?

[dmh20002]

The Subversion Book 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.

Re:Is it better than the Subversion Book?

[Anonymous Coward]

the subversion book might be a good introduction, but when working with subversion in bigger projects you will find that you have a lot of questions that unfortunatelly you will not get answer in that book.

Note to moderators

[Anonymous Coward]

Parent is offtopic.

Their reputation

[spludge]

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?

Re:Their reputation

[PragDave]

Seems to work... :)

Re:Their reputation

[mgm]

Yh im typng wth tre fngers nw.

Anyone considering switching to SVN...

[greppling]

...might find this thread 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.

Re:Anyone considering switching to SVN...

[cduffy]

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.

That's something of a disappointment -- I'd hoped to see them on Arch. Given the magnitude of their project and the number of 3rd parties interested in maintaining their own branches, I'd think that distributed revision control support would be as valuable a feature for them as it's proved to be for Linus.

Re:Anyone considering switching to SVN...

[Anonymous Coward]

You can use SVK to mirror a SVN repository: http://svk.elixus.org/

Re:Anyone considering switching to SVN...

[gullevek]

If you read a bit in the gcc ML about the switch one of their main points is, that they want a central server, something which arch does not give them.

Re:Anyone considering switching to SVN...

[cduffy]

That's what the PQM (the Patch Queue Manager -- effectively a "maintainer-bot" responsible for pulling, testing and applying patches on demand) is for.

Re:Anyone considering switching to SVN...

[jilles]

I migrated some of our legacy repositories to svn yesterday. It's rediculously easy. I didn't encounter any problems with newlines like the mono guys.

Svn blame and svn log are very powerful tools and yes they take a while to complete. For each release I do a svn log -v -rbeginrev:HEAD > changelog. I usually edit some of the languahe inside changelog but this gives a pretty decent overview of changes. The -v option lets you see which files changed in a particular commit.

Of course we've been using svn for our main products for about a year now. Once you're used to svn, cvs feels like a huge step back.

BTW getting started with svn is rediculously easy too. Here's what you need to do to set up a server:
- install svn.
- make sure you have a working ssh server.
- make sure svnserve is in the path.
- svnadmin create somerepository

That's it. You can use the svn+ssh type url now to do stuff on your newly created repository.

Re:Anyone considering switching to SVN...

[cduffy]

I'm aware of SVK (and it's much more than a mirroring tool -- referring to distributed revision control that way does the concept a severe injustice). Best I can tell, however, it has neither the userbase nor the general maturity to make it suitable for a project on the scale of gcc.

Re:Anyone considering switching to SVN...

[Anonymous Coward]

Whereas arch has the userbase and the general maturity to make it suitable for GCC?? SCNR.

Re:Anyone considering switching to SVN...

[cduffy]

Whereas arch has the userbase and the general maturity to make it suitable for GCC?

As opposed to any other Free distributed revision control tool? Absolutely. Arch's major outstanding issue (IMHO) is mature win32 support, and that's targeted as a fix for tla2.

Indeed, in a number of other respects, I'd argue that Arch is more stable than SVN. It certainly doesn't have the same propensity for corrupting itself -- such being one of the advantages of using a write-only archive format.

Re:Anyone considering switching to SVN...

[kaiidth]

Just for you (to celebrate your switch!), I'm going to give you the URL of a rant that a university lecturer of my acquaintance wrote a while ago about subversion, along with a quote or two.

Subversion is a version control system. Like CVS. It is designed as a successor to CVS, improving the functionality, speed, without losing the elegance and simplicity of CVS. Subversion has indeed the features that CVS is lacking, you can move files, and you can easily tag releases. It is also blindingly fast, and it has used the sample approach that CVS uses. So far so good.

The reason I am no longer touching it with a bargepole is the implementation. svn has been implemented using Berkeley databases. Presumably because they are fast and efficient. All releases o all files are stored in a single database. This is fine, efficient, and everything else, until your database gets corrupted. At that stage you are up to your chin in shit.

The database is easily corrupted.

The rest of the rant is here. I know he convinced me right back into CVS :(
Probably it would have made more sense merely to be convinced into making timely backups... but hey.

Re:Anyone considering switching to SVN...

[jilles]

Berkely db is just one of the (two) backends. At least they're using a db, cvs is just ascii files on disk. That means they're even easier to corrupt (which is probably why cvs fans consider this to be an important feature). And yes you can mess with them when that happens but do you really want that?

We haven't had any reliability problems so far and our repositories have been online for more than 1.5 years now. Of course we make nightly backups (which is also very easy with svn, even incrementally).

The nice thing about svn is that you can dump to plain ascii on the fly (i.e. without shutting down anything). The dump files are very portable, incremental and also very suitable for backup (and actually the output of cvs2svn). A dump file is like a chronological ordering of all commits. You can do incremental dumps every hour if you wish, hardly any performance penalty. Maybe backup the db binaries nightly/weekly and there's no risk. When bad stuff happens, just svnadmin load the dump files.

BTW. we've never had any need for backups so far. Maybe your friend has a grudge against berkely db and maybe for good reasons but I've heard no bad stories about subversion messing up repositories so far. It certainly works beautifully for us and we have dozens of commits per day.

why is this better than cvs?

[Anonymous Coward]

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?

[dingbatdr]

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.

Re:why is this better than cvs?

[Anonymous Coward]

Thanks man for answering despite somebody modding me as a troll.

Does sound like an improvement on the little PITA points of CVS w/o having to relearn a perfectly good worldview.

And whenver I'd read about "atomic commits" I'd always thought "I've never had CVS die in the middle of commiting a file, so why the hell would I care about that?". Never realized people meant atomic at the "whole-checkin" level!

Is it better than Perforce?

[Anonymous Coward]

What is this subversion thingy and is it better than Perforce?
I'm looking for something similar to Perforce but free. Any ideas?

Re:Is it better than Perforce?

[mgm]

When I was initially getting involved with Subversion I found that most of its features reminded me a lot of Perforce. The repository-wide revision numbers, database backend, and general "feel" of Subversion is very similar to Perforce.

I think Perforce is better than Subversion if you're doing a lot of branching -- the merge point tracking that Perforce performs is really well implemented and saves you from a lot of manual tracking. Overall though if you're looking for a free alternative to Perforce I'd highly recommend Subversion

Re:Is it better than Perforce?

[badmammajamma]

Microsoft uses Perforce for their version control system. (Yes, even they don't use pos VSS.)

Although, I've heard that Perforce is a locking version control system. If that's true, it's something you should definitely take into account since locking vcs is a whole different (and crappier imo) ballgame.

Re:Is it better than Perforce?

[chiph]

If you've got the money and the need for a SCM tool like Perforce, you should also be looking at Borland Star Team (comes with defect tracking utility) and Clearcase.

If costs like $1000 per seat scare you off, and/or you don't have a need for planet-wide team development, then maybe Subversion would be suitable.

Chip H.

Re:Is it better than Perforce?

[yerfatma]

Oh happy Christ, Borland must release two tools under the same name, because you and I can't be using the same StarTeam. All you need to know is that StarTeam assigns files to the following status codes: "Current", "Out of Date", "Not in View" and "Unknown". How the hell does it not know? We spent like $50,000 on it (by "we," I thankfully don't mean me) and that's about the only thing making it difficult to convert us over to svn. I'm hoping to use Trac as a Trojan Horse here.

Re:Is it better than Perforce?

[Bryan Ischo]

Perforce is not a locking version control system; there is a step that you have to take before you can edit a file, 'p4 edit foo.cpp', that makes the file editable. Perforce checks out all files as read-only and p4 edit makes it writeable. But multiple developers can p4 edit the same file at the same time. I really have no idea what the point of p4 edit is except that it allows Perforce to know who all is editing a file and it can warn you if you p4 edit a file that someone else has opened. But it's just a warning, there is nothing preventing two people from p4 editing the same file at the same time.

I use perforce at work and subversion at home. I prefer subversion, I just like the "feel" of it better, but Perforce definitely has better branch merge support. I can't compare the speed between the two very well, the size and scope of the projects at work are not really comparable with the piddly projects that I use subversion for at home.

Re:Is it better than Perforce?

[Anonymous Coward]

That's funny; one of the first things I learned in business school was the importance of understanding sunk costs and not letting those costs enter into decision-making for new projects. Of course, this is IT...organizations routinely spend millions on horrible PSFT implementations with no results for years and they just throw up their hands and keep spending. Good luck to you in your efforts to save your company money the right way: understanding a current business need and acting accordingly instead of fretting over sunk costs and letting the company lose money in the interim.

Re:Is it better than Perforce?

[carrowood]

I used StarTeam at a former job and I must say, I'd be happier going to the dentist every day. I think that was before Borland owned it. My impression: overpriced and kludgy...

Re:Is it better than Perforce?

[smithmc]

I really have no idea what the point of p4 edit is except that it allows Perforce to know who all is editing a file and it can warn you if you p4 edit a file that someone else has opened. But it's just a warning, there is nothing preventing two people from p4 editing the same file at the same time.

Locking is available in P4, but optional.

Re:Is it better than Perforce?

[MemoryDragon]

Well... clearcase is no option in most projects... fact it clearcase is an almost untamable beast.

sounds interesting...

[n4ru70 f4n]

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?

Re:sounds interesting...

[proub]

What if you want more in-depth reading on tagging and other simple necessities that you cant go without knowing about well?

If it really is similar to their CVS book, it will cover that stuff quite nicely. I've used CVS for years in a variety of contexts, and that book still taught me a lot -- either features I wasn't using, or better, saner ways of using the ones I already knew. Particulary where branching and tagging are involved.

here's a better version control system:

[Anonymous Coward]

http://www.cvshome.org

Not Available Yet (Astroturf?)

[Cysgod]

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.

Re:Not Available Yet (Astroturf?)

[Cysgod]

I should note, that he did have a disclaimer on his own site's review of the book that he got a free review copy. Why this wasn't in the slashdot review... well, only slashdot's editors can answer that.

I'm still curious why he gets lots of free advance copies of books. (Where do I sign up...)

Re:Not Available Yet (Astroturf?)

[Anonymous Coward]

The book is available directly from the publisher, (www.pragmaticbookshelf.com) from O'Reilly, and a few other spots. B&N and Amazon are just slow on the draw.

Re:Not Available Yet (Astroturf?)

[jarich]

It's shipping now. http://www.toolshed.com/blog/News/svn_shipping.htm l,v

Re:Not Available Yet (Astroturf?)

[jarich]

I've done book reviews for /. and been contacted by publishers (other than the PragProg guys) who have offered to send me books if I would review them.

Re:Not Available Yet (Astroturf?)

[Anonymous Coward]

Firstly I did get an advance review copy. I enjoyed it enough to read the whole thing through on the first night.

Secondly it is out now, they moved it forward from Feb 14th.

If the book was rubbish I'd have said so (I know you have no reason to trust me on that but I've written some unflattering reviews of free books in the past), I've reviewed the rest of their series (each of which I've purchased) for my local Perl Mongers group and was very impressed so I asked for a review copy.

HTH
Dean Wilson

Re:Not Available Yet (Astroturf?)

[BigJimSlade]

Pre-orders shipped last Friday. I had my download link for the PDF that afternoon, and recieved my dead tree copy in the mail today. Plenty of time to read the material and write a quick review.

Don't be so paranoid.

Re:Not Available Yet (Astroturf?)

[V. Mole]

Reviewers receiving advance copies is standard practice. If you're going to be suspicious of that, you pretty much have to ignore reviewers in general.

Re:Not Available Yet (Astroturf?)

[Stmpjmpr]

I'm looking at my copy now, so it's available. ;)

Re:Not Available Yet (Astroturf?)

[Just Some Guy]

I reviewed a book on Slashdot a while back. I got an email one day from the book's publisher telling me that I'd been selected to receive an advance copy, and it showed up in the mail a couple of days later.

That was the entire history of my contact with the publisher. They didn't offer it as a bribe, or hint that they'd like a good review (or even any review at all). They never contacted me afterward to comment either way.

Honestly, this happens a lot more than you'd expect. It also doesn't necessarily mean that there's any relationship whatsoever between the reviewer and the publisher.

Benefits of Subversion's revisioning system?

[the-matt-mobile]

I've read the free subversion PDF, and I was interested enough to install it for use at home on my Windows box. The PDF does a great job of describing subversion's revisioning system, which is based on tracking directory revisions rather than file versions. That's great and all, but I've never read a valid explanation as to why this is a better way to do things than the way VSS and CVS work. VSS and I think CVS also use file revisions which makes it super easy to look at one file's revision history. 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? Does the Pragmatic Programmer book delve into source control theory at all?

Re:Benefits of Subversion's revisioning system?

[danpat]

Did you miss:

http://svnbook.red-bean.com/en/1.1/ch02.html

In addition to that, read:

http://www.accurev.com/accurev/info/timesafe.htm

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?

[aardvarkjoe]

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.

Re:Benefits of Subversion's revisioning system?

[Alioth]

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 something like the 'svn log' command.

Re:Benefits of Subversion's revisioning system?

[avalys]

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.

Re:Benefits of Subversion's revisioning system?

[mgm]

The book does discuss the differences between the per-file (CVS) and repository-wide (Subversion) numbering schemes, although the conclusion is that the differences don't matter that much.

Basically if you're using version numbers on files to figure out "how much has changed recently" you should be probably looking at the log/history instead. Even if a file in CVS has only been incremented one revision point, the change could actually have altered every line in the file. The numbers don't really give you concrete information about how much "churn" is going on in the code.

I'd recommend using decent log messages and keeping commits small and specific over using revision numbers to figure out what's changed.

Re:Benefits of Subversion's revisioning system?

[the-matt-mobile]

It's an elegant system if you are tracking files that have some relationship to one another like compiling a C program, but what about things like SQL scripts. I manage a project where we track changes to our SQL statements via Visual Source Safe. Each SQL script can change without affecting anything else, but if we were to use Subversion, revision numbers would become meaningles.

Don't get me wrong - free as in $$$ is good and I use Subversion at home because it works on Windows and I'm too cheap to pay for anything, but the revisioning model doesn't makes sense unless you're managing a compilable program. Or, perhaps I'm still missing something.

Re:Benefits of Subversion's revisioning system?

[mgm]

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 trees, in order to remember that kind of thing. So you might have a bunch of files in your repository corresponding to your released software, in directory

/myproject/tags/release-1.0/sql/...

In your example a single revision number is useful because a change to SQL code usually involves a change to other code. For example, if you rename a column you'll need to change application code that accesses that column. If you commit all these changes in one go, logically grouping them together, it makes things a lot clearer when reviewing changes later on. Once you have changes grouped together as a unit you can move them around, apply them to other branches, or even back them out if they don't work.

Grouping changes like this together probably also implies some stuff like having database people sit with programmers and pair on their changes, but I'll avoid going off the deep-end and evangelising XP too much... ;-)

Re:Benefits of Subversion's revisioning system?

[Dan Ost]

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?

[Anonymous Coward]

I buy the benefits of the atomic changesets, directory revisioning, bidirectional diffs for updates and commits, that a global revision number is as good as a discrete revision, etc...

For me the stumbling block is usually reporting. Since the link is external to the code tree, how do you tell that a bug was introduced in build 1.0.0100 and that all customers with builds after 1.0.0100 are impacted.

I don't think it should be impossible to tell this with Subversion, but in part it depends on the meaning that users apply to the repository hierarchy and the directory conventions that they use.

You can try to argue, write some reporting software yourself based on your own conventions, but when MS VSS is bundled in with the costs of your development environment, it is hard to get sponsorship for a move to Subversion without good reporting functionality built in.

Re:Benefits of Subversion's revisioning system?

[John Bokma]

Have a look at TortoiseSVN if you are running Windows, it works in explorer as a shell extension. http://tortoisesvn.tigris.org/ Also, note that if you use TextPad as an editor it's a piece of cake to add Tools to TextPad that do things like Add, Commit etc.

Re:Benefits of Subversion's revisioning system?

[mrbnsn]

If you use ViewCVS, it's every bit as easy to check a file's revision history in an SVN repository as in a CVS repository. Furthermore, the revision number on a file doesn't get incremented unless it's changed, copied or moved. With CVS, you have no visibility at all into copies or moves.

Re:Benefits of Subversion's revisioning system?

[MemoryDragon]

You can forget file revisions (which svn does also) if you do major refactoring, or renaming, which happens quite a lot on non C/C++ languages.

But SVN is not the ultimate tool, there are many problems which have to be tackled.

Id dumps myriads of files onto your hd, which is not a problem for smaller stuff, but give it a project with thousands of files and watch the harddisk doing itself not a favor, thanks to the client side stuff it has to do.

It basically dumps every file onto your hd twice

SVN still has bugs, it is solid, but for instance I got the message CRC check failed more than once and then refusing a checkin on me.

No distributed version control, there is SVK but that is not finished yet. The biggest problem are the myriads of files it generates on the client, you really can watch the performance go own once you hit a critical point on your filesystem (which happens quite often in a java project) watch the disk doing thrashing for five minutes on the fastest machine you can get before doing a simple submit on a handful of files. Depending on your filesystem and fragmentation grade worse or better.

Re:Benefits of Subversion's revisioning system?

[Fjornir]

It basically dumps every file onto your hd twice

Wild. You call that a problem, but where I work we tend to think of it as a feature. In fact it's one of the bigger reasons we're dropping CVS in favor of SVN. With four facilities scattered around the world, plus the engineers onsite with customers, this has big gains in terms of what needs to be slung across the WAN when you want to revert something.

Sample excepts

[darkpurpleblob]

Sample excerpts from the book are available in PDF format from the book website. You can also download the full Using Tags and Branches chapter 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>

Re:Sample excepts

[hereticmessiah]

You, sir, are a double karma whore, and should be disgusted with yourself for giving two, yes two, pieces of useful information in your post.

Conflicts and Merging vs Locking

[dmh20002]

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

[mmurphy000]

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

Re:Conflicts and Merging vs Locking

[borzwazie]

I use pvcs and I'm looking into switching - were you using the promotion model, and if so, what did you replace it with?

Re:Conflicts and Merging vs Locking

[simonecaldana]

> I use pvcs and I'm looking into switching

Is this slashdot or a BDSM forum?

PS: try latex.

Re:Conflicts and Merging vs Locking

[Anonymous Coward]

Exactly what I was wondering about. Please mod parent up. Its what is preventing me from
advicing a move to subversion at this point.

Re:Conflicts and Merging vs Locking

[decairn]

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, update to latest checked-in code prior to doing your own check-in, establish a process to run a unit test case suite for the project; these must pass 100% before checking in the new code. This is good practice anyways regardless of this situation.

Also, encourage check in early and often to minimize changes between source tree updates.

Have an automated build and/or a unit test runner, email a VIP list and the culprit that broke the build. This finds the issues early if people aren't actually using the process described above, which will help to enforce it.

I've used a process like this on teams with 20 people running for a year or more with 3-5 branches on the go at once. The problems are minimal. The hardest part is running 2 very active branches together for an extended duration; the merge is hell but all source systems will have this as an issue.

Re:Conflicts and Merging vs Locking

[Jerf]

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... static typing, the "need" for various excessively top-down methodologies, the need to compile all the way down to machine code or suffer Performance Doom. (The last one is one we are quite a ways into shaking ourselves free of; I mention it so more people can see the "other side" of a thing like this.)

Of course, this only applies to doom-and-gloom-based arguments. I bold that because there can be benefits in some situations for some of this class of issue, but the benefit won't be the avoidance of doom and gloom. You can make positive arguments about the benefits that, say, static typing might bring under some situations and this counterargument doesn't apply to that point.

The best thing about this though isn't so much using it to convince others, it's using it to convince yourself and advance your understanding. If there are a lot of people who are doing something you just know is wrong and certain to lead them to doom, it is still worth a try, especially if these people seem otherwise smart. You may still be right (PHP is still a disaster of a language, for instance), but you may prove wrong and learn something. It's happened to me several times. (Yes, the conclusion that I tried PHP is correct, and it's one of the few times I can think of that following this algorithm led me to reinforce my preconceptions on the issue, rather than discard or modify them.)

To get back to the topic at hand, abundant community experience indicates that source control needs to be easy, or nobody will bother with it. The price of rare conflict resolution (which is admittedly a cost, though there is some benefit in the explicit existance of a conflict that wouldn't necessarily be revealed in a lock-based system) is more than repaid by the way people actually use the source control system, instead of ignoring it as much as possible and sometimes actively fighting it. (Every time you fight or work around the system, you're not preventing problems, you're creating them.)

Re:Conflicts and Merging vs Locking

[motomike]

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 Developer B's foo.c. In fact, subversion is remarkably adept at handling those merges ... but that's only relevant after you've won them over from their file locking tools.

Re:Conflicts and Merging vs Locking

[rmohr02]

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--it explains things well.

Also, assuming you use Windows desktops, use TortoiseSVN.

Re:Conflicts and Merging vs Locking

[synx]

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 only real solution is frequent and aggressive testing.

I think this split between 'we must control changes' to 'don't slow me down' is the difference between what I call 'old school developers' and newer-style developers. Agile development style vs 'software engineering' which has been proven to not work anymore.

Re:Conflicts and Merging vs Locking

[jschrod]

I did quite some CM introduction at customers, both CVS/SVN style (version-oriented, central server) and CC/arch style (change-set-oriented, distributed).

In both cases, it boils down to:

• If two people have conflicts, it is either an emergency bug fix, and they need to communicate about it anyhow. Then the bug fixer got ahead and the module maintainer has to incorporate his bug.
• Or it's that really both want to change the module at the same place. Then it's an organizational problem -- distribution and allocation of work should avoid this to happen. If it doesn't, one has other -- more basic -- problem than conflicts in the code.

Re:Conflicts and Merging vs Locking

[master_p]

Having to rely on a human to select the proper bits of code in case of a conflict is not a good idea, for the following reasons:

a) the person assigned to it must be able to quickly tell what is the correct bit of code.

b) the programmer asssigned to it temporarily stops doing what he/she was supposed to be doing.

c) if the person that can quickly resolves the conflicts is on vacation or ill, the project halts.

On the other hand, the PVCS model starts slower, but the developers quickly learn how to coordinate themselves, and then there is no delay at all.

And having the edited file locked helps in enforcing good design: each developer is assigned a specific part of the project, and each part is a different file.

All the above come from my experience from the last 8 years as a developer. I've seen projects really messed up with CVS, because people quickly resolved the conflicts by selecting the wrong ones, whereas I never had any problem with PVCS; the few times that I truly needed access to a file at the same time with another developer and had to wait, I had other tasks to do...and the locking/unlocking part does not let one run wild over the source code.

Re:Conflicts and Merging vs Locking

[archeopterix]

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?

Make sure you know how to handle conflicts on non-mergeable files. You don't live in the ideal world - sometimes you just have to deal with unmergeable files in the repository - icon bitmaps, proprietary screwed-up format of your (pointy haired bosses') favorite database modeler, some strange resource files etc.

That's why file locking is the #1 feature on the SVN to-do list. Meanwhile, where I work we just use the "tell others before modifying" locking scheme on those unfortunate files.

Subversion better than CVS?

[aurumaeus]

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?

Re:Subversion better than CVS?

[Homology]

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?

[wmshub]

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. :-)

Re:Subversion better than CVS?

[Kaz Kylheku]

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. Apparently, the CVSNT guys picked up on it.

What's left? Fast tagging. Ah well ... :)

Re:Subversion better than CVS?

[V. Mole]

I don't mind the having to do seperate commits and updates; if it's truly an independent project, you *should* have to think about what you're doing.

The real problem with svn:externals is that they don't branch and tag "properly"; that is, the external still refers to the original part of the tree, and will get any changes made to it. You can work around this, and because the definition of "properly" is heavily dependent on intent, I doubt there really is a general solution. But it's a pain.

Thus, I've gone with the choice mentioned by the other poster: just copy the library into the project, and treat it just like a vendor drop of 3rd party code. That way, you don't have to worry about breaking other projects, or other projects breaking you, and tags and branches work as expected.

darcs

[mgoss]

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.

Re:darcs

[DrSkwid]

While Sean Quinlan and Sean Dorward were at Bell Labs the developed a block level file system Venti.

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.

Re:darcs

[Anonymous Coward]

While Sean Quinlan and Sean Dorward were at Bell Labs the developed a block level file system Venti.

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.

That's cool, but one imagines that for reasons of simplicity and efficiency, it only compares whole blocks on block boundaries. If so, how would this help a system that stores copies of binary files if the binary files' contents are change by shifting things some number of bytes that is not a multiple of the filesystem block size? (This probably happens 99% of the time.)

And if Venti does recognize redundant data that doesn't fall on the same block boundary between files, how does it pull that off without being slow and complex? :-)

Re:darcs

[DrSkwid]

rtfp

Re:darcs

[Anonymous Coward]

Agree. I used cvs, then switched to svn untill I lost a complete repository (under version 1.1, using berkeley db). Now I am using darcs. No complaints till now, except it is a little slow (darcs whats -ls takes a while). I like all its interactivity: you can decide what to commit (record), what to push, pull, etc. I have almost no binaries in the repository, so the way darcs handles them is not a problem for me.

CVS Admin's be afraid ... very afriad.

[JPyObjC Dude]

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

Re:CVS Admin's be afraid ... very afriad.

[omicronish]

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, 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 programming projects. I setup a dedicated server for my repository in this case so that I could access and synchronize my work at school. It works wonderfully, especially when used with plain text documents or source.

Re:CVS Admin's be afraid ... very afriad.

[Anonymous Coward]

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.

I don't know why more people don't do this. Why is it that only programmers are able to track documents well? This same concept makes perfect sense for Joe User. And with tools like TortoiseSVN, I think almost anyone can learn to use it. They might not be merging branches and tagging releases, but they can at least log changes, retrieve old versions when necessary, and keep files in sync between machines.

Re:CVS Admin's be afraid ... very afriad.

[tootlemonde]

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 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 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.

Re:CVS Admin's be afraid ... very afriad.

[Sax Maniac]

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.

Re:CVS Admin's be afraid ... very afriad.

[Anonymous Coward]

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.

How? Using cvs2svn I hope?

Re:CVS Admin's be afraid ... very afriad.

[vsprintf]

How? Using cvs2svn I hope?

Okay, there seems to be a tool for converting from CVS to svn, but after skimming the documentation, there are still loads of questions. Can anyone familiar with Subversion help out?

If I convert from CVS to Subversion will it retain all the tags, commit comments, etc.? Can I retrieve an old version of the source code (pre-Subversion)?

Is there anything in Subversion like the commitinfo stuff in CVS that allows you to call other scripts/programs and do verifications before a commit is completed?

Is there anything like CVSweb for Subversion? If not, forget about moving. If there is, will it display the pre-Subversion information (from a previous CVS repository) in the repository?

Re:CVS Admin's be afraid ... very afriad.

[mrbnsn]

"If I convert from CVS to Subversion will it retain all the tags, commit comments, etc.? Can I retrieve an old version of the source code (pre-Subversion)?"

Yes. You have to understand that the SVN model of "everything is a directory" requires a different way of thinking from the CVS "everything is a file with attributes" model, but cvs2svn does an excellent job of preserving your entire project history.

Also, it is not mentioned anywhere that I've seen in any documentation, but the output of cvs2svn is a very tractable ascii-formatted sequence of svn repository transaction instructions. This makes it very simple and straighforward to do an intermediate processing step (with sed, perl, whatever) to ensure you get an SVN repository structure that meets your own requirements rather than the default layout that cvs2svn uses.

"Is there anything in Subversion like the commitinfo stuff in CVS that allows you to call other scripts/programs and do verifications before a commit is completed?"

SVN supports pre-commit, commit, and post-commit script hooks. The design is simple (due in no small part to the fact that the SVN model is much more simple) and the documentation is clear.

"Is there anything like CVSweb for Subversion? If not, forget about moving. If there is, will it display the pre-Subversion information (from a previous CVS repository) in the repository?"

ViewCVS has excellent SVN support right out of the box (although I strongly recommend using the much-improved development version out of CVS, rather than the rather stale stable release). Because cvs2svn copies over your CVS-era project history into the new SVN repository, all that information is viewable through ViewCVS. Because of fundamental differences in the underlying model (directory-oriented vs. file-oriented), there are a few minor rough edges that are probably unavoidable in a unified CVS/SVN repository browser, but overall, the ViewCVS user experience with an SVN repository is quite satisfactory.

Not mentioned in your requirements, but a show-stopper for many projects is Eclipse support. I'm happy to report that Subclipse works great once you get around the fiddly javahl library installation issue. Just don't forget to read the documentation if you are checking out a Java project from SVN for the first time.

Once you get your brain around the differences in the underlying model, SVN is so clearly superior you'll never look back.

Re:CVS Admin's be afraid ... very afriad.

[Anonymous Coward]

Except... it's kinda slow. I tried an FSFS repository, and it was significantly slower on most operations I used daily compared to BDB. I suppose the eventual SQL backend would be what you'd like, but I suppose purists would argue the SQL backend stores data in binary, too. Heck, not even in the file system.

Re:CVS Admin's be afraid ... very afriad.

[vsprintf]

SVN supports pre-commit, commit, and post-commit script hooks. The design is simple (due in no small part to the fact that the SVN model is much more simple) and the documentation is clear.

I spent another hour with the documentation today and still didn't see that part, but I will spend some more time with it tomorrow. Many thanks for your help. Sorry to bother you further, but do you know of a publicly available SVN repository using ViewCVS that I could look at?

Re:CVS Admin's be afraid ... very afriad.

[mrbnsn]

From the SVN book: Hook Scripts

Sorry, I don't know of any public SVN repository using ViewCVS. However, installation and configuration of ViewCVS to use SVN is really very easy; if you're curious, I encourage you to set it up and play with it a bit.

i second that.

[Anonymous Coward]

darcs has been a real plasure to use. very easy, intuitive, etc.

Seems to be available to me.

[_archangel]

Just because bn.com does not have does not mean that it is not available. It looks like you can purchase and view at least the PDF version right now. It seems that the dead tree version is shipping immediately.

http://www.pragmaticprogrammer.com/titles/svn/in de x.html

getting permission to switch

[SecretSqrl]

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".

Re:getting permission to switch

[buckhead_buddy]

Actually, the name "subversion" was a real concern for me at a former jingoistic, anti-terrorist, amazingly technically ignorant employer of mine.

I found that I had to refer to it as svn all the time... at least until my overseer started calling it subversion on his own. Like Al Gore under the impression that he invented the internet, my task master thinks he was responsible for the subversive nickname.

Second that emotion

[A nonymous Coward]

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 like I had to wear a suit and tie again after having not worn one for 30 years.

I don't see darcs as being a big change from CVS and Subversion in how to use it, not in any way that requires a mind warp to use. Different, sure, but still just version control, only done better.

Re:Second that emotion

[the eric conspiracy]

Subversion now has a file system version as well, so you aren't stuck with Bezerkly db if you don't like it.

Will SourceForge move to Subversion?

[Necroman]

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...

Re:Will SourceForge move to Subversion?

[i41]

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."

Re:Will SourceForge move to Subversion?

[Anonymous Coward]

Umm, it's not like everything is being handled by one CVS or Subversion server. Subversion is certainly more scalable than CVS out of the box, due to replacing many O(n) operations with O(1) operations, but really, you'll only have a problem with scalability if you can't subdivide projects into suitably small repositories, and probably not even then.

Other justification...

[SuperKendall]

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.

Re:Other justification...

[Sax Maniac]

Clearcase does it quite well, they call it unreserved checkouts. It's just that (last time I used ccase) it's not the default like it should be.

To the OP: you may have to quit. I failed to convince my coworkers, so I left. Now we do parallel development the Right way.

Re:Other justification...

[CrocketAndTubbs]

Jeez, I haven't used clearcase in 6 years, but when I did, I didn't even know you could lock a file. It was all unreserved. All merges were done through the gui tool. I didn't set it up. We had a guy and a bunch of support scripts that abstracted much of the actual minutia. I moved to bitkeeper about 4 years ago and never moved back. Its expensive, but easy to set up and does everything you could want. At least everything I want.

Re:Other justification...

[WolfWithoutAClause]

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.

It's nearly always a good idea to code review all changes that are being merged back into a stream. That can solve nearly all merge problems.

And if somebody makes a change before you merge back, code inspect the merge with that too. The final merge shouldn't actually involve changing any code on the sidestream.

Re:Other justification...

[jrumney]

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.

Re:Other justification...

[orasio]

I'm no genius (well, I am, but don't tell anybody) and I installed CVS, following some cookbook, for my team in a couple of hours. The next day, by noon, everybody was using it (update/commit) with Eclipse, and next week we were all able to resolve merges seamlessly (damn struts-config.xml, should have divided the son-of-bitch much earlier).

It was a team of 5 developers, not huge, but enough. None of us had ever actually used version control systems. Previous to that, we were just 3 people, edited the same tree, shared with samba, and used actual physical tokens representing access to conflicting resources (it's clumsy, but it kinda works when you are close to other people).

Re:Other justification...

[WolfWithoutAClause]

IMO- The biggest problem with clearcase is that it's overcomplicated. You simply shouldn't have to jump through that many hoops to do the common stuff.

Speed compared to Perforce?

[Rikardon]

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?

[Anonymous Coward]

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.

Re:Speed compared to Perforce?

[nsxdavid]

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!

Re:Speed compared to Perforce?

[MemoryDragon]

Regarding slow lines SVN definitely is better than CVS because it only transmits the diffs, however expect the performance to go down once you have to deal with lots of small files. (Too much overhead on the client side which has to parse a handful of files per local file) But I rather doubt you will in any circumstance reach the performance of Perforce, and that is a good thing. (Would hate to see them go belly up, good company, with a good product)

Re:Speed compared to Perforce?

[emoon]

I wouldn't say that Perforce is going to lose out.

Perforce easily handles repositories with hundreds of thousands of files.

Perforce is dead simple to setup and has a number of 'enterprise' type features (distributed repositories, caching proxy servers for satellite offices, ftp/http frontend, etc).

Perforce support is top-notch. Perforce has the best support team I've ever contacted.

You've gotta love a SCM that offers GUIs for Windows, OS X, Linux, Solaris, & FreeBSD: http://www.perforce.com/perforce/products/p4v.html .

Finally, in addition to the free 2-user version, Perforce offers free licenses to projects developed under a recognized open source license.

Good, free software is wonderful. But there's no shame in paying for a solid commercial product backed by a fantastic company.

Re:Speed compared to Perforce?

[jarich]

Was this all on the same hardware? I migrated a shop from Perforce to CVS and found CVS performance to be about the same.

I'm currently on a project that just migrated from CVS to Subversion and Subversion is ~much~ faster, however, they also did a hardware upgrade, so I can't compare the two.

Re:Speed compared to Perforce?

[nsxdavid]

I did not compare Subversion to CVS... but Subversion was very pokey when we worked with it. Moving to Perforce on the same hardware and topology was very fast. The bigger the project, the more Perforce really shines, IMHO.

My biggest wish is that the integration of these tools with VisualStudio were better. Not sure if Microsoft is going to address this in the next version or not, but it's very klunky. Especially if you want to branch....

-- David

Windows users

[Vicegrip]

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?

Re:Windows users

[Anonymous Coward]

It's still CVS, though..

I wouldn't consider that an option starting out today. Maybe archs or darchs or something, but not cvs.

Re:Windows users

[CrocketAndTubbs]

If u want cvs on windows, I recommend installing cygwin and add cvs as one of the packages. I just found it easier to get working. Plus you get all the gnu tools to boot.

Re:Windows users

[Anonymous Coward]

try tortoise-cvs (http://www.tortoisecvs.org/) too, its an excellent windows explorer shell plugin for cvs

Subversion?

[the_mushroom_king]

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

Re:Subversion?

[Anonymous Coward]

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

You get spec docs!!! You're so lucky! I have to resort to threats like:
"Touch my code, and I will beat you silly with vague, constantly changing notions of what the code may or may not look like in the near to mid term future".

It doesn't work nearly as well.

--
AC

Re:Subversion?

[andi75]

Mod parent up. We live in a world of constantly shifting requirements, and glorious "just give us something (preferably next week), we'll tell you when it's what we want" assignments.

Re:Subversion?

[Anonymous Coward]

In 1984, some newbie "system manager" on our VAX decided he would help me by going into my login directory and editing a bunch of FORTAN code, leaving comments taking me to task psychologically for the way I was doing things (I was a new-technology C programmer and those FORTRAN files were just interfaces to C modules back-in-the-day before DEC shipped its own C compiler for VMS). That bastard set me back 6 months and, to make matters worse, erased an array of dishwasher-sized disk drives by changing my "virtual I/O" to "logical I/O" (same API, just a different constant), thinking it would be "faster"!!! (Virtual I/O goes from start of FILE to end of FILE, Logical I/O goes from start of VOLUME to end of VOLUME --ouch!) Bottom line, that guy now works at Walmart so that he can have medical benefits because he never managed to build up much of a retirement after being canned so many times.

All of this has happened before and it will all happen again, especially to the inexperienced (but very talented) guys in India --outsource away, dumb fucks!

NIce but where is WinSubversion

[Portal1]

I tried Subversion but it lacks a cool graphical interface like WINCVS, for the rest it seems to be nice
Untill a client GUI is available I will not start looking at it again.

greets

Re:NIce but where is WinSubversion

[scottbell]

Try Tortoise SVN. It's a pretty, integrated windows subversion client.

Re:NIce but where is WinSubversion

[mgm]

TortoiseSVN is an excellent front-end, and there are a bunch of IDE plugins for integration with things like Eclipse, IntelliJ, Visual Studio...

http://tortoisesvn.tigris.org/

Re:NIce but where is WinSubversion

[Anonymous Coward]

Have you looked at TortoiseSVN?

http://tortoisesvn.tigris.org/

It integrates right into the Windows file manager.

Re:NIce but where is WinSubversion

[Anonymous Coward]

Aye, the WinCVS gui blows TortoiseCVS out of the water.

But I switched anyway.. SVN makes it worth the price and I'm sure a WinSVN port is gonna show up soon.

Re:NIce but where is WinSubversion

[bcuriel]

There are a number of GUIs, we use TortoiseSVN here, which works pretty well and integrates directly into the windows explorer. Takes some getting used to, but I find this much more effective than having a standalone program.

Re:NIce but where is WinSubversion

[Wizarth]

RapidSVN, right there on the Subversion main website.

RapidSVN

[Anonymous Coward]

Besides Tortoise, you should also check out RapidSVN. I tried them both and I like the RapidSVN Gui better. Both of them are open source.

With SVN people about, could someone answer...

[HopeOS]

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

Re:With SVN people about, could someone answer...

[Anonymous Coward]

Not sure about your branch problem, but google for "asvn" for the file permissions issue. Someone on the dev list is working on a patch to get the file-permissions/owner info to stick with the file.

Re:With SVN people about, could someone answer...

[Kaz Kylheku]

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 writing to me.

The very rare time someone has an issue, we take it up in e-mail and usually get it resolved.

PrintFu Link

[Anonymous Coward]

Get a printed version for 9.80
http://www.printfu.org/?mcAction=pdfURL&pdfURL=htt p://svnbook.red-bean.com/en/1.0/svn-book.pdf&pppem ail=jdrake@gmail.com

Right, but ...

[A nonymous Coward]

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 you'd do it with Subversion.

I also had a minor scare with moving subversion (with a Berkeley DB repository) from a Pentium to an Opteron system. The repository size, using dump and restore as recommended by the subversion docs, grew by (IIRC) a factor of around ten. I do not understand this. Merely going to a longer word size would have made no difference to a CVS or darcs repository, being text, and I could think of no reason to more than double for a binary repository. That is what prompted me to look for alternatives, and how I found darcs, and I won't go back to either CVS or Subversion.

Re:Right, but ...

[Anonymous Coward]

I also had a minor scare with moving subversion (with a Berkeley DB repository) from a Pentium to an Opteron system. The repository size, using dump and restore as recommended by the subversion docs, grew by (IIRC) a factor of around ten. I do not understand this.

It's hard to say without details of what software you're using (Solaris? BSD? Linux?), but a likely explanation is that your dump/restore programs don't preserve sparse files.

As you may or may not, know, on most Unix filesystems, you can create a new file, write() a byte to the beginning, lseek() forward (say) 1 megabyte, and then write() another byte. When you do this, the filesystem will only allocate disk blocks for the parts of the file that have already been written. In effect, it leaves NULL pointers in the i-nodes for the intervening blocks. If you try to read back the blocks, the system will give you zeros.

These are called sparse files, and Berkeley DB uses them to simplify or speed up its implementation or something along those lines. (Among other things, sparse files can be used to create a big address space to store a hash table, and then blocks which have all empty buckets do not take up disk space.) Unfortunately, many backup and restore programs are not "sparse file aware", so they just read the zeros and then when restoring the file create a file with vast regions of zeros in them that actually use disk space.

You can tell a sparse file, by the way, because the output of du filename usually (always?) will not agree with ls -l filename.

Anyway, while I understand the code-reuse motivation for using Berkeley DB, I do agree it adds complication. It probably is the case that what you saw is a known behavior of Berkeley DB and nothing has gone wrong at all, but this extra complication does cause stress and doubt, and in some situations the confusion could cause someone to back out of a planned server upgrade out of fear of corrupting their repository, causing delays in a project or something.

Re:Right, but ...

[the eric conspiracy]

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.

Has Anyone Considered Parallel CVS/SVN?

[EXTomar]

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 (because work won't let me have the time to plan things) it seems almost possible with shell script-fu. The goal is of course that during a given transition time window you can do either a "cvs update" or a "svn update" and get the same code. At some later date you can turn off one archive and move forward. Of course there is the quirk about exactly how revision history is maintained in this situation but something is always lost in the transition unless you use or build tools to carry the data with you.

Books like this are great but I would rather seem some hardcore information on transition scenarios. Learning a new revision control system can be tough (although I don't think SVN is that daunting) but not as scary trying to switch revision control systems.

Does anyone comment on Subversion Stability

[Anonymous Coward]

I would like my company to switch to using subversion to take advantage of all of the features it offers, but my biggest question is stability. Though CVS may lack a lot of features, after upteen years it is very stable. I've heard subversion stores its revision info in a single file, and if that file becomes corrupted, you're SOL (note other SCM systems have this problem, like Perforce). Does anyone have more info on this?

another interesting one

[jbellis]

PuTTY converts to svn:
http://www.chiark.greenend.org.uk/~sgtatham/ svn.ht ml

(much) smaller project than mono, obviously; interesting all the same.

Re:another interesting one

[professorfalcon]

Wow. That's the kind of setup that is a royal pain to maintain.

No it is not

[SuperKendall]

So tell me, when you do an unreserved checkout how do you easily merge current changes for that file from the view into your working copy? How do you do that in batch for all files you are working on?

The if you can do that, how do you specify a real merging tool that will not screw up the file or get lost if someone alters whitespace?

Re:No it is not

[Sax Maniac]

It's been a very long time. I seem to remember writing a short script that invoked findmerge and clearmerge to do it all. Definitely not a simple as CVS.

As for the screwing up on whitespace, no idea. But CVS does sometimes, too. :-)

And no, I don't prefer clearcase... that thing was like a tank without an engine: you'd just have a bunch of people inside turning the wheels.

Eclipse support?

[JKR]

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.

Re:Eclipse support?

[MemoryDragon]

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 the functions in and improve performance, which is a drag once the project gets bigger... *IBM anyone?*

Offtopic.

[lakerdonald]

You notice that only about 40% of the replies are actually about anything remotely related to Subversion, let alone Version Control Systems in general? Just an observation. But back to the topic, I don't know why there aren't more books about subversion out there already.

Great tool

[KalvinB]

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.

I'll check out findmerge...

[SuperKendall]

Actually my preferred means of working now is not even unreserved checkout, but simple hijacking - which comes closest to working the way you can with CVS.

I'll check out findmerge and see if I can get a script using that to approximate an auto-merge into my existing file.

Seriously though, if anyone knows how to tell clearcase to ignore whitespace for diffs, that would be fantastic. We've had a few people look at that but no luck.

I could see somewhat why companies would use a VC system that supported directory changes, but now that Subversion seems to be pretty well ready for primetime hopefully the age of clunky VC systems is over.

Re:I'll check out findmerge...

[Sax Maniac]

I don't know anything that should ignore whitespaces during merging. When you merge, it has to pick one or the other, and that whitespace might be in the middle of something where it counts (a string). You don't want to automatically pick up one or the other.

Ignoring whitepsace during analysis is altogether different. I seem to remember just using whatever diff tool (diff -w or whatever) I had available, since you could just diff while feeding version-extended pathnames.

These days I use tkdiff to do a graphical diff with TkDiff for analysis, that can ignore whitespace.

Re:I'll check out findmerge...

[JQuick]

Seriously though, if anyone knows how to tell clearcase to ignore whitespace for diffs, that would be fantastic. We've had a few people look at that but no luck.


I sympathize with your plight, but treating whitespace as significant has a number of benefits.

For instance consider Python, whose control flow structure is defined by whitespace alone. White space which is mere ornamentation in some contexts is critical in others. For rigor and consistency the only sound approach is to consider each byte significant.

One switcher's experience...

[nonmaskable]

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.

Re:One switcher's experience...

[Dom2]

Hmmm, I've had lots of problems with the Eclipse client. So much so that I've given up on it for a moment. It would just hang on checkout.

I suppose I should give it another go at some point. It'd be a better match than CVS in Eclipse for sure.

-Dom

Re:One switcher's experience...

[nonmaskable]

It works for the very basic checkout - commit cycle. It's integrated with eclipse refactoring, although we had one mysterious problem that could have been either subclipse or user error.

Beyond those simple operations, I think there are lots of missing features.

Re:SVN sucks

[BlueTooth]

Right, so have you read about arch?

Binary file corruption????

[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?

Re:Binary file corruption????

[Quill_28]

Don't you have to tell svn(or is it cvs?) that it is a binary file?

I know cvs had a crappy algorithm for binary files but svn was suppossed to fix that.

Yes In tried TurtoiseSVN

[Portal1]

Sadly enough Turtoise SVN does give the user some control, but for advanced tasks it realy is not up to the task.
If you have to merge or repair some fuckups from others (done alot, i can say i am a hardened CVS manager) it is a must to have a visual tree of all the changes and diff whatever version you want.
Sadly enough that is not supported with turtoise.

I hope it will come soon though

Greets

Re:Yes In tried TurtoiseSVN

[Anonymous Coward]

Do you see anybody else misspelling "tortoise?" No. Then why do you do it?

speed: how you install svn makes a difference

[jbellis]

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.

Yes, during analysis...

[SuperKendall]

I did mean during analysis. However whatever ClearCase uses to diff does not seem to understand the concept of ignoring whitespace changes. I too have many other diff tools that work properly, but they are a lot harder to work against the vob for checkin conflicts.

More information on side-streams...

[SuperKendall]

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 ClearCse sidestreams) a lot of bother when under CVS I can simply edit files and merge in all changes as they come. It literally is the least amount of work possible for the best workflow, and if the sidestream thing works like private branches then I fear the version tree would be a nightmare from daily merges into a private branch over time... I'll reserve judgement though until I get more details and try it out. If all you do is create a private branch once then I guess the overhead is not too bad... as long as the merging works well.

Re:More information on side-streams...

[WolfWithoutAClause]

However, I still find setting up a sidestream (private branch? Google had nothing on ClearCse sidestreams) a lot of bother when under CVS I can simply edit files and merge in all changes as they come.

Yes, private branch. It was a fair amount of bother, but for the highly disciplined software engineering I was involved with, the extra process wasn't significant- not when it could take 2 days to change 1-5 lines of code :-( We had scripts to automate it mostly; so it wasn't so bad.

It may very well be that CVS is a better fit for most people. I used clearcase on a *big*, cross-site (international) project (as in several hundred software engineers all hacking away simultaneously, millions of lines of code- *BIG* project, and there it worked very well, although it seemed somewhat overcomplex to use. I think we evaluated CVS, but elected not to go that way.

What about modules?

[Anonymous Coward]

Can anyone comment on svn support for cvs "modules"?

The use case I have in mind is that we have dozens of directories in our repository corresponding to different components. Some components are shared by several products. Individual products pull different sets of components together. In cvs, you just use "aliases" in the modules list for this. It's a more than minor bummer than cvs doesn't follow directories/components being added to or removed from a module, which is why I had hopes for svn and its meta-data abilities.

The closest thing I could find in the svn docs was "external" links, but since svn doesn't recurse into them, they're not nearly the same.

The last time I did some searching on the web and svn mailing lists, I noticed several others with a similar use case, and no interest from the svn developers (some negative vibes, in fact).

Use Darcs

[Anonymous Coward]

If you don't like SVN or Arch, try Darcs http://darcs.net . It reminds me of BitKeeper quite a bit, and literally makes CVS look like a joke.

Probably not a sparse file problem

[A nonymous Coward]

This was subversion's dump program on Slackware Linux, to a single dump file, then restored via subversion on a Gentoo Linux system. I doubt Berkely DB or subversion is writing sparse files anywhere in that process, especially since it wrote all the repository files that went into the dump too.

It may have been perfectly normal, but I didn't like it, and didn't want to find out the hard way that it had made a boo-boo.

Wow. dotProject is still alive!

[Mustang Matt]

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?

charge sets required

[oo_waratah]

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.

Re:Anyone here have the PDF?

[oo_waratah]

Go to the library and ask them to order the book in. In Australia this is a free service.

They actually can do this, I have used this to read an obscure book I could not get any other way.

Yes but it should be toggleable

[SuperKendall]

I agree for Python you'd be in a serious hurt if merges ignored whitespace!!

However for so many Java programmers on the earth with auto-indenting editors, life is hell when the merge cannot detect whitespace changes alone, and gives you a maddening number of conflicts for things that should have been simple.

Or even ignoring Java, take XMl files, which may be generated or again reformatted by editors. ClearCase is at its worst with XML files, I have seen it just give up a number of times, throw up the white flag and say the whole file is "different" even if you'd just added a four-line node and re-saved the file!!! Crazy stuff, and the main reason I have grown to loathe ClearCase. Plus it requires some serious know-how to admin properly, always a bad idea to require support people to know anything about what they are doing.

Fantastic series

[LarsWestergren]

Great to see a new version coming up. I was considering writing a review for Slashdot of this series. I like O'Reilly a lot, but to be honest they have nothing as good as this. If you are a Java programmer you should get all three.

Second book in series is best. It has a huge number of "best practices" I haven't found anywhere else - how fine grained tests should be, how to make sure you write all the important tests ("Right-B.I.C.E.P.") and so on.

So with this new book the series is now:
1: Version control with {CVS, Subversion}
2: Unit testing with {Junit, Nunit}
3. Pragmatic Project Automation - How to Build, Deploy, and Monitor Java Applications

Ok, I'll finish gushing now.

Not astroturf - User groups get review copies

[Anonymous Coward]

All user-groups like LUGs and Perl mongers get review copies.

I saw this review on the london perl monger list before it appeared here. We (the london perl mongers) have a good relationship with several publishers and include several Authors and many people who have had technical imput on books.

I know Dean personally and have worked with him. He isn't astroturfing, he has a full time job and still has time to get involved in local groups and contribute. Perhaps if cysgod was smart enough to use google this would become apparent immediately.

Well, it is actually a DBMS.

[master_p]

It's funny that almost everything like this kind of applications (version control systems, in this case) eventually boils down to a DBMS (and often an RDBMS). Here is a list of similarities:

-Directory versioning: directories are modules in their own right; i.e. tables with contents.

-atomic commits: transactions

-Versioned metadata: any data in a table

-Choice of network layers: database apps already work with server/client and web models.

-Efficient branching and tagging: copying tables and data and inserting new data.

-Hackability: database APIs are plentiful out there.

The above really says that it's time to throw away traditional filesystems and use database management systems. Traditional file systems do not justify their existence: they cover so minimum functionality these days...DBMSs is the proper way to manage information. Versioning systems simply fill in the void between traditional filesystems and DBMSs.

Re:Well, it is actually a DBMS.

[ebh]

it's time to throw away traditional filesystems and use database management systems

That's what ClearCase does. Although it does use regular files for its data containers, all metadata is stored in a database. MVFS is just a fancy view into that database. It wouldn't surprise me if at some point they brought the data containers into the database, too.

Sharing code

[SLOGEN]

We practically never use svn:externals, we just copy the library to share into a "deps" folder.

When we think we've done enough improvement for the library to make sensee to other lib-users, we merge the local changes into the shared location of the library.

If a new (well tested) "release" of the library emerges, we check if it's got the changes needed for the specific project that has a copy. now there are two scenarios:

1. all changes are included: just rm and recopy lib to deps-folder
2. not all changes are included: either stay with the version we've got or merge relevant changes into our local copy

This works REALLY well, allowing project to decide when changes to their dependencies are to their advantage.

--
Helge

CS & Pragmatic can easily coexist

[SLOGEN]

CS slowly expands the amount of tools in the pragmatic tool-box.

The goals of CS and pragmatics are different:

CS investigates boundries to computing: performance, resource use, ...

Pragmatism is about just looking for "enough" to complete a specific task

If you have a task/project with a very specific goal, you'd better be pragmatic, or you will delay delivery of the goal. If some CS (or related) thought up a great way to to this, like a compiler, algorithm, data-structure, language, ...
then that's GREAT, if not, then you better solve the problem with the absolutely least amount of effort

Subversion, CVS and arch are history

[nietsch]

history-tools, that is. But most people want more than an archive what stupid mistakes they have made over and over. Sometimes you want to restrict who can do what, by using specific roles in the project, So your youngest intern may be able to check out the code and develop a change to it, but he may not check that change directly into the baseline.
You als need to assure his change does not break other stuff, makes mistakes others have allready made.

In ohter words, you need aegis for that.
Have a look at it at here. You will like it if you are serious at software development for more that trivial programs.

Re:SLASHDOTTED... mirror, please

[Anonymous Coward]

we did our job

Wow!

[V. Mole]

I don't think I've ever heard anyone else refer to BitKeeper as expensive in relationship to ClearCase. Did you do something to piss Larry McAvoy off?

Re:what? WHAT?

[Anonymous Coward]

You trade in dug ditches? How do you effect the swap? Do you move the ditch from the new location and fill in the old?
You, sir, are as oxymoronic as a professional athlete.

Back on topic

[V. Mole]

Because there is a reasonably good book available for free online.

Pragmatic?

[Anonymous Coward]

If you're really pragmatic programmer, you do not use Subversion. You use either darcs or monotone or something like that, but not subversion, a system that does not distribute as well and does not have so good basis on theory of patches.

Maybe even arch.

Help!

[Fjornir]

How do I tell what date a branch was created on with cvs??

Good Idea

[retendo]

What a great comment! I'm a developer with 8 years in the industry and I came from a strict CS background (UMass Amherst). I've always felt that the background I recieved at UMass was a great help in the work field but usually didn't directly help me solve real world problems. So I suplimented some of the standard CS courses with the more applied engineering courses and internships to give me real world experience.

I think the comment above is a great approach to the "science" of software engineering. Seeing what people are really doing and using that as a focus for new theory and achedimic development should be a good way to lead achedimia in the right direction. I had to go "against the grain" in college to get the proper mix of theory and application. It's good to see others are looking along these lines.

--
Dan

I would love SourceForge to move to Subversion

[retendo]

We use Subversion here at my company and have had a great time with it. When we moved from CVS we had a few headaches but the documentation is so good that we had an easy time figuring it out. Now we have all of our projects in Subversion repositories. Life is good....

Then we loaded a project onto SourceForge. Back to CVS. I screwed up the initial import and had to remove a bunch of files. Do you know how this is done? By sending a request into SourceForge.

Already I miss Subversion.....

--
Dan

How to get svn+ssh to work with svnserve?

[Anonymous Coward]

I got svnserve working without ssh, but I had no luck doing it with svn+ssh. I read the relevant chapter in the Subversion manual, and tried it and it does not work.

Atomic Commits!

[lorcha]

My current project uses ClearCase and unreserved checkouts (basically, edit/conflict/merge because there is no exclusive locking). The most annoying thing with that is the lack of atomic commits.

With Subversion, your commit either succeeds or fails. And you have to have your repository up to date before it lets you commit. This is a good thing.

On my current project, I can't tell you how many times I've updated the code from clearcase, went to compile, and OOPS! Compile fails. I don't know if it's because somebody's commit half succeeded (I have had commits half succeed and then die off) or if I check out in the middle of someone's big commit. But it really irritates the hell out of me that the repository can so easily get into an inconsistent state.

I have never had svn do this to me because I never see somebody's half commit.

If you're happy

[lorcha]

If you're already happy, then for fuck's sake, why would you want to switch?

Does CVS meet your needs? Keep it!

Others have responded with the advantages of SVN over CVS. Personally, I prefer SVN. For me, it boils down to the following:

1. Atomic repository commits. I can't tell you how sick and tired I am of checking out in the middle of someone else's commit and having the code fail to compile.
2. Moving of files. That's right. svn mv will move your file for you and keep all the file's history. If you do a timestamp checkout when the file was its original filename, you'll get the original filename. If you do a checkout of the head, you'll get the new filename. It just works. You can move files and directories that way. Refactoring is a breeze.

But, seriously man, it depends on what your requirements are.