Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

cvs_root

 
jay vas
Ranch Hand
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
jay vas
Ranch Hand
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 407
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Pie
Posts: 11944
212
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Tim Holloway
Saloon Keeper
Posts: 18303
56
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic