Slashdot Mirror

I wouldn't really fault Visual Studio for Source Safe's failings, it isn't a required component. Personally, I wouldn't touch Source Safe with a very long pole in any voluntary manner (only if I was required to). Considering it is the only system marked as a system to avoid over at the Better SCM Initiative and even Forrester won't consider it anymore in ranking SCM products, I'm surprised it is being considered for any kind of current solution.

There are some decent tools for Visual Studio to work with CVS and Subversion, among other version control systems, and they work out fairly well. At work, we are using Subversion for our VCS, with AnkhSVN to handle the management inside Visual Studio. Except for some issues with using AnkhSVN back when it was first getting started (and was rather buggy), we have been very happy and productive with the solution.

http://subversion.tigris.org/links.html

There's a good selection halfway down the page.

There are lots of clients to choose from at the tigris.org site. If you don't want or need a file browser plug-in/Explorer extension/IDE integration, there are a number of apps to choose from. Granted, TortoiseSVN and Subclipse track the Subversion releases more closely than the others. Personally I use a combination of TSVN with Kdiff3. I also use AnkhSVN in Visual Studio, just for the auto-add and file icons.

I suspect a lot of people really don't much like CVS, so I didn't really even expect anybody to argue that CVS was really anything but a legacy system. And while I've gotten a few people who argued that I shouldn't have been quite so impolite against SVN (and hey, that's fair -- I'm really not a very polite person!), I don't think anybody actually argued that SVN was 'good'.

SVN is, I think, a classic case of 'good enough'. It's what people are used to, and it's 'good enough' to be used fairly widely, but it's good enough in exactly the sense DOS and Windows were 'good enough'. Not great technology, just very widely available, and it works well enough for people and looks familiar enough that people use it. But very few people are 'proud' of it, or excited about it.

And here is the reaction from the subversion team. For those of you who don't want to RTFA, they basically say they agree, its not appropriate for something like Linux.

BTW, isn't this all old news? His original comment on subversion was dated from 05

Yep, cause this license ain't free enough and, besides, we don't want anything that is better than CVS.

You're a codin' machine Theo, but I wish you could learn to play well with others.

Ok, don't go for the gold right out of the box. Find a smaller/lesser know OSS project to work on.

Some projects are actively trying to get newbies involved. I've heard of GnomeLove (though I don't actually know much about it), and Subversion has a list of bite-sized tasks.

Subversion 1.5 will have automated merge tracking. The merge tracking feature is already available on the trunk, and will be released in (probably) a couple of months. This link has more information:

http://subversion.tigris.org/merge-tracking/index. html

With the addition of the merge tracking feature Subversion will be almost at parity (feature wise) with commercial products like P4.

Git may be a great SCM tool for some situations, but for commercial development which doesn't require a distributed architecture, IMO, SVN is preferable to Git.

Git needs to be supported on more platforms and have a better user interface to be accepted as widely as Subversion.

I must mention TortoiseSVN at this point, because until Git has a user interface like TortoiseSVN, it'll never be accepted by Windows devs. I'm not asking for trouble here (in other words, I'm not trolling Linux users), it's just that I looked at lots of alternatives for our (mainly Windows and UNIX-based) shop and nothing else came close. All of our devs use Windows, even if just to host a terminal program, and the ease of training folks on the use of TortoiseSVN was a big reason for our switch to Subversion.

http://tortoisesvn.tigris.org/

FWIW, I'm a UNIX/OS X/Linux guy myself.

Subversion 1.5 will have automated merge tracking. The merge tracking feature is already available on the trunk, and will be released in (probably) a couple of months. This link has more information:

http://subversion.tigris.org/merge-tracking/index. html

With the addition of the merge tracking feature Subversion will be almost at parity (feature wise) with commercial products like P4.

Git may be a great SCM tool for some situations, but for commercial development which doesn't require a distributed architecture, IMO, SVN is preferable to Git.

Git needs to be supported on more platforms and have a better user interface to be accepted as widely as Subversion.

I must mention TortoiseSVN at this point, because until Git has a user interface like TortoiseSVN, it'll never be accepted by Windows devs. I'm not asking for trouble here (in other words, I'm not trolling Linux users), it's just that I looked at lots of alternatives for our (mainly Windows and UNIX-based) shop and nothing else came close. All of our devs use Windows, even if just to host a terminal program, and the ease of training folks on the use of TortoiseSVN was a big reason for our switch to Subversion.

http://tortoisesvn.tigris.org/

FWIW, I'm a UNIX/OS X/Linux guy myself.

Found it. Here is the update to merging - they even ask for input, so hop to it pal!

http://subversion.tigris.org/merge-tracking/

That should be fixed in 1.5: http://subversion.tigris.org/merge-tracking/

http://subversion.tigris.org/faq.html#in-place-imp ort
Install Subversion, and use it on your config files.
Subversion: it's not just for projects anymore.

But with subversion, I just found it disgusting (and hard to manage) how it left all these invisible files all over my system

It only puts them in your working copy. Most development practices include the assumption that you wouldn't deploy your working copy simply by copying it directly. There are several models of how to generate something to be deployed. One of the most common ones is to have a script or build tool that operates on the working copy and generates something that can be deployed. That something could be a tarball, or it could be an RPM, or it could be a directory tree that can be used directly, or it could be a source distribution. Another common way to do it is to have a script that actually installs directly from the source tree onto a system. But it's really not very common to simply use the source tree (or a copy of it) directly.

and if I copied a directory, for example, there would be two copies linked to the same place in the repository

That would only happen if you copied the files directly instead of using svn copy as the documentation says to do. If you really want to use a GUI to do it, and you're on Windows, get TortoiseSVN and use that. There are probably other similar tools for other systems.

exactly .. and.. my biggest complaint is.. that i actually recommended subversion to everyone who asked because of his cool advantage over CVS - the versioning of directories ... how cool is that .. you can move a file and still have all the history of the file.. so .. no problem with refactoring a big project..

after all .. it's one of the biggest features.. see http://subversion.tigris.org/ "Subversion versions not only file contents and file existence, but also directories, copies, and renames."

well .. of course it all works great.. until you merge...

but as i said .. i'll keep using it for my smaller open source projects.. but i can't honestly recommend it to bigger projects for a company ..

Anyway, it's safe practice to check in the trunk modifications before you merge.

I think you missed his point... he'd committed all his changes. The problem is that if you merge a file or directory deletion in, where that file or directory had modifications committed, Subversion won't tell you about the conflict, but will delete the file or directory including the new modifications.

You wanted to delete it, so who cares, right?

Subversion represents renames as a copy & delete. So now, you rename a file or directory, and do the same dance as above, and the renamed file or directory does not have changes that were made on trunk under their previous names. So renaming a file can re-introduce a bug you already fixed.

No big deal, the devs will fix it soon, right? Wrong and wrong again.

That is the problem.

Anyway, it's safe practice to check in the trunk modifications before you merge.

I think you missed his point... he'd committed all his changes. The problem is that if you merge a file or directory deletion in, where that file or directory had modifications committed, Subversion won't tell you about the conflict, but will delete the file or directory including the new modifications.

You wanted to delete it, so who cares, right?

Subversion represents renames as a copy & delete. So now, you rename a file or directory, and do the same dance as above, and the renamed file or directory does not have changes that were made on trunk under their previous names. So renaming a file can re-introduce a bug you already fixed.

No big deal, the devs will fix it soon, right? Wrong and wrong again.

That is the problem.

for me performance is (currently) the least of my problems with subversion..
more that you lose changes without any warning or whatsoever during merging .. http://subversion.tigris.org/servlets/ReadMsg?list Name=users&msgNo=65992 .. and noone seems to be too bothered..

(don't get me wrong, i love subversion .. and i use it for my open source projects.. but currently CVS is way better.. just because of the tools and a few unnecessary annoyances less)

Not sure I'd call something that's well-documented in the FAQ a "trick."

Maybe if you would just implement SVN Obliterate, you'd be pestered less. ;)

If all Congressional documents were stored in a Subversion repository, Homeland Security would positively short-circuit trying to follow up on all of the suspicious emails from young DC residents saying things like "Hey, are you sure the latest pages are committed to Subversion yet?" and "Something just bombed in my sandbox, I'm going to have to nuke everything in sight and do an update!"

Correction, I meant cvs2svn
Here's the project page http://cvs2svn.tigris.org/

OfflineIMAP would fix most synchronization problems. Dovecot is a fast IMAP server and Maildrop coupled with your favourite smap filter could take care of the server part. Couple that with a good mail client (mutt) and a way to synchronize contacts. mutt can be customized with own keybindings, so that way one could add support for training the mail filter. I keep my home directory in a darcs repository to keep it in sync between machines. Other people use Subversion.

1. Exchanging finished documents for reading. PDF is better:
   1. It can reproduce the results exactly.
   2. It doesn't include Word's "change tracking" information which can cause embarrassing leaks.
   3. It's a standard with many interoperable implementations.
2. Exchanging in-progress documents for revision. At least for stuff limited to your company, a version control server (like Subversion with friendly TortoiseSVN clients) is better:
   1. Doesn't cause email storage to grow enormously. Instead, a server actually meant for this kind of thing stores only deltas. And only one copy of each document - on most mailservers, the disk space consumed by an attachment is proportional to the number of recipients.
   2. Lets you easily find the latest version of a document. ("Did he send me another copy after this? I'm not sure.")
   3. Lets you easily retrieve any previous version, see changes/authors/checkin comments. (I don't trust Word's built-in change tracking, and you shouldn't either. Its security model is flawed, and I don't think it's reliable to begin with.)
   4. Supports locking/unlocking documents to prevent conflicting changes.
   5. With some setup, supports diffing and merging office documents. You can maintain branches!
   6. Supports searching - where I work, we've plugged in swish-e for full-text searching over our documentation repository.

1. Exchanging finished documents for reading. PDF is better:
   1. It can reproduce the results exactly.
   2. It doesn't include Word's "change tracking" information which can cause embarrassing leaks.
   3. It's a standard with many interoperable implementations.
2. Exchanging in-progress documents for revision. At least for stuff limited to your company, a version control server (like Subversion with friendly TortoiseSVN clients) is better:
   1. Doesn't cause email storage to grow enormously. Instead, a server actually meant for this kind of thing stores only deltas. And only one copy of each document - on most mailservers, the disk space consumed by an attachment is proportional to the number of recipients.
   2. Lets you easily find the latest version of a document. ("Did he send me another copy after this? I'm not sure.")
   3. Lets you easily retrieve any previous version, see changes/authors/checkin comments. (I don't trust Word's built-in change tracking, and you shouldn't either. Its security model is flawed, and I don't think it's reliable to begin with.)
   4. Supports locking/unlocking documents to prevent conflicting changes.
   5. With some setup, supports diffing and merging office documents. You can maintain branches!
   6. Supports searching - where I work, we've plugged in swish-e for full-text searching over our documentation repository.

1. Exchanging finished documents for reading. PDF is better:
   1. It can reproduce the results exactly.
   2. It doesn't include Word's "change tracking" information which can cause embarrassing leaks.
   3. It's a standard with many interoperable implementations.
2. Exchanging in-progress documents for revision. At least for stuff limited to your company, a version control server (like Subversion with friendly TortoiseSVN clients) is better:
   1. Doesn't cause email storage to grow enormously. Instead, a server actually meant for this kind of thing stores only deltas. And only one copy of each document - on most mailservers, the disk space consumed by an attachment is proportional to the number of recipients.
   2. Lets you easily find the latest version of a document. ("Did he send me another copy after this? I'm not sure.")
   3. Lets you easily retrieve any previous version, see changes/authors/checkin comments. (I don't trust Word's built-in change tracking, and you shouldn't either. Its security model is flawed, and I don't think it's reliable to begin with.)
   4. Supports locking/unlocking documents to prevent conflicting changes.
   5. With some setup, supports diffing and merging office documents. You can maintain branches!
   6. Supports searching - where I work, we've plugged in swish-e for full-text searching over our documentation repository.

Good idea, building on a closed-source SCMS that's (barely!) a mid-level player in the market. I can understand not wanting ClearCase, but what's wrong with CVS or Subversion?

I use both Subversion and Perforce. There's one major feature still lacking from Subversion: merge tracking. There's work underway to design, implement, and document this feature, but it's not done yet. This is a huge deal for anyone with lots of branches.

Not that it's all roses with Perforce. My impression is that it doesn't scale very well. Most operations simply lock the entire database. I think it's a reader/writer lock, but it means that (for example) while the hour-long checkpointing pre-backup process happens every night, you can't do any write operations. (And there's a way to do an offline checkpoint, but it's not documented or supported, and is difficult to get right, with bad consequences if you don't.)

I've built a lot of web pages, and this has made me realize that it's incredibly quick and easy to whip up GUIs with HTML. The experience was much better than with the GUI builders I had used, and certainly beat coding GUIs by hand.

Of course, HTML is not intended as a language for describing native GUIs, so it has some limitations there. Fortunately, there is a variety of XML formats for describing real GUIs.

What makes XML so great for describing GUIs is that it's so good at describing nested objects. If you think about it, that's exactly what GUIs are: you've got your windows, with a bunch of widgets in it, one of which is a scrollable area with more widgets in it, etc. This is naturally described by an XML tree that contains all these widgets, with some attributes used for connecting them to the application; e.g. ids to allow the application to reference widgets, and embedded code to let the GUI respond to events (e.g. HTML's onclick).

Where many XML GUI languages fall short is in that they don't provide methods for building new abstractions. If you have a lot of subtrees that are all very similar (say, a frame, a title, a content window, and a hide and a show button), you'll completely have to code each of them in full. Any programming language worth its salt will provide a way to abstract over this (functions!), but I think the realization that XML GUI descriptions (and HTML documents!) are programs hasn't fully set in yet.

Next time I'm coding a GUI, I'll be generating the XML from a proper programming language. I've had good results with Lisp before...

We've gone through a similar experience when we grew from a team of 2 to a team of 8 in 3 months. Things we learned to be helpful in the way of tools:

- A Subversion repository for every project, and one repository per person, to host "private" projects. Also, TortoiseSVN for a windows shell integration with Subversion.

- Install Trac for every subversion project. Use it for writing documentation, and for following up on issues by posting Tickets. Tickets help a lot in maintaining the focus on problems and future developments. The integration with Subversion changesets and milestones is bliss.

- Install the appropriate modules for Trac for permission management, and allow your customers and testers to post tickets themselves. Eases up a LOT in the way of issue tracking and fixing bugs fast. It's a great way to have other people build your to-do list dynamically.

- Use frameworks for development. If you're programming with PHP use Symfony for real programming (and not just random code bits).

- Have a shared folder for files.

- Use an appropriate database backend and install common tools for database access (phpMyAdmin, pgpPgAdmin).

- Use the right tools for the job. As an example, remmember that MySQL works well as a fast database backend. But if you stick to MySQL for real applications where integrity and object mapping is relevant, you won't be doing real DB development unless you use views, functions and stored procedures. If you don't have these features, you'll never use them. If you use them, use PostgresSQL.

- Buy a billboard, a big one, and have a handy set of markers available. Do not underestimate the power of a billboard.

These are just things that worked and still work for us. There are plenty more things you can do, but first step is realizing the NEED for change, and getting everyone to work towards that.

I tend to do basically what MPlayer does nowadays, and that includes using Subversion for SCM, Bugzilla for bugs, Mailman for mailing lists, and Apache HTTPD for serving it all. I like to maintain a Debian Sid package (you can't directly upload to stable or testing anyhow, so the Debian maintainers will take care of adapting the package for those distros), and if someone else on the team knows anything about RPM, we also maintain the .spec file as well. I also like to keep an emerge script in there as well, but even if I didn't, someone would write one faster than you can bootstrap a Gentoo Mac Pro, so there's nothing to worry about there.

Here's a checklist of things i have used:

* Subversion is the backbone - http://subversion.tigris.org/
* Buildbot - Does the rest with right setup. http://buildbot.sourceforge.net/

When new patch is submitted to subversion, buildbot will get notification, checks out the latest changes and runs pre-defined commands on the source.

The predefined commands i've had where:

* Runs Unittests
* checks src against invalid keywords/intendation/characters and so forth
* compiles
* if compile was success, builds binary package and copies to fileshare
* if it wasnt, sends email to submitted about bad patch

And status of the process is visible thru web interface ..

Basicly buildbot was just acting as a "scheduler" and all building/testing where bunch of scripts we had written ourselves.

Quite nice platform =)

For most things - assembler, shell, Perl, C, C++, SQL... Slick Subversion integration is a plus.

Sun Studio for Linux might be worth trying out.

Something like this? http://readyset.tigris.org/

Does your Symbian playback DivX videos? No?

Yes, there is 3rd party software that does play DivX movies, and XviD codec has been ported to Symbian OS. More than that, latest Nokia phones can now play H.264 movies out of the box, and N93 can play iPod movies at full speed.

Well does your symbian support DRM?

Yes it does, if this matters to you.

Does it include drawing applications?

I honestly cannot imagine why you would want to draw on your phone, but UIQ includes Jotter application which allows you to have hand-drawn notes (in addition to handwriting recognition using Jot).

Does it have internal safe checks?

Symbian OS is sooo internally safe-checked you will be surprised.

Does it have full featured http www-browser which doesn't cut anything out of the web-sites content?

Yes, there is Opera, and now there is also Webkit-based Nokia browser for S60v3 phones.

And oh yeah, can you theme your phone as much as you want like changing places where the menu buttons lie in phone screen or can you even directly sync it without need for installing managerment software of somesort?

You can theme all recent Symbian OS phones to some extent, which is good because I don't think moving buttons and controls around is such a good idea from the UI stability and usability point of view. As for syncing, many Symbian phones are supported by Mac iSync/iCal/Address Book out of the box, and if not, there are usually simple hacks to get them working. In Windows the vast majority of external devices (USB in this case) require installing numerous drivers and multiple reboots, so if you are still using Windows, you probably won't be able to avoid installing drivers.

Symbian is allways Windows binary based and it makes development harder for phones.

You can use Xcode on the Mac to develop for Symbian OS (except for hardware debugging) using an Xcode plugin.

So, to paraphrase you, with all these points, it's hard to see reasons why use Linux like QTopia in mobile phones.

Subversion FAQ about Symbolic Links:

Does Subversion support symlinks?

Subversion 1.1 (and later) has the ability to put a symlink under version control, via the usual svn add command.

Details: the Subversion repository has no internal concept of a symlink. It stores a "versioned symlink" as an ordinary file with an 'svn:special' property attached. The svn client (on unix) sees the property and translates the file into a symlink in the working copy. Win32 has no symlinks, so a win32 client won't do any such translation: the object appears as a normal file.

You should also read up on Subversion External Definitions -- it looks as though you misunderstood how they really work.

Funnily enough I was setting this up yesterday... and I discovered for Eclipse 3.2 Tigris suggest using Subclipse 1.1.x as explained here. Also, for Mac OS X/Linux you need to first install JavaHL, as explained here.

Funnily enough I was setting this up yesterday... and I discovered for Eclipse 3.2 Tigris suggest using Subclipse 1.1.x as explained here. Also, for Mac OS X/Linux you need to first install JavaHL, as explained here.

I think it's all a big game, but seriously I think there's a point where you have to cave in and raise the numbers. Developers can't be all gung-ho about NOT raising the version numbers cause otherwise users will never feel the need to update to the newer version. Example : You have FireFox 1.1, Now FireFox 1.2 has come out ... probably not a big change, not going to upgrade. Now 1.3 comes out, same thing, who cares. 1.4 hmmm they must just be fixing minor things. 2.0 comes out, hmmm gotta get that right now, must be something important. You have IE 5, Now IE 6 comes out ... gotta upgrade, something important. Now IE 7 comes out, gotta upgrade, something important. Yes, there can be too many version changes (case in point Opera) ... but sometimes there can be too few also.

For something like a web browser the version number has not been critical; it's a testosterone driven publicity marker. It's mostly hype and anything that's broken in a new version can be re-enabled via an extension.

• First decimal - Major changes of file formats, features, and api's
• Second decimal - Features and requirement changes, but still backwards compatible
• Third decimal - Bug fixes

I think it's all a big game, but seriously I think there's a point where you have to cave in and raise the numbers. Developers can't be all gung-ho about NOT raising the version numbers cause otherwise users will never feel the need to update to the newer version. Example : You have FireFox 1.1, Now FireFox 1.2 has come out ... probably not a big change, not going to upgrade. Now 1.3 comes out, same thing, who cares. 1.4 hmmm they must just be fixing minor things. 2.0 comes out, hmmm gotta get that right now, must be something important. You have IE 5, Now IE 6 comes out ... gotta upgrade, something important. Now IE 7 comes out, gotta upgrade, something important. Yes, there can be too many version changes (case in point Opera) ... but sometimes there can be too few also.

For something like a web browser the version number has not been critical; it's a testosterone driven publicity marker. It's mostly hype and anything that's broken in a new version can be re-enabled via an extension.

• First decimal - Major changes of file formats, features, and api's
• Second decimal - Features and requirement changes, but still backwards compatible
• Third decimal - Bug fixes

Likewise, I enjoy promoting the use of LaTex, though awareness of both seems to be waning even in academia (e.g. my graduate school thesis folks "Hate LaTeX" and have seem to have chosen standards that can only be fulfilled by MS Word. Grrrr). If you're looking to get into LaTeX, I highly recommend "Guide to LaTeX, Fourth Edition" by Helmut Kopka and Patrick W. Daly. It's the only LaTex book I've ever purchased and is well-thumbed with use, despite the plethora of good internet sources for information as well.

A caveat regarding LaTex, though: it is, first and foremost, a typsetting package. In order to typeset a document, LaTex encourages you to structure it (chapters, sections, subsections, etc.).
The poster doesn't state whether it is his intention to programmatically strip out requirements from the document. Perhaps there are simpler formats for doing this.

I've also used Wikis for requirements gathering. While they lack the sophistication of LaTeX's markup features, they are very simple to setup and very easy to use. In a previous life I used them as the primary document repository to describe marketing materials, product information, and requirements in a small startup where the majority of users were tech-savvy but hadn't used a wiki before. In spite of this, we had no problems, and even used access to our wiki during the financial due-diligence review by our investors.

I'm suprised at folks advocating CVS so strongly rather than Subversion. Since the poster's users are likely running Windows, I think it is important to note that there is a nice, fairly easy-to-use explorer extension client that allows you to check-in/out sets of documents from a GUI. http://tortoisesvn.tigris.org/

Revisited

branching is woefully inefficient on the storage side:
Incorrect as far as "storage" is concerned. branching is virtual, but.... a branch or a tag is the same thing in SVN. The result is a duplication of the directory and file nodes without the base content. Only the deltas are stored. This method is lean on space usage but consumes filesystem directory entries at an alarming rate for systems with a lot of tags or branches. This may be acceptable for single-project-per-repository, but is unlikely to scale well for large numbers of projects with many tags and branches.

merging is (practically) unsupported:
Merging is only supported using the actual version numbers, not tags. Specifically, the merge command syntax requires the user to determine what version numbers are associated with what tags so as to perform the merge using the version numbers.

there is no rollback from a commit, because....:
Design decision.

it uses BerkeleyDB as the management system.. and that is bad because...:
An alternative to BDB has been released in 2004. The FSFS solution for SVN is more like the CVS solution being based on special files. The solution is not without its own problems (see the link: )

Oracle now own Sleepycat software (the makers of BDB):
Claimed as "irrelevant" by SVN supporters, but the question begs as to how long a major corporation is willing to support free (as in beer) software for non-core business still is unresolved.

A detailed explanation of how tagging/branching operates in SVN is definitely required in order to clearly understand why it can be a problem for repositories that contain multiple projects with many tags and branches. In short, the SVN manual says that the operation of tagging or branching is treated the same. A "svn copy" command is issued. This is the root of why so many people (including me until recently) believed that the back-end storage would be very inefficient. The "copy" is referred to by SVN zealots as a "cheap copy" because it is an almost constant time operation. What the documentation says occurs is that links are made to the original repository area and the file deltas are recorded in the new tree. Conceptually this means that space consumption is very small being only a small growth in the size of some control files and creation of some directories. Realistically, there is a practical limit on the number of directory entries that can be made in a system. So for a very large repository containing many modules, tags and branches, then the growth rate in directory entry usage would be significant if not unsustainable. Partitioning the repository into multiples spanning several servers may be the only way to scale that adequately. CVS suffers from a similar problem, but not to quite the same extent as multiple tags on the same file version would not cause duplications. The SVN solution of forcing a version to represent all the files in a project (compared to CVS where each file has separate version numbers) leads to some simplifications and some complications.

One of the various explanations of how it works :

The structure of SVN is interesting and in some cases disturbing.

http://subversion.tigris.org/design.html#server.fs .struct.bubble-up

a summary...

The reasons to move to SVN are based primarily on the claims that CVS is not an active open source project any more and that it is losing support. Those claims are misleading. CVS has moved from being a "constantly updated to fix and enhance" open source project to being a stable product now under the GNU banner.

The reasons to stay with CVS would be largely dictated by practical issues.

The migration of a multiple-project CVS repository to SVN appears on the surface to be an unsustainable move. Ideally, the projects would be split into separate repositories if such a migration was to be performed.

The clients deployed to u

I will say that AnkhSvn http://ankhsvn.tigris.org/ has been fantastic for my use in visual studio. I basically never use the CLI on windows anymore.

or... "a bunch of reasons NOT to use Subversion":

http://subversion.tigris.org/faq.html

1. branching is woefully inefficient on the storage side
2. merging is (practically) unsupported
3. there is no rollback from a commit, because....
4. it uses BerkeleyDB as the management system.. and that is bad because...
5. Oracle now own Sleepycat software (the makers of BDB)

so WHY would ANYBODY recommend this thing ?!?!?!

of course, have a read of another view...

http://www.pushok.com/soft_svn_vscvs.php

I second all the Subversion recommendations, and add to that the web-based Trac frontend. Trac incorporates a web-based interface to your SVN repository, along with authentication & access levels, wiki, and several project-management features (timeline tracking, milestone tracking, ticket system, etc.) Nice interface to SVN, though you should still install Tortoise on everyone's desktop for additional client functionality. Here's an interesting writeup on one sysadmin's use of SVN, Trac, and RapidSVN client.

It is my not-so-humble opinion that a lot of this Word mindset that is present in the Windows world stems from a lack of a gtkspell-ish component in Windows.

I have heard of people (and maybe folks still do, for all I know) who use Word as their email composition component. Can you imagine: firing up a copy of Word each time you press Reply?

I mention this because I was thinking about why Word docs are so ubiquitous in the business world when 90% of the docs I have seen contain absolutely no formatting or other "word processing" type functionality. What would one need to replace in order to get the B.A.s off of Word?

I believe the secret sauce is: spell checking.

I believe strongly that IE ('cause you can forget a BA using something other than the icon labeled "The Internet") with the Google toolbar (to provide speel chekking) against a versioned Wiki would go a long way toward answering TFA's need.

There is something to be said for a slightly more formalized requirements architecture (akin to http://xmlbasedsrs.tigris.org/), but I believe strongly that the presentation/editing of that data should be a light-weight as possible.

    -- /v\atthew

Use CollabNet. If you go to http://www.tigris.org/, you'll see that CollabNet is what powers the whole site. That will give you an idea as to what it its like.

Disclaimer: I don't work for them, I'm just really impressed by their product.

Of course, Subversion is no more your friend than CVS in this case since neither can do proper diffs! It's binary data for f*ck sake! Subversion handles binaries better than CVS, but not for the reason you state.

Actually, GUI Subversion clients like TortoiseSVN can show diffs for binary files like Word or OpenOffice, using the built-in diff capability of these programs. The end result is you can double-click your binary document and get a window showing you the differences.

The latest nightly TortoiseSVN builds even include an image diff viewer.

Don't forget TortoiseSVN, for more ease of use for the windows people.

SmartSVN

Back when I was looking at SVN clients, I found this one had the most promise. Of course, if you have users who know Windows Explorer (assuming your site is MS-based), then TortiseSVN is another good alternative.

Trac is a powerful ticketing system that integrates well with Subversion, and is built around an easy to use Wiki. I would also recommend using TortoiseSVN as a Windows client for both developers and non-developers.

Trac is a powerful ticketing system that integrates well with Subversion, and is built around an easy to use Wiki. I would also recommend using TortoiseSVN as a Windows client for both developers and non-developers.