[TriLUG] version control recommend

[Mike M]

I used proprietary things in the past. I was using RCS most recently because 
it was bone-simple and I was the only developer.  I recently moved to CVS 
with the repository in San Diego.  It's not much different from having the 
repository is on my own disk. Learning CVS puts you in company with the vast 
resources of open source development.  The CVS book and the Cedarqvist are 
good manuals. As Brent mentions below, I am keeping an eye on Subversion.  I 
do not have an appreciation for the benefits of Subversion yet, but its name 
keeps getting dropped by the clueful.

On Saturday 22 February 2003 00:58, Brent Verner wrote:
> [2003-02-21 23:46] Morris Walton said:
> | Hi,
> |
> | I do a little bit of personal development & was thinking about checking
> | out getting some version control other than "cp foo.c foo.c.1".  CVS
> | seems to be used by most of the linux development community....  I don't
> | need anything too complex.  I was curious what everybody else uses.
>
> CVS:
> ====
>   pros: quick && easy, especially when working solo on multiple
>         machines :-)  simple network access to remote repositories
>         over ssh.

How I got simple network access to remote repositories over ssh:

edited /etc/hosts:
192.168.50.60   my-url.com

issue manually or put in script or .bashrc:
[mike01 at dev0 S1]$ export CVSROOT=myname at my-url.com:/dirwherecvsrepsarekept
[mike01 at dev0 S1]$ export CVS_RSH=ssh

issue CVS commands as though repository is local; when prompted for password, 
enter myname at my-url.com password

references: 
http://cvsbook.red-bean.com/cvsbook.html
http://www.cvshome.org/docs/manual/cvs.html

>   cons: can be unfriendly in the face of code refactoring and/or
>         source tree hierarchy modifications, since directories
>         are not versioned -- renaming directories requires
>         manual maintenance inside the CVSROOT
>
>   quick-nasty-tutorial: (for using a local repo)
>     'cvs -d $CVSROOT init'
>       creates a fresh repository
>     'cvs -d $CVSROOT import some-new-code brent start'
>       imports/creates a new module from the current directory
>     'cvs -d $CVSROOT co some-new-code'
>       checks out working version
>     'cvs ci'  (from within working tree)
>       checks in changes
>     'cvs up' (from within working tree)
>       updates a working tree
>
>
> subversion:  http://subversion.tigris.org
> ==========
>   pros: much more advanced versioning -- directories are versioned
>         and can be easily renamed.  more granular access control
>         on repository servers, since it runs behind apache.
>         much better (remote) file locking mechanism due to
>         features of DAV.
>   cons: complex.  versioned files in binary/database format,
>         requiring the use of a special program to manage
>         the repository.  network access requires apache2/mod_svn
>         (which is based on the DAV http extensions).  Still in
>         alpha stage (tho I've had _no_ problems in my limited use)
>
>   quick-nasty-tutorial: (for using a local repo)
>     'svnadmin create $SVNROOT'
>        creates a repository
>     'svn import file://$SVNROOT some-new-code some-new-code'
>        imports/creates a module named some-new-code from
>        the directory named some-new-code
>     'svn co file://$SVNROOT/some-new-code'
>        checkout a working copy of code into current directory
>     'svn ci'  (from within working copy)
>        checks in changes
>     'svn up'  (either it updates the working copy, or quenches thirst)
>
>
> There are a number of other systems, but these two are the only
> I am familiar with.  I can recommend both, but I'd recommend
> starting with CVS, and keeping an eye on subversion :-)
>
> I currently use CVS 90% of the time, but am already starting
> (some) new projects in subversion.
>
> I'd like to see others' experience/recommendations on this subject
> as well.
>
> hth.
>   b

-- 
Mike M.