[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: How well does CVS handle other types of data?
RE: How well does CVS handle other types of data?
Fri, 13 Jul 2001 17:44:45 +1200
I will now try not to raise to the bait when Greg starts forth. I was
raising some hypothetical situations and discussions, not describing our
reuirements. Greg has now told me not to use CVS. We can make our own
decisions thank you and it sounds like one day it wih be Gregs CVS and
everyone else's CVS. Greg, you seem to have moved from following the full
debate to attacking everyone who participates and has a different point of
view. You seem to assume that any hypothetical example people give is their
actual position and then attack it!
According to the original author of CVS, merging was ONE OF SIX advantages
of CVS, not THE advantage!
In summary Greg is saying that if you don't want 'automagic' merging don't
use CVS. Greg says that the -kb code has flaws, but rather than fix them,
get rid of it completely, even though it is part of the RCS framework that
CVS is built on top of!
>From man co:
-kb Generate a binary image of the old keyword string.
This acts like -ko, except it performs all working file
input and output in binary mode. This makes little
difference on Posix and Unix hosts, but on DOS-like
hosts one should use rcs -i -kb to initialize an RCS
file intended to be used for binary files. Also, on
all hosts, rcsmerge(1) normally refuses to merge files
when -kb is in effect.
That's all from me. Good evening from your future, it will be a beautiful
day on Friday (well it was here):)!
Chris Cameron Open Telecommunications Ltd
Product Manager IN Product Management
address@hidden P.O.Box 10-388
+64 4 495 8403 (DDI) The Terrace
fax: +64 4 495 8419 Wellington
cell: +64 21 650 680 New Zealand
Life, don't talk to me about life ....(Marvin - HHGTTG)
> -----Original Message-----
> From: Greg A. Woods [mailto:address@hidden
> Sent: Friday, 13 July 2001 4:51 p.m.
> To: Chris Cameron
> Cc: CVS-II Discussion Mailing List
> Subject: RE: How well does CVS handle other types of data?
> [ On Friday, July 13, 2001 at 13:50:34 (+1200), Chris Cameron wrote: ]
> > Subject: RE: How well does CVS handle other types of data?
> > We need:
> > 1. Ability to recreate a particular contour of file versions
> > 2. Ability to work across multiple directories
> Good. If that's all of your requirements then please go find something
> else to use other than CVS. I'm sure there are many other tools that
> fill those requirements. I've written some shell scripts for SCCS that
> might even fill the bill for you. You can find them on my FTP site in
> dotfiles.tar.* (in the enclosed file .kshsccs). I've even been planning
> on fleshing them out to include more CVS-like features and will be happy
> to do so under your explicit directions, for a small fee of course.
> CVS does more than you need and some of what it does can be orthogonal
> to your needs and may therefore cause you problems if you try to use it
> for only those two purposes and without taking into account its
> > Greg suggests that people write their own tool to do this, however CVS
> > (which is written on top of RCS, so how can it be good for
> binaries on it's
> > own, but not underneath CVS) can already do this.
> If this isn't clear by now then you have a fundamentally flawed
> understanding of how CVS works and what features it provides (and which
> it _explicitly_ does not provide, not to mention those it _implicitly_
> does not provide).
> > CVS also allows you to merge text files. For some binary files
> a merge can
> > be managed (e.g. word or framemaker documents), for others
> (e.g. gifs) it
> > does not make any sense. Is merging of text files important? In Greg's
> > world it is, in other peoples eyes it isn't.
> Anyone and everyone who uses CVS as it is intended to be used must
> believe that merging of text files is critically imporant to their use
> of CVS! You don't even have to know what a branch is to still need
> merging to work if you use CVS.
> You're trying so hard now that you've not only bent the truth beyond
> recognition, you're now torturing it to death!
> > Now whenever I've been involved in product decisions, we've listed our
> > requirements, prioritised them and then listed our requirements
> that each
> > product supports. Usually no product meets all our
> requirements so it is a
> > matter of determining which product best meets our top requirements. As
> > merging probably doesn't fit in anyones requirement list for graphical
> > files, merging and patches are 'extras' from CVS, not a 'wrong tool'
> > decision.
> If you want to go off and write something that meets your needs, then
> please do so.
> In the meantime please try to at least accept the fact that CVS might
> actually be at odds with your needs (besides providing features for
> fulfilling some of them). A tool that's at odds with even one of your
> (unstated) requirements, even though it might perfectly fill all the
> others, is still the wrong tool. You won't succeed by doing an
> incomplete requirements analysis, and you won't succeed by throwing out
> requirements to which there's no solution.
> Greg A. Woods
> +1 416 218-0098 VE3TCP <address@hidden> <address@hidden>
> Planix, Inc. <address@hidden>; Secrets of the Weird <address@hidden>
RE: How well does CVS handle other types of data?, Thornley, David, 2001/07/12
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
RE: How well does CVS handle other types of data?, Thornley, David, 2001/07/13
RE: How well does CVS handle other types of data?, Noel L Yap, 2001/07/13