File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes IDEs, Version Control and other tools and the fly likes cvs_root Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "cvs_root" Watch "cvs_root" New topic
Author

cvs_root

jay vas
Ranch Hand

Joined: Aug 30, 2005
Posts: 407
Hi guys : I've never quite understood why CVS_ROOT is so commonly used, given the fact that CVS can take a directory as an option.
I have a build process that requires CVS_ROOT to be set.... But I don't want to have to set a "single" root, because I have other build repositories for other projects with other companies.

Is there a way to specify multiple CVS_ROOT repositories, or to "proxy" the CVS_ROOT references made by tools such as maven ?
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

Is there a way to specify multiple CVS_ROOT repositories, or to "proxy" the CVS_ROOT references made by tools such as maven ?

Yes. For example, The "cvs" Ant task allows you to specify the root.


[My Blog]
All roads lead to JavaRanch
jay vas
Ranch Hand

Joined: Aug 30, 2005
Posts: 407
My problem is that the build process actually requires that CVS_ROOT be set ... It looks to the machine path...

My real question is : why is CVS_ROOT so commonly set as an an environmental variable to begin with? It's not well suited as an environmental variable, because it really has nothing to do with a users machine, but rather, it is simply an input to a program....
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

Many programs use their own environment variables. Like JAVA_HOME and CLASSPATH for Java. These can usually be overridden either by using command line parameters, application settings, or by making a batch file overriding the variable value.
jay vas
Ranch Hand

Joined: Aug 30, 2005
Posts: 407
Yes, but JAVA_HOME and Classpath are different.

1) They both describe a paths which reference a local machine and
2) There is no conventional reason why someone would want to have two different classpaths or two different JAVA_HOME locations.

In contrast , CVS_ROOT is a hard link to a file path on an (often) external mahine, and it is quite conventional for CVS developers to deal with different root repositories... Especially in today's open source climate.

The most problematic aspect of it, to me , is the fact that build procedures which would conventionally work just fine if given an external argument specifying CVS_ROOT, often call for users to "set" their CVS_ROOT in their global environment variables .

It seems to me that the purpose of enviornment variables is to allow one, global location for a peice of information which might be accessed by multiple programs. $JAVA_HOME,$SHELL,$LANG, and $HOME all conform quite nicely to that category.... $CVS_ROOT does not.
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

jay vas wrote:2) There is no conventional reason why someone would want to have two different classpaths or two different JAVA_HOME locations.

I have three different JDK on my machine. I'm adjusting the JAVA_HOME in batch files depending on the JDK I want to use.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

Christophe Verré wrote:
jay vas wrote:2) There is no conventional reason why someone would want to have two different classpaths or two different JAVA_HOME locations.

I have three different JDK on my machine. I'm adjusting the JAVA_HOME in batch files depending on the JDK I want to use.

Only 3? I have 5 on my machine.

jay vas wrote:Yes, but JAVA_HOME and Classpath are different.
1) They both describe a paths which reference a local machine and

Although they don't have to. Their common usage dictates that they should be referencing accessible drives (not necessarily local).

It is also quite common for classpaths to differ depending on the application being run. The classpath for Tomcat could be quite different than the classpath for Glassfish (to give one example - I could give more).

In addition, they are just variables. They could contain anything at all. (although there would be little value in that).

jay vas wrote:2) There is no conventional reason why someone would want to have two different classpaths or two different JAVA_HOME locations.

Apart from developers requirements, it is common for software suppliers to specify "certified" environments for their software. In such cases, it is not unusual for system administrators to have multiple JVMs, multiple containers, ... to run the appropriate software.

jay vas wrote:In contrast , CVS_ROOT is a hard link to a file path on an (often) external mahine, and it is quite conventional for CVS developers to deal with different root repositories... Especially in today's open source climate.

<pedantic mode>in today's open source climate you are far more likely to encounter Git repositories, or stepping back a notch, SubVersion repositories. It is rare to see CVS still in use in open source.</pedantic mode>

jay vas wrote:The most problematic aspect of it, to me , is the fact that build procedures which would conventionally work just fine if given an external argument specifying CVS_ROOT, often call for users to "set" their CVS_ROOT in their global environment variables .

You asked in your very first post in this topic whether there was a way for the CVS_ROOT to be set in tools such as Maven. Christophe gave you an example with ant. In Maven you can use the (deprecated) maven.scm.cvs.root definition for fine grained control.

jay vas wrote:It seems to me that the purpose of enviornment variables is to allow one, global location for a peice of information which might be accessed by multiple programs. $JAVA_HOME,$SHELL,$LANG, and $HOME all conform quite nicely to that category.... $CVS_ROOT does not.

You haven't mentioned your continuous integration engine. But assuming you are using Hudson Jenkins, then you can use the parameterized build plugin to set the desired CVS_ROOT for each build.

If you are not using a CI engine, then these are all just variables that you can put in any script and source them at any time. So I see no difference between them.


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16019
    
  20

CVS_ROOT is the default repository to be used when logging into CVS. You can easily override it on the CVS command line. And, in fact, I've run CVS without a CVS_ROOT setting at all and only specified it on the command line.

Environment variables typically come in 2 flavors: local and global. In Windows, this factors out to system and user settings. In Unix/Linux, it's typically inherited when a new shell process is spawned (depending on the spawn options). If you run a sub-environment, you can generally override the local CVS_ROOT setting without impacting the other processes, since in both Windows and *n*x, the processes each maintain their own private set of environment variable settings.


Customer surveys are for companies who didn't pay proper attention to begin with.
 
wood burning stoves
 
subject: cvs_root