changeset 13632:c4a5d8950d8c

[gaim-migrate @ 16030] Change CVS to SVN in a bunch of places, and use "2.0.0dev" as the version string. committer: Tailor Script <[e-mail]>

--- a/HACKING	Wed Apr 12 02:49:20 2006 +0000
+++ b/HACKING	Wed Apr 12 04:00:19 2006 +0000
@@ -28,26 +28,24 @@
 you don't know GTK+ you should go learn that first.
 
 If you're going to hack gaim, PLEASE, PLEASE PLEASE PLEASE send patches
-against the absolute latest CVS. I get really annoyed when I get patches
+against the absolute latest SVN. I get really annoyed when I get patches
 against the last released version, especially since I don't usually have
 a copy of it on my computer, and gaim tends to change a lot between
-versions. (I sometimes get annoyed when they're against CVS from 3 days
+versions. (I sometimes get annoyed when they're against SVN from 3 days
 ago, but can't complain because it's usually my fault that I haven't
-looked at the patch yet.) To get gaim from CVS (if you haven't already),
+looked at the patch yet.) To get gaim from SVN (if you haven't already),
 run the following commands:
 
-$ export CVSROOT=:pserver:[e-mail]:/cvsroot/gaim
-$ cvs login (hit enter as the password)
-$ cvs co gaim (you'll see it getting all of the files)
+$ svn co https://svn.sourceforge.net/svnroot/gaim/trunk gaim
 $ cd gaim
 $ ./autogen.sh
 
 You'll now have your normal gaim tree with ./configure and all (which
 ./autogen.sh takes the liberty of running for you). (If you want to make
-your life really simple, learn how CVS works. CVS is your friend.) To make
+your life really simple, learn how SVN works. SVN is your friend.) To make
 a patch, just edit the files right there in that tree (don't bother with
 two trees, or even two copies of the same file). Then when you're ready to
-make your patch, simply run 'cvs diff -u >my.patch' and post it on 
+make your patch, simply run 'svn diff > my.patch' and post it on
 sf.net/projects/gaim in the patches section.
 
 Some Documentation is available on the Gaim api if you run the command 

--- a/README	Wed Apr 12 02:49:20 2006 +0000
+++ b/README	Wed Apr 12 04:00:19 2006 +0000
@@ -73,7 +73,7 @@
 
 If you come across a bug, please report it to http://gaim.sf.net/bug.php.
 
-See README.CVS for information on the bleeding edge CVS version of Gaim.
+See README.SVN for information on the bleeding edge SVN version of Gaim.
 You probably shouldn't use it, as it may eat your children, as well as
 your settings.
 

--- a/README.CVS	Wed Apr 12 02:49:20 2006 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,41 +0,0 @@
-If you plan to use gaim CVS, PLEASE read this message in its entirety!
-
-Gaim is a fast-moving project with a somewhat regular release schedule.
-Due to the rate of gaim development, CVS undergoes frequent bursts of
-massive changes, often leaving behind brokenness and partial
-functionality while the responsible developers rewrite some portion of
-code or seek to add new features.
-
-What this all boils down to is that CVS _WILL_ sometimes be broken.
-Because of this, we ask that users who are not interested in
-personally tracking down bugs and fixing them (without a lot of
-assistance from the developers!) avoid CVS and use releases.  Since
-releases will be made often, this should not prevent anyone from using
-the newest, shiniest features -- but it will prevent users from having
-to deal with ugly development bugs that we already know about but
-haven't gotten around to fixing.
-
-If you are interested in hacking on gaim, please read README and
-HACKING, and take note of the issues in PROGRAMMING_NOTES.  (Note that
-they may be somewhat out of date at times.) Win32 developers, please
-read README.mingw.
-
-By far the best documentation, however, is the documented code.  Not
-all parts of gaim have yet been documented, but the major subsystems
-are falling fast.  If you have doxygen, you can use the Doxyfile in
-the toplevel directory to generate pretty documentation.  Otherwise
-(or even if you do!), the header files for each subsystem contain
-documentation for the functions they contain.  For instance,
-conversation.h contains documentation for the entire
-gaim_conversation_* API, and account.h contains documentation for the
-gaim_account_* API.
-
-If you have questions, please feel free to contact the gaim developers
-by email at [e-mail], on IRC at
-irc.freenode.net in #gaim, or via the sourceforge forums at
-http://www.sourceforge.net/projects/gaim.  Please do as much homework
-as you can before contacting us; the more you know about your
-question, the faster and more effectively we can help you!
-
-Send patches to [e-mail] or post them in the
-Sourceforge forums at http://www.sourceforge.net/projects/gaim.

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/README.SVN	Wed Apr 12 04:00:19 2006 +0000
@@ -0,0 +1,41 @@
+If you plan to use gaim SVN, PLEASE read this message in its entirety!
+
+Gaim is a fast-moving project with a somewhat regular release schedule.
+Due to the rate of gaim development, SVN undergoes frequent bursts of
+massive changes, often leaving behind brokenness and partial
+functionality while the responsible developers rewrite some portion of
+code or seek to add new features.
+
+What this all boils down to is that SVN _WILL_ sometimes be broken.
+Because of this, we ask that users who are not interested in
+personally tracking down bugs and fixing them (without a lot of
+assistance from the developers!) avoid SVN and use releases.  Since
+releases will be made often, this should not prevent anyone from using
+the newest, shiniest features -- but it will prevent users from having
+to deal with ugly development bugs that we already know about but
+haven't gotten around to fixing.
+
+If you are interested in hacking on gaim, please read README and
+HACKING, and take note of the issues in PROGRAMMING_NOTES.  (Note that
+they may be somewhat out of date at times.) Win32 developers, please
+read README.mingw.
+
+By far the best documentation, however, is the documented code.  Not
+all parts of gaim have yet been documented, but the major subsystems
+are falling fast.  If you have doxygen, you can use the Doxyfile in
+the toplevel directory to generate pretty documentation.  Otherwise
+(or even if you do!), the header files for each subsystem contain
+documentation for the functions they contain.  For instance,
+conversation.h contains documentation for the entire
+gaim_conversation_* API, and account.h contains documentation for the
+gaim_account_* API.
+
+If you have questions, please feel free to contact the gaim developers
+by email at [e-mail], on IRC at
+irc.freenode.net in #gaim, or via the sourceforge forums at
+http://www.sourceforge.net/projects/gaim.  Please do as much homework
+as you can before contacting us; the more you know about your
+question, the faster and more effectively we can help you!
+
+Send patches to [e-mail] or post them in the
+Sourceforge forums at http://www.sourceforge.net/projects/gaim.

--- a/VERSION	Wed Apr 12 02:49:20 2006 +0000
+++ b/VERSION	Wed Apr 12 04:00:19 2006 +0000
@@ -1,1 +1,1 @@
-2.0.0cvs
+2.0.0dev

--- a/config.h.mingw	Wed Apr 12 02:49:20 2006 +0000
+++ b/config.h.mingw	Wed Apr 12 04:00:19 2006 +0000
@@ -529,13 +529,13 @@
 #define PACKAGE_NAME "gaim"
 
 /* Define to the full name and version of this package. */
-/* #define PACKAGE_STRING "gaim 2.0.0cvs" */
+/* #define PACKAGE_STRING "gaim 2.0.0dev" */
 
 /* Define to the one symbol short name of this package. */
 #define PACKAGE_TARNAME "gaim"
 
 /* Define to the version of this package. */
-/* #define PACKAGE_VERSION "2.0.0cvs" */
+/* #define PACKAGE_VERSION "2.0.0dev" */
 
 /* Define if <inttypes.h> exists and defines unusable PRI* macros. */
 /* #undef PRI_MACROS_BROKEN */
@@ -579,7 +579,7 @@
 /* #define USE_SM 1 */
 
 /* Version number of package */
-/* #define VERSION "2.0.0cvs" */
+/* #define VERSION "2.0.0dev" */
 
 /* Define to 1 if your processor stores words with the most significant byte
    first (like Motorola and SPARC, unlike Intel and VAX). */

--- a/configure.ac	Wed Apr 12 02:49:20 2006 +0000
+++ b/configure.ac	Wed Apr 12 04:00:19 2006 +0000
@@ -1,5 +1,5 @@
 dnl Process this file with autoconf to produce a configure script.
-AC_INIT([gaim], [2.0.0cvs], [[e-mail]])
+AC_INIT([gaim], [2.0.0dev], [[e-mail]])
 AC_CANONICAL_SYSTEM
 AM_CONFIG_HEADER(config.h)
 AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION)
@@ -645,8 +645,9 @@
 dnl  the build process to generate the code, not for running gaim.
 dnl  This autogenerated code is system-independent, so in principle we
 dnl  can generate all of it before shipping.  But I thought adding
-dnl  auto-generated stuff to the CVS is inelegant.  Alternatively,
-dnl  these python scripts could be rewritten in C (brrrr ...).
+dnl  auto-generated stuff to the repository is inelegant.
+dnl  Alternatively, these python scripts could be rewritten
+dnl  in C (brrrr ...).
 
 AC_ARG_WITH([python],
 			AC_HELP_STRING([--with-python],

--- a/gaim.spec.in	Wed Apr 12 02:49:20 2006 +0000
+++ b/gaim.spec.in	Wed Apr 12 04:00:19 2006 +0000
@@ -9,7 +9,7 @@
 %define beta 3
 
 %if 0%{?beta}
-%define gaimver %(echo "@VERSION@"|sed -e 's/cvs//; s/beta.*//')
+%define gaimver %(echo "@VERSION@"|sed -e 's/svn//; s/beta.*//')
 %else
 %define gaimver @VERSION@
 %endif