Any good arguments in print to refute the thought?
A CMS system provides far more than backup for the source code. In
fact, that's probably the least important function it serves. It's
primary roll is to manage change. Backups can't tell you who
submitted what changes when or for what purpose. If your SDLC process
never references old code for any reason and never uses it to provide
information about the change of your software than you have far bigger
problems than a manager who apparently doesn't understand the business
he manages :-)
Jeff
Exactly. rm, ask your manager how he would handle the
following real-life situation we encountered earlier
this week:
An application enhancement was mothballed some months
ago, by users who decided it wasn't needed just yet.
The developer who worked on it last is neck deep
in a large rollout of a major application.
Business users discovered this week that they not only
need the functionality they postponed implementing,
they kinda need it today! With a revision control system,
I could search for the specific version, as well as
rapidly diff against the history of changes, to answer
questions on what the code does, why, and how, that
otherwise would have required pulling the original guy
off the big rollout and delaying that.
Then I could rapidly merge his code into the application
code base, generate a checkpointed version, unit and
regression test that (NUnit helps, too!), and send it
out to QA by early afternoon.
Accomplished in about 4 hours what would take -days or
weeks- of screwing around with backup tapes in your
bosses scenario.
Just one of several dozen examples each week in our
team.
Well some time it is just mater of educating the manager.
So far my assumption is he / she "understand" backing up the source
control repository is a very important task. "one can just hope"
Why should you back up source control ? Source control's big value as
Jeff mentioned is its capabilities to show attributes, history and
delta changes happen through the life of developing the code. The
mechanizes of storing this information is in the format of a
"database".
Since all of the informations are collected in a database you have to
treat the backup of this data the same way as you treat the database
backup.
1) lock the database
2) take a snap shot image of the data
3) backup the data.
If we just simply backup the flat file, when time come to restore the
data, we do not have a correct picture of how to retrieve this data
from database.
> Any good arguments in print to refute the thought?
I'm very disturbed to read that there is someone out there, who has
worked his way up to be a "manager", who is not aware of SCM. More
scarily, this "manager" has not stopped to ask himself "SCM products
appear to be useless. So why do people willingly pay $thousands per seat
for Clearcase and friends ?"
SCM is plainly necessary if you want to track the history of a project
based on the changes that went into the code base, or if you want to be
able to successfully manage merging between code lines. It's very hard
to explain this to someone who has never seen this in action, a bit like
trying to explain a web browser to someone who does not know what a
computer is.
rm wrote:
Any good arguments in print to refute the thought?I'm very disturbed to read that there is someone out there, who has worked his way up to be a "manager", who is not aware of SCM. More scarily, this "manager" has not stopped to ask himself "SCM products appear to be useless. So why do people willingly pay $thousands per seat for Clearcase and friends ?"
Well, I'm not sure we know the full picture.
The poster talked about "being able to restore an application from our
[version control]". If that means "grabbing binaries commited at
LATEST/HEAD in the repository and copying them over", restoring from
backup is at least as good a solution.
That you use a version control tool doesn't imply that you actually
have more than a primitive backup system. A manager who understands
that is a good manager.
(This is /one/ possible interpretation of the posting -- I'm not
saying it's the correct one!)
> SCM is plainly necessary if you want to track the history of a project
> based on the changes that went into the code base, or if you want to be
> able to successfully manage merging between code lines. It's very hard
> to explain this to someone who has never seen this in action
Yes, the benefits of SCM working well are notoriously hard to explain.
And you can think that you "get it" and yet you only see the tip of
the iceberg.
/Jörgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
It's not bad to have such 'the emperor is naked' questions now and
then.
What it shows first is that we (as a community) do not seem to resort
to any kind of SCM to manage this kind of breakdown, and the replies
that were made previously.
I mean of course that this is a FAQ, so where is the answer?
I don't really have one either. Maybe I'd start from:
http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/YaScmManifesto
but the truth is that there are in fact:
- far too many
http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/SoftwareConfigurationManagement
- with a lack of agreement
- and a lack of acknowledgement about this
In short: there is no FAQ, because the issue of what is SCM is not so
simple as to call for one universal answer.
OK, and now a simple reply:
- bringing back yesterday's tapes means throwing away what else has
been done since.
If this is safely OK for you, you are doing so simple things that it
is
unlikely that they'll fit in today software market.
Marc
[snip]
> OK, and now a simple reply:
> - bringing back yesterday's tapes means throwing away what else has
> been done since.
But it doesn't; you normally restore to a separate area,
and from there you can merrily do diffs, merges etc,
without a need for a more integrated SCM solution.
I'm not arguing that simply using backups is good enough
for SCM; it's relevant only to small facets. However,
you can certainly do better with backups than "throwing
away what else has been done since", though often at a
considerable cost in terms of time spent (and SCM tools
often take a lot of that too).
-- James
> But it doesn't; you normally restore to a separate area,
> and from there you can merrily do diffs, merges etc,
> without a need for a more integrated SCM solution.
Point taken. I anticipated this argument in:
http://www.cmcrossroads.com/cgi-bin/cmwiki/view/CM/WhyNotJustUseTapeBackups
Roughly, as you told it yourself, it won't scale.
The SCM should offer you an immediate solution
(e.g. changing a label in your config spec).
No time should be spent, or it is indeed an issue.
Marc
Backups just about supply the version control and the baselining. But
how about the management? It is called configugation Management?
Restoring history is only part of CM. For example how does he manage
the flow of developers work through integration and from there on into
delivery to test?