[thelist] Getting version control into the office for the first time

[Will]

Subversion is very robust.  You'll be happy you did it.  I can't really see
a reason to use a distributed version control for a small team.  One very
compelling reason to use svn for our team is the number of other tools it
currently integrates with including a number of QA/Bug tracking systems.

Big snafu for folks getting started with svn: renaming files using the OS
instead of svn's "rename" tool.  dear god, DONT DO IT!

At this point, svn is almost silly simple to administer.  1. create repo  2.
import whatever files you want to start with into repo 3. that's about it.
:)



On Fri, Sep 26, 2008 at 9:03 AM, Barry Woolgar <barry at burnthebook.co.uk>wrote:

> Hello all
>
> I'm hoping to convince the boss about the benefits of using a version
> control system over the current system of there being _no system_. We are
> taking on a third developer soon and I can see things going quite wrong
> quite quickly.
>
> I've read up about Subversion and it seems the way to go, but I'm open to
> suggestions of simpler alternatives if you have them.
>
> So, my questions are:
>
> What are your experiences of getting version control into a development
> environment (we are a LAMP house) for the first time?
>
> What things do you wish you'd know about before you started (technical or
> otherwise)?
>
> What would we need to look out for with regard to common mistakes and doing
> things the wrong way (ie, bad habits)?
>
>
> I'd appreciate any comments, suggestions or warnings you can share -
> unfortunately there's only so much I can learn from developing with a local
> repository and myself.
>
>
>
> Thanks in advance, have a good weekend
>
> Barry
>
>
>
> --
>
> * * Please support the community that supports you.  * *
> http://evolt.org/help_support_evolt/
>
> For unsubscribe and other options, including the Tip Harvester
> and archives of thelist go to: http://lists.evolt.org
> Workers of the Web, evolt !
>