Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Subversion is adopted by more and more bigger projects. A list of the big users can be found on the the Subversion Testimonials. From some talks on #drupal and some queries with some devs, i know some of them want switch to svn aswell.
i am a svn user since more than 1.5years now. i helped converting many smaller projects and maintain 3 svn using projects myself. my biggest conversion so far was irssi ( http://svn.irssi.org/ ).
i would help you to move to svn. so would the civicspace people (i think).
so long ...
darix
Comments
Comment #1
axel CreditAttribution: axel commentedThere 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
Comment #2
Bèr Kessels CreditAttribution: Bèr Kessels commentedThat 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.
Comment #3
Dries CreditAttribution: Dries commentedI'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.
Comment #4
axel CreditAttribution: axel commented"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:
Drupal in many directions is very innovative project and I think nice to develop it with really innovative tools, like Darcs :)
Comment #5
Steven CreditAttribution: Steven commentedIMO 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.
Comment #6
chx CreditAttribution: chx commentedBack 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.
Comment #7
axel CreditAttribution: axel commentedI 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:
Comment #8
sepeck CreditAttribution: sepeck commentedI 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..
Comment #9
axel CreditAttribution: axel commentedIf 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/
Comment #10
gordon CreditAttribution: gordon commentedI 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
things I would like to see
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.
Comment #11
axel CreditAttribution: axel commentedBut 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.
Comment #12
axel CreditAttribution: axel commentedI renamed subject, because discussion moved from only SVN questions.
Comment #13
diroussel CreditAttribution: diroussel commentedSVN 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):
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
Comment #14
diroussel CreditAttribution: diroussel commentedchanged title back. I ment to title my post, not the issue!
Comment #15
moshe weitzman CreditAttribution: moshe weitzman commentedfolks - 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.
Comment #16
darix CreditAttribution: darix commentedwhy did noone tell me there is discussion here?
1. moshe: i offered dries and kjartan to port the scripts. so did various other persons (chx, civicspace folks. i think bryght would help too.) we never got them so we could at least look at them.
and i really wonder how many scripts could be just dropped because they worked around cvs problems.
2. I no longer recommend Subversion alone.
Subversion itself is fine for the central core of the Drupal development. Who only needs a place to hack his module and version it will live happily with svn. svn has proven to be mature and widely adopted now. We have gui clients for nearly all platforms and more are under development.
But there are other situations where you want to develop your own branch on top of drupal. A module needs a patch you wont get into core for example, or projects like bryght or civicspace. They all would like to see a way to easily sync changes from the upstream (You) into their branches.
There is a solution for this problem: SVK
- svk works very well with SVN.
- svk has very good merging capabilities.
Over a long time I easily merged the changes from the upstream repository into my local development repository with svk.
A minus for svk is the lack of gui. But we will see what we get in the future.
My conclusion about all this:
svn for the centralized development and svk as glue to the off site branches and for offline development.
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?
just my 2 cents
darix
Comment #17
chx CreditAttribution: chx commentedI 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 :)
Comment #18
chx CreditAttribution: chx commentedTo 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!
Comment #19
adrian CreditAttribution: adrian commentedI have to agree with chx.
Re: the issue with berkeleydb , isn't it possible to run subversion with Fastdb or something Darix?
Comment #20
darix CreditAttribution: darix commentedfsfs is a non-database back-end alternative for the repository, new in svn 1.1.
You can read about it in the book at http://svnbook.red-bean.com/svnbook/ch05.html#svn-ch-5-sect-1.2.A .
A more in-depth description of differences between fsfs and Berkeley DB is at
http://svn.collab.net/repos/svn/trunk/notes/fsfs .
and about all rants against bdb: http://pixel.global-banlist.de./svn/permissions
darix
Comment #21
darix CreditAttribution: darix commentedbdb transactions are acid.
bdb is used as backend for the mysql transactional table types.
bdb can wedge if you powerdown the box during a commit but in 99% you can recover from that.
darix
Comment #22
darix CreditAttribution: darix commentedand portability is not an argument as the repos wouldnt move every few days.
anyway -> fsfs.
darix
Comment #23
Dries CreditAttribution: Dries commentedDarix: 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.
Comment #24
axel CreditAttribution: axel commented> 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.
Comment #25
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedPart 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.
Comment #26
ax CreditAttribution: ax commentedyou can put the location of the external diff into the subversion runtime configuration area, eg.
that way, your cmdline reduces to
accepatble, isn't it?
Comment #27
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedNot really. As I explained it does not matter so much for the patches I generate but for the patches I get sent.
Comment #28
apakuni CreditAttribution: apakuni commentedHow about offering an SVN mirror?
Comment #29
rkerr CreditAttribution: rkerr commentedAt 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/
Comment #30
Heine CreditAttribution: Heine commented*sigh*.
Moving to the right project.
Comment #31
chx CreditAttribution: chx commentedSVN 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.
Comment #32
anarcat CreditAttribution: anarcat commentedNot 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).
Comment #33
rbeton CreditAttribution: rbeton commentedIMHO 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
Comment #34
philbar CreditAttribution: philbar commentedIt'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.
Comment #35
RobLoachWhy is Drupal still using CVS covers a few things that would have to happen before the Drupal repository moves anywhere.
Comment #36
merlinofchaos CreditAttribution: merlinofchaos commentedThe 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.