U was going to put this on the Win Dev
Server.
What work arounds will I encounter?
I can see already that I will probably
have to load Apache to use this.
Is this a command line only tool? No GUI?
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: Steven Ross [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006
2:32 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss]
Change Management Options Debate.
I posted a blog entry
about setting up a fedora box and getting SVN going:
easy stuff... course now I'm liking ubuntu, but the basic commands stay the
same (except you use apt instead of yum) and some config files are in different
places.
http://www.zerium.com/zerium/index.cfm?mode=entry&entry=63467E64-E1E5-119E-19FA55A04B20E4F3
On 8/8/06, Robert Reil <[EMAIL PROTECTED]>
wrote:
Doug:
You did not hijack my thread. I opened it up for debate and I
just stood back and absorbed. It seems that the debate provided a general
consensus of SVN.
I appreciate the candid banter and absorbed a lot from it.
Objective fulfilled!
Thanks again.
thank you Jeremy! As Charlie pointed out, it
would be a good blog post to get consumed.
Robert, we kind of hijakced your thread, but this is some good fudge for your
version control sundae you will be eating!
I made a couple in line comments below.
I'll add one thing I really hate about CVS, you can't export a module from teh
repository to a existing directory where you exported the module
previously. CVS will not overwrite files. This forced us to
checkout working copies on our prod server. No biggie, we are a intranet
only team, but a pain.
DK
On
8/7/06, Jeremy Allen <[EMAIL PROTECTED]>
wrote:
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.
We use tags in CVS for this. Works fine, but certainly doesn't tie in
with the version of a file. This is a interesting concept. This
means a file that was created as teh first file in your tree and never edited
for 5 years still has the version listed at the max of all file versions, eh?
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.
yes, this is a major PITA for sure in CVS. Most clients hide this issue
by 'pruning' empty dirs.
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.
branching and merging is a major PITA, luckily we rarely do it. The team
of 10 here usually works on seperate projects.
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
-------------------------------------------------------------
-------------------------------------------------------------
List
hosted by FusionLink
-------------------------------------------------------------
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
-------------------------------------------------------------
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
-------------------------------------------------------------
--
Steven Ross
web application & interface developer
http://www.zerium.com
[phone] 404-488-4364
-------------------------------------------------------------
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
-------------------------------------------------------------
|