[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: How well does CVS handle other types of data?
From: |
Thornley, David |
Subject: |
RE: How well does CVS handle other types of data? |
Date: |
Thu, 12 Jul 2001 16:53:53 -0500 |
> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Sent: Thursday, July 12, 2001 3:24 PM
> [ On Thursday, July 12, 2001 at 09:38:17 (-0500), Thornley,
> David wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> >
> > > Learn to separate your unmergable files form your other stuff
> > > and build
> > > procedures and processes to bring them together only at
> build time!
> > >
> > Why? What do I get out of this that I don't get by keeping the
> > binary source files with the text source files and use CVS on both
> > of them? What does it buy me?
>
> "Doctor! Doctor! It hurts when I bang my head against the wall!"
>
> Well stop banging your head against the wall!!!!!
>
Except that I'm not banging my head against the wall, and it doesn't
hurt. I don't know about the rest of you, but I'm not having problems
with the way CVS manages the stuff I work with, which does include
some binaries.
> If you keep your binaries and your sources separate you won't
> have this
> problem in the first place!!!!!
>
What problem? You've claimed that putting binaries into CVS is bad,
and now you're claiming that I've got a problem with it. I'm happy
with CVS. I wish it could handle unmergeable data as well as it
handles mergeable, but that isn't possible, so I'm (a) not considering
it a problem, and (b) not going to buy that keeping these apart is
going to solve any problem I may have.
> > You've accused me in another post of not being able to see
> a screwdriver
> > because there's a hammer in my hand. I've asked what a
> screwdriver is,
> > and where to get one, and so far I've got a piece of metal
> I can pound
> > into something almost as useful to drive in screws as the claw of my
> > hammer. If you'd show me something better, like a piece of
> metal I could
> > pound into a better screwdriver than I've got, I'm very
> willing to learn.
>
> I did show you something better. Several things in fact!
> Here's one of
> the alternatives, AGAIN:
>
> Keep and manage your binaries separately from your source
> code. Create
> a build system that pulls the various components together as desired.
>
Why, in the name of Babbage, is that supposed to be better? I still
can't automatically merge binaries, so it's no advantage there. So
what do I get if I do that?
1. I get to maintain two version control systems in parallel.
2. I get to maintain a more complicated build system.
3. I get to try to keep the CVS stuff and the other stuff correctly
aligned.
What I don't get is an easier way of managing binary files.
> That's the easiest solution. It's so easy it's child's play -- brain
> dead simple. There literally can't be anything simpler.
>
You know what's easier than CVS? Just keep all your source files in
a directory tree, and let everybody change them as they need. Child's
play; there can't be anything simpler. Personally, I don't want to
do that, but your needs may differ.
However, I think you're wrong. I have a simpler thing to do than manage
text-based sources in CVS and binary sources in another directory with
a more complicated build system: I can put them all in CVS! As long
as I make sure the -kb goes on (and this has not been a problem in my
shop), it's even simpler than hacking the build system.
> When you have a problem managing disparate types of data, don't manage
> them the same way!!!!!
>
What's the problem? And why is using one management technique worse than
using two different techniques if the more complex process doesn't do
anything more?
> > Right. This is the point that you completely miss. If you
> are going to
> > tell me not to use a particular tool for a particular task,
> you need to
> > show me either that that tool doesn't work for that task,
> or that there
> > is a better tool. You haven't done either.
>
> BUT THAT WASN'T THE POINT! THE POINT WAS THAT YOU WANT THE
> IMPOSSIBLE!!!!
>
Or at least I want some things my wife would object to (she doesn't
want me buying more books).
Anyway, what I want for source code management here is to use something
like CVS without people telling me I'm doing something wrong.
> The point of saying you can't see the screwdriver because you've got a
> hammer in your hand is that you aren't thinking outside the box and
> you're failing to see how to separate your problems out into managable
> subdomains.
>
No, I'm failing to see *why* to separate my problems (such as they are)
out into subdomains less manageable than the single domain.
> You're still seeing CVS as the only tool in your toolbox. It
> MUST NOT BE!!!!
>
I have lots of tools. I have language software, editing software, mail
software, and that's just Emacs. I've got a lot of tools besides Emacs
and CVS also. I just don't see why I am expected to use a hammer for
some nails and a rock for others.
- RE: How well does CVS handle other types of data?, (continued)
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/12
- RE: How well does CVS handle other types of data?, Paul Sander, 2001/07/13
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/13
- RE: How well does CVS handle other types of data?, Paul Sander, 2001/07/13
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/13
- RE: How well does CVS handle other types of data?, Paul Sander, 2001/07/14
- RE: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/14
- Re: How well does CVS handle other types of data?, Paul Sander, 2001/07/12
- Re: How well does CVS handle other types of data?, Greg A. Woods, 2001/07/12
- Re: How well does CVS handle other types of data?, Paul Sander, 2001/07/13
RE: How well does CVS handle other types of data?,
Thornley, David <=
RE: How well does CVS handle other types of data?, Noel L Yap, 2001/07/12
RE: How well does CVS handle other types of data?, Cameron, Steve, 2001/07/13