I was trying to synchronize my local git repository to a CVS repository and everything gets synchronized properly, except for the .git folder.
At first, I thought all folders starting with a dot would be ignored, so I tried adding a .test folder and putting mock files in it. To my surprise, it is detected as a new folder, and the files inside of it are listed and ready to be synchronized.
How do I make CVS sync the .git folder? Thank you.
P.S. I use git locally to keep track of individual changes, and CVS for major milestones. They don't have to be linked in any form.
You definitely do not want the .git folder itself to be synced "as is" to your CVS repository.
When using git, the .git folder contains the version information, e.g. the content of all versions of all files in the repository (in a compressed format).
When you are syncing, the information in .git is used to populate the version control information in CVS. But CVS cannot read the information in the .git folder directly.
Syncing content of .git so that it would be visible in CVS would only be confusing (and dangerous if you tried to "sync back" that content to git, overwriting the contents of the .git folder in git).
Related
Using eGit...
When I perform the initial Commit and Push from Eclipse, a new directory appears in the remote repo. Inside that directory is the root of the project directory. It makes a big mess because when someone clones it (again using eGit) the src folder is munged into a name containing then project folder name, which mucks up the package references in the class files.
eGit assumes you don't want an entire git repository for a single workspace project. Doing so would be wasteful and cumbersome for almost anything nontrivial. https://wiki.eclipse.org/EGit/User_Guide#Implications
You also didn't commit the .classpath file, which would have indicated what the source folders were.
The CVS repository in my project has a HEAD code and 8 other branches. The server location mentioned as '/local/cvs/srcjboss' contains only the projects in the HEAD branch.
Is there a physical location on the server where all the branch code can be accessed ? I need the server location for CVS to SVN migration.
If it helps, we are using a linux server
To convert a CVS history to Subversion using cvs2svn, you need filesystem-level access to the data from the central CVS repository. It is not enough to have access to a working copy where the code is checked out. It's not really clear from your question which of these you have under /local/cvs/srcjboss.
A CVS repository is recognizable from its CVSROOT subdirectory and lots of files named like your project files, but with ",v" appended, like maybe "Makefile,v" or "index.html,v" or "build.xml,v". Each of these files contains the entire history (including branches) of the corresponding file from your project, in rcsfile(5) format. The repository probably also contains "Attic" subdirectories that hold the histories of files that are not present in HEAD.
A CVS working copy, on the other hand, contains one particular version of each file (with no ",v" suffix), plus a CVS subdirectory in each of your project directory. A CVS working copy doesn't contain any of the project history.
So is your /local/cvs/srcjboss the CVS repository or is it a working copy?
If you have a working copy and are trying to find the central repository, look in one of the files named CVS/Root. It will tell you the location of the repository from which the working copy was checked out.
I'm working on an Android game with the folder structure:
\bin
\data (contains game graphics)
\libs (libgdx engine jars)
\src
----\com
--------\brand
------------\game
(*.class files)
Foolishly, I created a mercurial repository (hg init) in the \src directory. Thus, if I update any of the graphics (small file sizes), they aren't added to the repo when I commit. My question is: how can I change the root of the repo to include the \data directory as well as the \src directory, but without including the \libs directory as that includes 10-20mb jars?
There are two ways to do this.
1) Start a new repo. It's quick and easy but you'll lose your history.
2) Use hg rename. This is effectively a move command.
Rename the src directory to be something meaningful and then do this.
hg rename MyProject/com MyProject/src/com
Copy all the files/folders into the MyProject/ directory.
Mark bin and libs as ignorable and
Add everything else.
hg commit
If you don't want to just do an hg rename, you can do it with the convert extension (which comes by default with Mercurial, you just need to enable it in your .hgrc).
Run it with the --filemap parameter and a filemap file that has something like:
rename com src/com
You will end up with a new repository with all of your history, but with your com directory moved into src/com. You can then copy you bin, data and libs folders in there, run hg addremove and you should be all good to go.
Warning: the new repo is completely different than the old one -- changeset IDs and such will be different, so anybody you worked with in the past will have to get on the new repo.
I just installed eGit plugin and I'm playing around with it. I'm new to Git.
I've noticed something strange:
I committed sample project "Planets" then I modified one file only Planet.java.
Then I looked in the Git repository folder, and this modified file Planet.java is there, but none of my other source files are.
Does this mean if I delete my original project folder from the disk, it will break Git? I mean will I not be able to restore any previous committed version of this project anymore?
The "original project folder" is your Git repository. Git only exists* within the directory where you performed a git init. Its metadata about your files is stored within a hidden .git directory inside your project directory. If you delete your project directory, you're deleting your local copy of the Git repository.
*Assuming you haven't explicitly cloned your repository
Issue
After importing an Eclipse project from a cloned git repository, I make some changes and commit - and wtf? I get a ".git" folder added to the project, the whole shebang with the heads and refs and worst of all the whole object database gets added to the project, all files/folders having that little question-mark icon signaling that the files have not been added / are not yet tracked by git. This .git folder exists in the actual Working Directory (how does that even make sense?). You can imagine what an annoyance this causes when trying to use the "Synchronize" tool/view (which is supposed to make life easier for committing, you can see all the changes and changed files and diffs).
Question (tl;dr)
How to correctly import an Eclipse project from a cloned git repository? I don't want a .git folder showing up in "Team > Synchronize" when I commit, let the .git folder reside somewhere else outside of my project.
Additional Info
I'm on Windows 7 using Eclipse Indigo and Egit.
I am using Egit to clone a git repo from http://git.apache.org/ (the ofbiz project, to be exact) and in the wizard I choose the option to import an existing project from this newly cloned repo.
Yes I am aware of how little I may expect from Egit. In fact, if there are any alternative ways (external git tool? command line git for windows? other?) to use a git-tracked project in Eclipse which keeps the actual .git stuff out of the project, i'd gladly abandon Egit.
When you clone a git repository, the default behavior is to create a .git folder inside the root of the local clone. You can change the default behavior by setting the GIT_DIR variable:
Git docs says:
"GIT_DIR
If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository."
Depending on which terminal you use, you could set it using setenv or export.
For example in a bash terminal:
export GIT_DIR='[path_to_git_directory]'
After setting the variable, you should be able to clone and the .git directory should show up at the specified directory.
I totally agree - I can't imagine it would ever be anyones intent to commit the .git folder!
And git/EGit knows that this is the repository folder of the project, so it should be easy to implement the appropriate exception - so that this folder does not become part of the synchronization.
I know the following does not solve your problem, but in cases where you control the way files are layed out in the repository, you could choose to have the Eclipse project folder not be the root folder of the repository, but rather a sub-folder.
This also allows you to have stuff in the repository that should not show up in Eclipse, or even have multiple Eclipse projects grouped in one repository (if you should wish to do so).