[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS corrupts binary files ...

From: Doug Lee
Subject: Re: CVS corrupts binary files ...
Date: Thu, 17 Jun 2004 19:47:07 -0400
User-agent: Mutt/1.5.4i

Responding above rather than below largely because my comments are
general thoughts on the whole discussion...

There is wisdom in choosing the right tool for a job.  There is also
wisdom in making the best use of the tools you already know and have.
Both can be taken to unpleasant extremes.  I believe both extremes can
be "wrong" (from a functional standpoint).

The fact that CVS was designed for mergeable data means it should be
good at that.  It does not mean it absolutely cannot serve further
useful purposes.  Those who want to use CVS for further purposes would
be well advised to know just what CVS is and is not capable of doing
(note this is not the same as what it was originally designed for, but
rather is what it happens to be able to do reliably).

So for the job of managing versions of mergeable files, CVS bills
itself as ready, and it should do well.  For the job of managing
unmergeable files, it sounds to me like it can, regardless of original
intent, as long as you don't go trying impossible stuff.  For the job
of managing distribution of file sets among workstations (which may be
on a LAN or across a VPN connection or an ssh connection or whatever
but which do not necessarily have access to a central file location),
I find CVS reasonable.

And may I humbly suggest that, for the job of pursuading the unwashed
masses such as myself of the pitfalls and folly of using CVS for
further purposes than concurrent versioning, information might be a
better tool than inflamation. :-)  (Specifically to Greg:  The latest
post I saw from you, the one more precisely describing how one might
lay out binary files in directories, manage them with a
version-controlled config file, etc., has made me think more about
this than any other post to date.)

On Thu, Jun 17, 2004 at 06:16:32PM -0400, Greg A. Woods wrote:
> [ On Thursday, June 17, 2004 at 16:25:02 (-0400), Tom Copeland wrote: ]
> > Subject: Re: CVS corrupts binary files ...
> >
> > Hm.  Why not simply check these jar files into the repository where they
> > can be tagged/branched/exported and so forth?  Why should every
> > programmer on my team need to get all the versions of each jar file laid
> > out on his machine when he could just do a "cvs up" to get the current
> > stuff for his branch?
> Don't you have a build system?  (apparently you do going by your later
> comments)
> Can't it do all those things for you?
> Let me repeat:  CVS is _not_ a build system.
> Just because you can use CVS to update version-controlled files from
> some central repository doesn't mean you should try to use CVS to copy
> all types of files from all kinds of repositories.
> If you have many and diverse build machines then put your static
> (i.e. non-changing) components on a central machine in a public
> directory and have your build system invoke the appropriate tool to copy
> them into the build environment as necessary.  If you do that, and if
> the way you reference those components includes information about their
> version numbers (e.g. in the name of the directory they're "installed"
> in), and if your build system is configured using normal source files
> (e.g. text makefiles) that you commit to your CVS repository, then CVS
> will track which version of which component is needed for every release.
> -- 
>                                               Greg A. Woods
> +1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
> Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>
> _______________________________________________
> Info-cvs mailing list
> address@hidden

Doug Lee           address@hidden
Bartimaeus Group   address@hidden
"Our chief want in life is somebody who will make us do what
we can. {Ralph Waldo Emerson}

reply via email to

[Prev in Thread] Current Thread [Next in Thread]