I had one CVS repository located in a remote location, which CVS can access via these environment variables:
export CVSROOT=:ext:xyz#abc.com:/home/xyz/cvsroot
export CVS_RSH=ssh
export CVS_SERVER=cvs
Recently I added another server which has a different location and a different repository. I tried adding the location via
export CVSROOT=$CVSROOT:ext:xyz#fgh.com:/cvs/cvsroot
However, I am unable to perform operations such as checkout and update with the following error:
Cannot access /home/xyz/cvsroot:xyz#fgh.com:/cvs/cvsroot
No such file or directory
What am I doing wrong?
When you are in a CVS repository, any cvs operations will take its CVSROOT information from the current directory's CVS/Root file, regardless of what any CVSROOT environment variables are there. So your only issue is how to initially checkout from your different repositories.
When you type export CVSROOT=$CVSROOT:ext:xyz#fgh.com:/cvs/cvsroot that says "change the CVSROOT environment variable to be the old variable with ':ext:xyz#fgh.com:/cvs/cvsroot' appended to the end if it. That's likely not what you want. You need to take the $CVSROOT out of the right hand side.
As a workable workflow, you can either
run cvs -d <newcvsroot> co <reponame> to specify each CVSROOT as you do your cvs co (you may need to unset CVS_RSH as well, I don't know about that), or
you could also export CVSROOT=<newcvsroot>; unset CVS_RSH; cvs co <reponame>.
If you're frequently checking out from multiple repositories, you may want to have environment variables set up like this, and then you can easily check out from each repo. (Add repos as necessary.)
# in your .bashrc or someting
export REPO1ROOT=:ext:xyz#fgh.com:/cvs/cvsroot
export REPO2ROOT=:ext:xyz#abc.com:/home/xyz/cvsroot
export CVSROOT=$REPO1ROOT # default
# when you use the command line
cvs co repo1
cvs -d $REPO2ROOT co repo2
Related
It is possible to track one file, but discard changes to it:
git update-index --assume-unchanged <file>
But this is local setting.
How can I make this visible to my team members, without forcing them to locally do the git update-index --assume-unchanged dance?
The answer is that you can't. Git doesn't support doing this and using git update-index --assume-unchanged for this purpose is not a supported use of that feature.
If you have a config file or other file that needs to change depending on the user or system, then check in a template and generate it as part of a local build step. For example, GitHub uses templating and a set of scripts to set up local configuration in a project-independent way.
I'm exporting a file in one folder and moving it to production without performing an change, using this command:
svn export --username user --password passwd --non-interactive --force svn://svnserver.com/trunk/patch/115/sql/TestFile.sql
After the movement I would like to add a comment/tag that file was moved successfully. For this, I tried the commands below but they didn't work:
> svn commit -m " Test" TestFile.sql
svn: '/home//SVNTEST/1' is not a working copy
> svn commit -m "Test" svn://svnserver.com/trunk/patch/115/sql/TestFile.sql
svn: Must give local path (not URL) as the target of a commit
Will it be possible if yes how to do so?
To summarize, you're copying a file from the repository to your local machine, then you want to somehow indicate in the repository that this action happened.
Without knowing more about your setup, I think creating a tag is probably the most straightforward way to do this. Use this command:
svn copy svn://svnserver.com/trunk/ svn://svnserver.com/tags/115 -m "Test"
Use whatever unique key for the tag name (here I used '115' since it seemed like that was a patch identifier).
Let's discuss why the commands you tried did not work.
Since you're exporting rather than checking out the file, you don't have a working copy. Exporting is basically equivalent to downloading a file from an HTTP or FTP server; there are no strings attached.
Now, the subcommand commit requires a working copy (in order to know where in the repository to put your local changes), which explains why in the first command you tried the error indicated you aren't in a working copy. The second command errored because you (I think) are trying to tell SVN the remote location to upload your local TestFile.sql, which is not a valid use-case for the commit subcommand.
My suggestion creates a tag, but does so entirely on the server which means you don't need a working copy.
We are using Gitosis in our Linux OS server to manage our projects. One time, I mistakenly pushed the config file which contains errors and then I wasn't able to push changes or clone copies of other projects from the server anymore, including gitosis-admin itself. Now, I need to login to the server using the root user and edit the config file there.
So, when I logged on to the server I saw these files:
Then I cd into gitosis-admin:
Then I cd again into gitosis-admin:
Then I vim the config file. This is what I see:
The content is obviously not what I am expecting, because I should have other repos listed in this config file.
I also double checked with git reflog to see the commit history:
Then I thought there might be another gitosis-admin located somewhere else so I search using the command: find / -type d -name 'gitosis-admin'
This is what I got:
The two directories are the ones that I checked. And they do not match the one I have in my local computer.
I tried searching for one of our projects but still I got no result at all.
Then I thought that the root might not have access to the repo files so I switched to the git user by executing the following command:
sudo git
But still, I can't find the directory of the repos.
So now, I need to know where are the repos located so that I might find the "real" gitosis-admin there.
You might be wondering am I checking on the wrong server here. So to prove that I am not mistaken, this is a screenshot of the host address that I am connected to:
This is the remote address of the gitosis-admin git repo shown in source tree:
A typical directory would be the repositories sub-directory of the git user's $HOME directory, that is
~git/repositories
It is possible to change this location using the repositories key of the gitosis section in the configuration file, which typically is a file named .gitosis.conf in the git user's home directory.
To answer the implied question (namely which file to fix to restore gitosis access), that would be ~git/.gitosis.conf as well.
(This is all documented in the gitosis repository's readme file.)
I have several git repositories. One of these is in $PATH. Today, I accidentally moved to a directory that I thought had a git repository, but did not have one.
cd <another_directory_without_.git>.
So, when I entered git status, the output was confusing.
It appears git found the repository in $PATH, so in this case, git found the repository in ~/bin, which is in my PATH.
Does git search for repositories by looking in $PATH, or is there another search mechanism at work?
I can't find a definitive reference for the actual details, but we can infer most of it from the documentation to the git repository variables.
Git looks for its a repository, by order of preference:
in a directory provided by the --git-dir argument
in a directory provided by the GIT_DIR environment variable
in subdirectory .git or the current directory
in subdirectory .git of an ancestor directory. Environment variables GIT_CEILING_DIRECTORIES and GIT_DISCOVERY_ACROSS_FILESYSTEMS set a few constraints on that.
According to the git(1) manual page, Git goes like this when it looks for its object store:
If the "--git-dir" command-line option was specified its value is used to locate the repository.
If the GIT_DIR environment variable is available and set its value is used to locate the repository.
Note that in both of these cases no search/heuristics is done.
Otherwise Git tries to figure out if the current directory is the repository — in case it's a bare repository which has no work tree.
The logic it uses to carry out this task is explained here. To cite it:
Test if it looks like we're at a git directory.
We want to see:
- either an objects/ directory _or_ the proper
GIT_OBJECT_DIRECTORY environment variable
- a refs/ directory
- either a HEAD symlink or a HEAD file that is formatted as
a proper "ref:", or a regular file HEAD that has a properly
formatted sha1 object name.
Failing that, Git tries to find a directory named ".git" in the current directory.
If it succeeds, it uses the test from the previous step to verify if it's really what it was looking for.
If it fails, it ascends one level up — to the parent directory and tries again.
The last two steps are carried out until / on POSIX-like systems or the root of the drive — on Windows is hit (and hence there's nothing to ascent). By default, Git also won't cross the boundary of a filesystem of the current directory.
As you can see, no $PATH is involved: this directory is used only to look up executable programs, and Git has no business with it.
I'm trying to use CVS on my linux machine for the first time for a project, and I keep hitting my head against the same brick wall.
I have created a projects directory as /home/myuser/cvsproject
I then set the environment variable for CVS as:
export CVSROOT=/home/myuser/cvsproject
I then ran the initialize for CVS as: cvs init
This created the CVSROOT folder under my projects directory.
I then created a lower level project directory, as /home/myuser/cvsproject/project1
I added these project details in the modules file at the end as
project1 project1
I am now trying to add a new file to the repository with cvs add project1/filename.txt but I get the following error:
cvs add: in directory project1:
cvs [add aborted]: there is no version here; do 'cvs checkout' first
The file is in my current directory, located in /home/myuser/cvsproject/
If I try to add the file without the project1 prefix: cvs add filename.txt I get the same error still.
I am able to check out a file in the CVSROOT directory, i.e.
cvs checkout CVSROOT/modules so CVS is definitely working.
I appreciate any help. Thanks
CVS is not decentralised, you shouldn't make your project directory the root of CVS repository. Set CVSROOT to different place where your repository will reside (that is not the same place as your project's working directory - it should be some place new, where CVS will create its structure), then add or import everything you need (don't forget to commit). If you want another working copy, you should checkout from the same CVSROOT.