Move to subversion (or another advanced RCS)

There are a lot of versioning systems with interest features, Subversion is not unique. I vote for Darcs (http://darcs.net) - distributed system with advanced features. Darcs is changesets based (contrary to file-based CVS), minimal system requirements (r/o repository may be placed on _any_ webhosting, for r/w repository you need ftp/ssh access), patches may be sended and accepted through email, easy branches etc. And main feature: due to distributed nature of this system, each copy of repository is fully functional repository, repositories may be synced each with other in any way. See short intro at www.darcs.net/DarcsWiki/GettingStarted

PS. Old CVS repository may be converted to Darcs with `tailor` utility. See: http://darcs.net/DarcsWiki/Tailor

And main feature: due to distributed nature of this
system, each copy of repository is fully functional repository,
repositories may be synced each with other in any way.

That was my main reason for bringing up DARCS in the past too. But maturity level made the mayority choose for SVN.

Darcs is IMO by far the best suited for a drupal.org alike community, with distributions and scattered developers. Its dead easy to get a diff of the Civicspace distro vs drupal.org with darcs.

I've been using Darcs for a couple months now, and I don't like it. It is less convenient than CVS, although it has a number of interesting features.

It is less convenient than CVS, although it has a number of interesting features.

"Convenience" is question of time. Drupal on first look is also strange thing :) CVS has very ineffecitve realization of files moving/renaming, not easy branching. Of course, CVS is very stable and has very much 3d party utilities and GUIs. But for example Subversion also very stable and has many extensions, but also solves problems of CVS. I not sure, that Darcs is only what we need, but I sure - CVS is not best choice for large project like Drupal.

In my taste Darcs is very convenient for usage in unix environment. Though it looks here more like 'emacs', than 'vi', i.e. offer many functions which RCS not need - send patches by mail for example. Real problem may be memory usage - I not sure. I use darcs only for personal projects and don't test it for large repositories. See for example comments for article http://lwn.net/Articles/109719/ about memory usage in Darcs 1.0 (I don't know may be it solved in later releases).

Brief list of Darcs features:

• The ability to record changes locally.
• The ability to perform interactive record operations.
• The ability to un-record a non-published change.
• A full set of interactive commands.
• Support for integrating test suites into a repository.
• Support for multiple repository server protocols including http, ftp, and ssh.
• User-defined repository write access.
• Symmetric repositories, all darcs repositories are equal.
• Support for repository browsing via a web server CGI script.
• Cross-platform capable with support for Unix, Mac OS-X, and Windows.
• History is preserved when files and directories are moved around.
• Support for token replacing allowing global variable and function name changes.
• Per-user and Per-repository default setting capabilities.

Drupal in many directions is very innovative project and I think nice to develop it with really innovative tools, like Darcs :)

IMO an important aspect of choosing a RCS is whether or not there are nice clients available for it. Our contributors will need to use it, and command-line presents unnecessary barriers IMO. Having advanced features is nothing if you can't use them easily.

Personally, I find command-line RCS to be a pain to use and much more prone to errors. In WinCVS, I can instantly see which files were locally modified because their icon turns red. I can see tags, revisions and branches all together in one neat view. I can check out a branch without having to remember commands or the order of their arguments. And by using commands in a GUI, I am naturally reminded of which fields are needed and what other possibilities there are. It is basic usability.

Looking at Darcs specifically, there doesn't appear to be any mention of GUI clients on their site whatsoever, which seems to indicate it hasn't moved beyond the geek-tool phase. Definite -1 on that then.

Subversion has TortoiseSVN which looks really nice. Haven't tried it out yet, but the screenshots look promising.

Back in the dark age when I was using Windows, I used TortoiseCVS. It was the only thing that was better than anything comparable on Linux.

Personally, I find command-line RCS to be a pain to use and much more prone to errors.

I think, this is not RCS problem, but work environment problem. Windows not have convenient command line and usage of any command line tool become as real pain. Also it depends of program logic. Simple interfaces well works without GUI. Well, I also use GUI under Linux for many CVS operations, but only because I can't remember these all cryptic options and unclear logic of CVS. Contrary to it, I easy use Darcs only in command line - there are recipes in Darcs Wiki for bash/zsh autocompletion and also integration with Emacs. Also Darcs support coloring of output for diffs and other commands. These features make + compact command set make usage really comfortable, more comfortable then dozens of menus, buttons and icons in GUI. But unfortunately it fair only for unix environment, in windows missing of GUI grow to real problem. Though developers promise GUI in future Darcs releases:

--gui
Certain commands may have an optional graphical user interface. If such commands are supported, 
you can activate the graphical user interface by calling darcs with the --gui flag.
NOTE: The GUI is not currently functional, but is expected to re-appear in a future release.

I am looking forward to SVN myself and I have to take exception with windows not having an easy to use cmd line interface. On the contrary, the windows cmdline is very easy to use. I use it for administration purposes everyday at work.It all depends on your experiance and work environment.

The fact that DARC does not not have a GUI interface as mature as those used by CVS and SVN is not a good recommendation in my humble opinion..

On the contrary, the windows cmdline is very easy to use.

If windows CLI such easy to use, why the absence of GUI is such problem here? ;) Though if use Cygwin or similar environment for CLI, but then it is not windows, it is more unix.

Darcs have not so much commands, each of them has 2-3 optional parameter. With autocompletion usage of it is simple without gui, though of course many users not adopt such way. Really, system without gui probably not right choice for Drupal project :\

Anyway, even SVN will more convenient than CVS. Though more attractable in my opinion are distributed systems:
http://web.verbum.org/blog/freesoftware/distributed-future
http://lwn.net/Articles/112710/

I have been thinking about this for a while, and before we change we need to make sure that a few features are covered.

essential requirements

• Needs to work all main operating systems, eg linux, windows, mac os x

things I would like to see

• distributed source management
• the ability to retain the original author of a patch. ie the original author will be credited with the patch even though they were not the final person to commit it to the repository.
• current repositories need to be converted to the new system.
• patch picking, so if you want you can take from a distributed repository only the patches you want.
• sync patches from multiple sources.

There are many very advanced source management systems, but we need to pick one that will work for us and make it easier for us to work more effeniently.

the ability to retain the original author of a patch

But what for case, when patches intersect each with other for same code? Can you let example of RCS with such feature? For example in darcs cgi you may click any line of source code and get name of patche from where it came. You mean about something similar?

All other requirements (except conversion to new system) covered by darcs too, include multiplatform support. But people want GUI and darcs now has only command line and CGI for webaccess.

Conversion from CVS to work through `tailor` utility (about it I already wrote above). You may see info about it in DarcsWIki (though afaik it is not Darcs subproject): http://darcs.net/DarcsWiki/Tailor This python script support migration of changesets between next RCS: CVS, Subversion, Monotone, Darcs, Codeville, Bazaar-NG.

I renamed subject, because discussion moved from only SVN questions.

SVN looks like a great project at first glance, it's had a good take up through out the FOSS community and looks like it will be _the_ dominant RCS in the FOSS world.

However, I think it's important to look at the vission of SVN, which is just to replace CVS with a non-buggy and maintainable code base. It doesn't offer anything smart, like merge tracking or direct changeset support. So you've still got the same problems as CVS in that when merging between branches, you can get the same patch applied twice. Or when doing a 'get latest', you can get half of someone elses changeset, if you are unlucky.

Also, although SVN offers 'atomic' checkins, it's not an ACID checkin. If someone pulls the plug on your box during a commit, the chances are the the Berkley DB will corrupt and you'll have to restore from backup. Plus the DB is non-portable, endian-ness problem I think (?).

In my day job I use ClearCase. At $1000 per developer license, plus the need for a full time admin, it's not a great choice for drupal. However, I just love the merge tracking. We we a 'branch per task' model to approximate chanage sets. Each merge from my branch, to the release branch, to main (HEAD), to another developers branch is tracked, so that automated merge feature can track back up the merge chain to find the common ancestor of two versions, and then 'do the right thing'. I've found, amazingly 90% of the merges between mulitple branches, with 20 developers working on the same files, required no manual intervention.

I've never contributed code to the drupal project, but I know if was to do so, I'd want to version control my changes whilst they are in development. (So I can rollback changes if required). If drupal used SVN, I'd have to run a standalone repository at home, and then produce a patch before applying it to the central SVN. If a distributed rcs was used, then the process of developing with rcs locally and remotely becomes a little more fluid.

I've not done enough research into where the different distributed RCS systems are upto, but I the ideas they are based on are as interesting as they are varied.

Distributed version control systems that are worth a look (in no specific order):

• SVK
• Codeville
• Monotone
• Darcs

For a good comparison of these see here: http://www.livejournal.com/users/bramcohen/17319.html I can highly reccomend this!

In summary

SVN is a safe choice. One of the distributed version control alternatives may offer a model with a closer match to the way drupal is developed.

See also: http://del.icio.us/tag/version+distributed

changed title back. I ment to title my post, not the issue!

folks - please no more discussion of which source control you prefer. Drupal is not going to change until someone volunteers to rewrite all the scripts and documentation that rely on CVS. And provide some help to everyone who is active in Contrib. If you want to perform that work, then please post here. Otherwise, this discussion is going nowhere.

I have used SVK when we had core SVN mirror for a little time. It was a joy.

If you need a helping hand to move away from CVS, then I can offer two fast codings ones :)

To sum up:

SVN is the only choice because of maturity. KDE have moved to SVN, this tells us something.
SVK is a good spice for SVN.

There can be an endless debate whether darcs git or whatever is better but as none of the is mature enough they are (alas) out of question. End the debate, let us start coding!

I have to agree with chx.

Re: the issue with berkeleydb , isn't it possible to run subversion with Fastdb or something Darix?

Darix: as I told you, you just need to port or update 'contributions/modules/cvslog/cvs.module'. The module has code that imports CVS data from a CVS repository, and does the integration of project module, CVS and the user accounts. Except for that module, we have a 10-line script that hooks into CVS to insert new data in the tables upon a commit.

> 3. a side note to all patch based SCMs:
> anyone ever tried to undo tree changes with them?
> moving files around and undoing that later?

Darcs does both things with sequence of two commands: `darcs unrecord`, `darcs revert`. First command changes repository but untouch working copy, next sync working copy with repository. Though, I tried to undo very simple sequences of changes, because don't use darcs for large projects yet. Moving works for files and dirs. Some explanations about unrecording patches in manual: http://darcs.net/manual/node6.html#SECTION00623000000000000000

> KDE have moved to SVN, this tells us something.

Some notices about svn, darcs, svk: http://www.kdedevelopers.org/node/view/1028

This page describe current problems in svk: http://svk.elixus.org/?SVKSucks
Most of them unimportant, though. Serious problem is poor documentation.

Part of moving to svn or something else than cvs should be a server side script that accepts -F^f or -p as input to diff. these options make reviewing patches so much easier and I plainly refuse to review patches that don't use them.
Yet to achieve this for svn you need to type: svn diff --diff-cmd /usr/bin/diff -x -puN which is a bit much. We cannot ask all people to install a script on their side that makes the neccessary substitutions.

you can put the location of the external diff into the subversion runtime configuration area, eg.

[helpers]
diff-cmd = /usr/bin/diff

that way, your cmdline reduces to

svn di -x -puN

accepatble, isn't it?

Not really. As I explained it does not matter so much for the patches I generate but for the patches I get sent.

How about offering an SVN mirror?

At the risk of bringing this thread back from the dead..

GNOME is also moving to SVN very soon now and have the general notes and a migration script posted here:
http://live.gnome.org/Subversion/

*sigh*.

Moving to the right project.

SVN buys us very little , the tags/branches concept is the same, we would port lots of our integration code.

A distributed RCS would be very nice but let's get back on the topic when there is one which is supported by IDEs, has GUIs etc.

Not that I want to revive this thread... Just a quick note to mention bzr now has a GUI: http://bazaar-vcs.org/bzr-gtk (integration in Nautilus, notably).

Subversion also has RapidSVN and GUIs and integration in various IDEs (Eclipse, Emacs, etc).

IMHO Subversion is a compelling replacement for CVS, just as its creators intended.

Subversion is now very stable - it's at version 1.4.x and works very well. The clients are also stable with a good choice for each platform (Windows, Linux, MacOS) now available.

A large proportion of open-source projects have made the switch to Subversion. I think Drupal should do so too.

Rick

It's been over 2 years since this was last discussed and I think it's time for reconsideration.

SVN is clearly the most popular version control system, but I couldn't find any statistics to show by how much. Because of it's popularity, it has become integrated with many tools like Coda and Dreamweaver while CVS and other version control systems require third-party plugins. Not to mention SVN has excellent Windows Explorer and OSX Finder integration with TortoiseSVN and SCplugin.

Perhaps a poll could help the Drupal community gain a better insight into this matter:

* I use SVN for other projects but it's not my favorite.
* I would prefer using SVN for my drupal projects.
* I prefer sticking with CVS for my drupal projects.
* I prefer using another version control system for my drupal projects.
* I don't maintain a drupal project.

If a large majority choose "I would prefer using SVN for my drupal projects." it would be clear that the drupal infrastructure team should plan a migration. If a large majority choose "I prefer sticking with CVS for my drupal projects", then that is the nail in the coffin for this thread.

Why is Drupal still using CVS covers a few things that would have to happen before the Drupal repository moves anywhere.

The conversation has been had, many times. Until project.module supports svn fully, there's no point in re-opening the issue just to rehash the conversation. again.