Re: Thoughts on choosing a source code control system?
Re: Thoughts on choosing a source code control system?
- Subject: Re: Thoughts on choosing a source code control system?
- From: Ian Joyner <email@hidden>
- Date: Mon, 13 Mar 2006 13:25:33 +1100
That's probably my problem with SCS systems – there is an important
function there of coordinating multiple people and being able to
review patches before they are integrated into the next version of
system and also being able to use an SCS as a multi-level undo so
that a single patch (which may include many lines in many different
parts of code) can be undone or reapplied.
I can't say that I've seen anything that does this simply, easily,
and effectively (except Burroughs' PatchManager, which was integrated
with a fantastic editor which was able to load multiple patches
against the software for review to detect conflicts, but Burroughs
was a company (still is in the A Series line) that had small and
effective development teams, rather than the IBM/MS approach of
throwing hundreds of developers on a project. They also had a very
disciplined Design Review process, and my experience was with a very
ignorant process and quality manager who knew nothing about this, who
thought they were going to reform the whole company and teach those
guys in the US a lesson on how to do it right, by adopting they usual
industry flavour-of-the-month tools, so hence my caution).
Maybe one day I'll get to look at subversion when I get the current
software into a more finished state, but do not want to slow
development to a glacial pace (which is good when you are enhancing
products already there), that often results from SCSs. Having looked
at some of this stuff, though I don't want to spend time on solving
bugs in SVS and having to learn an extra layer of complexity (Xcode
is bad enough, and I'd like something that makes life in Xcode
simpler not harder, like it's there, it works, and I hardly notice it
at all).
Too often, we put the cart before the horse in software development
and these tools become more important than the software structure,
from which they should arise.
Ian
On 13/03/2006, at 12:49 PM, email@hidden wrote:
The first couple of years we were in business I mostly worked by
myself (we had other programmers but they each had their own
project). My source code control method was to make a copy of the
source file, with the date appended to the name, before I worked on
it. Other than the occasional time when I forgot to do this, the
method worked fine and served me well. Having all the previous
versions of the file right there came in very handy on more than
one occasion.
However, time marched on and I started working on one website with
several other programmers; we were all doing maintenance work and
so there was no way to prevent people from stepping on each other.
That was when we adopted CVS, because it was the only package we
all knew how to use. Least pain for most gain.
In the beginning our WO projects will be mine alone, so I could
forgo source code control once again, but using it is now part of
my work process and I don't really want to go back to having to
remember to make copies of files. Having it also makes it easier
to transfer only stable code to the live site.
So while I don't dispute your assertion, I think having one is the
right choice for us. Thankfully I am the management (or
damagement, take your pick :) and I get to make the hopefully
informed decisions that others will follow.
janine
On Mar 12, 2006, at 5:08 PM, Ian Joyner wrote:
Now what are your real requirements? I'll throw in another thought
for you – don't bother with an SCS at all! For small companies and
small projects they really are not necessary and add so much
overhead that you almost have to employ an expert to get whichever
one you choose working.
Rather than wasting such resources, the money is better spent on
someone who really understands software structure will get your
class structure right and develop neat programs. Perhaps once that
is right, an SCS might help, but too often the reverse is the case
and an SCS is used to help manage a mess of a software system.
Of course, this comment might start off the real religious war
since the process and methodology people don't like the real truth
to be known that they are really just hiding behind their tools
("the project failed, but don't blame us we did everything right
according to some misguided book"). Since I don't know the real
structure of your company or development team I can't really
comment, but I can only say that SCS systems are not necessarily a
mandatory part of the development process, and it is worth
thinking about, since none of these tools seem to be without their
problems (which you must expend energy and resources to solve).
(Oh yeah and be wary of the marketing pitch of these methodologies
that says you are obviously a hacker if you are not using this or
that tool. They know how to make people feel inferior if they are
not using them and of course can go straight to management, who
will fall for the pitch. Goes back to the SA/SD days and probably
further, but I know even Larry Constantine who wrote the book with
Yourdon woke up to that one and moved on.)
OK, I'm going back to reading "Object-Oriented Software
Construction" now.
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden