info-cvs
[Top][All Lists]
Advanced

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

Re: CVS corrupts binary files ...


From: Tom Copeland
Subject: Re: CVS corrupts binary files ...
Date: Fri, 18 Jun 2004 11:38:00 -0400

On Thu, 2004-06-17 at 18:16, Greg A. Woods wrote:
> > 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)

Yup, Ant.

> 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.

I think this might be a difference in the way Java apps do
dependencies.  

I certainly agree that if I write, say, a C++ app that manages a
PostgreSQL database, I won't ship PostgreSQL along with my app.  I'll
assume the user has it on there already, and the other guys who are
developing with me will install PostgreSQL on their machines as well.

But if I have two Java applications, each of which uses, say,
JFreeChart, I expect each of them to come with a lib/ directory that has
the version of JFreeChart they expect to use.  There just isn't a Java
standard - that I'm aware of - that expects Java jar files to go in
/usr/lib or whereever.  It's just not the done thing.  So keeping 3rd
party dependencies (i.e., a single jar file) in the repo is std
practice.

You've got a good point though - why aren't Java apps installed in a
well-known location in the filesystem like everything else?  Dunno.

Yours,

Tom





reply via email to

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