Well thanks all.
Sounds like SVN is the way to go then for
me.
More stuff to learn I guess but you gotta
start somewhere...
Robert P. Reil
Managing Director,
Motorcyclecarbs.com,
Inc.
4292 Country Garden
Walk NW
Kennesaw,
Ga. 30152
Office 770-974-8851
Fax 770-974-8852
www.motorcyclecarbs.com
From: Jeremy Allen
[mailto:[EMAIL PROTECTED]
Sent: Monday, August 07, 2006 3:48
PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss]
Change Management Options Debate.
THe points for SVN go
like this:
Versioning is much more sane and manageable. When I first started using SVN it
was much more bearable to me. Your entire codebase can be encapsulated in one
SVN version number instead of each file having its own version. When I say
version 543 of the codebase with SVN there is no ambiguity about the state of
the system when I say that. CVS has no easy concept of referring to the
contents of the repository as a whole with a version number. That to me is what
makes SVN so much better.
SVN is easier to manage. This is a personal opinion but my experiences bear
this one out. The command line for SVN is much more intuitive.
SVN allows for you to delete and rearrange branches. This is HUGE. Deleting
folders in CVS is plain not possible. CVSs delete functionality is just lacking
in every way.
Directories have revision numbers too. Everything in the system behaves
consistently and there are no surprises or differences to deal with with
different types of entities in the system as there is with CVS.
SVN has no special functionality for branching, merging, or tagging. It is all
implemented using the same functionality so how you arrange your repository is
up to you. The cost of these operations in SVN is constant O(1) which is great
compared to CVS and its slowness with many of these operations, especially on
larger codebases.
That is all I can remember off the top of my head. I know there are a couple of
other good points somewhere in there that favor SVN. Sure a lot of these are
small things but add them up and it makes SVN much better to work with. So if
you are starting from scratch why bother with CVS? Unless you have very
specific interoperability requirements or you are already really experienced
with CVS from a management perspective I recommend using SVN. Its not just
about solving "issues" with CVS. The system is also a bit more
cohesive overall. And I promise you that with a team of 10 developers that
consistently write code every week you WILL have to deal with these
"issues" in CVS. They are common and frequently annoying problems not
just edge case things that come up once in a while.
That said if you already have a lot of experience with CVS or have some
specific requirements SVN may not work out. If this is starting from scratch
and you have not managed CVS or SVN before SVN wins quite easily in my mind.
Why use an inferior system if you have no requirements holding you to it?
Jeremy
On 8/6/06, Charlie
Arehart <[EMAIL PROTECTED]>
wrote:
And a good book of
exploration (which also discusses the differences and
benefits over CVS) is "Pragmatic Version Control with Subversion",
which I
have obtained from the publisher and am one chapter from finishing and then
will write up a review. Someone else had asked me at the meeting about
borrowing it, but after him, you could take it, Doug. Sounds like you're in
no hurry, right? :-)
/charlie
http://www.carehart.org/blog/
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Cameron
Childress
Sent: Sunday, August 06, 2006 4:00 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Change Management Options Debate.
On 8/6/06, Douglas Knudsen <
[EMAIL PROTECTED]> wrote:
> righto. So, in a team of 10 developers that don't seem to run
into
> these 'issues' in CVS that SVN solves, it doesn't seem very economical
> to go through changing, eh?
All things held equal, I'm always a proponent of using the tools your team
is most familiar and proficient at. If there aren't any compelling
reasons
for you to change, then don't.
It's just like the age old CF vs [insert other language here]
argument. No
reason to change horses midstream if both horses get you there just fine,
and the development teams know one better than the other. If it
ain't
broke, don't fix it.
I would, however, thoroughly explore the differences and advantages of one
over the other before dismissing it. Once that due diligence is
over, make
the educated decision.
-Cameron
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @
http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
