«

Hi,

we are a group of four software developers working on a single Java project.
We are going to use CVS (client: Eclipse).

I used CVS before but I was never sure which files to upload and which not.
Source files are clear to me, but what's about property-files or libraries
(jar's)? Do you upload them alltogether in your CVS-server?

Just wanted to here your (best) practices and if there are any good
guidelines to hold on.

Thank you very much in advance.

greetings, Hubert
--


----------------------------------------------------
This mailbox protected from junk email by Matador
from MailFrontier, Inc. http://info.mailfrontier.com

: I used CVS before but I was never sure which files to upload and which not.
: Source files are clear to me, but what's about property-files or libraries
: (jar's)? Do you upload them alltogether in your CVS-server?

Don't put binaries in CVS, its no good with them. It can handle them
but its some extra work for each binary file....

Store source, config files and language files in CVS, have the
Makefile/build.xml produce the jar files. Download needed 3:rd party
jars/libs from the file server.

/robo

"Hubert Grininger" <> wrote in message
news:...
> Hi,
>
> we are a group of four software developers working on a single Java
project.
> We are going to use CVS (client: Eclipse).
>
> I used CVS before but I was never sure which files to upload and which
not.
> Source files are clear to me, but what's about property-files or libraries
> (jar's)? Do you upload them alltogether in your CVS-server?
>
> Just wanted to here your (best) practices and if there are any good
> guidelines to hold on.
>
> Thank you very much in advance.
>
> greetings, Hubert
> --

For what it's worth:

My preference is to put everything necessary to produce a build into the
repository. I'd put property files, libraries and .jars in there, but would
stop short of executibles like javac.

Conceptually, you want to be able to:

1) build your development environment: OS and basic toolset (such as javac
and cvs client)
2) pull your repository
3) execute a single script (maybe after making some configuration changes),
which should produce a releaseable (or deployable) product.


If the libraries aren't part of the repository, then they are necessarily
part of the development environment, and you may end up with a messy
versioning problem. How does one solve versioning problems? Use a version
control system like CVS!


CVS can store binaries, but it isn't very efficient about it (a complete
copy of each version is stored), and you can't do branch-and-merge
operations on them.

But this shouldn't be a problem; when a new version of a library is
released, you commit the updated version to the repository, and you're done.


-- Adam Maass

thanks for your answers!

hubert