I want to create a local repository using tortoise tortoise cvs without making a server...
Is it possible??
You can create a local repository on your computer. You create an empty directory, and call cvs init within there (I guess ther is a cvs.exe or cvsnt.exe lying around somewhere in the installation directory of TortoiseCVS. If not you need to get it). Then you can import any local folder into this repository. You enter the file path of the top folder when you are asked for the CVSROOT.
:: create the repository
c:
mkdir c:\repo
cvs -dc:\repo init
:: import something
mkdir initial
cd initial
echo 23>42
cvs -dc:\repo import first-module useless-tag-1 useless-tag-2
There might be issues with the '\' chars in the path names, you can then try with forward slashes.
But honestly, today I use Mercurial and TortoiseHg for version control, which has lots more features and is less painful.
Related
I used computer A via the Terminal to create a) create a git repository, b) add an index.html file to the repo, c) add a remote origin, d) push to the remote origin. All OK.
Then, i used computer B to clone that repository via Terminal. Then, I opened Eclipse (equipped with Egit), and created a new project in the folder that was created by the cloning process. Then I used Eclipse to push any changes to the remote origin.
Returning to computer A, I used Eclipse to create a project in the original repo folder, and then I attempted to pull from the remote origin, in order to get the changes that were pushed when using computer B.
Eclipse will not do it. It complains the I have items such as .settings, .project and similar and since they are not under version control it won't overwrite them by fetching files from the server. I had to manually delete those files (via Terminal) and then Eclipse worked as expected.
Please provide information on how to avoid this.
Should I create the local repo from within Eclipse and then push it to the remote origin, so that items such as (.settings) are under version control and (if so) how would that cause trouble to people cloning the repo and use different versions of Eclipse?
Should I gitignore those items?
Should I ask Eclipse to save its own affiliated files to another folder (not that i am aware how to do that, i only know that NetBeans does it)?
Looks like you didn't gitignored eclipse files.
Probably, when you commit/push via egit, you also commit and push those files you already had unversioned in your machine A, so git complains, because you are asking to override existing unversioned files.
I strongly recommend you to gitignore those eclipse files. You can see examples of .gitignore files in the github gitignore repo.
Hope it helps.
It complains because if you pull the changes from your remote it will overwrite your local files. That is the problem. The other answerer has right. You should better add all the eclipse project files and and target .settings and classpath to gitignore. You can use a global gitignore for your computers as well, before creating projects. You could use maven for example, then you can import your projects only from the pom.xml-s given in the git repository.
I use them the same. Egit and other guis are a bit too complex to work with. Git repositories can get easy in an inconsistent state where you should use the oldfashioned terminal to solve things. Like, rebasing, merging on conflicts. Gits learning curve is solid.
Now you can solve your problem if on the first computer save a backup of your original and clones your project later, after fixed it on the second. On the second git remove all this files, but use the --cached option to avoid deleting them. Before you do it so, check the help of git remove! after you have done this, put them into the .gitignore as filenames with wildcards. You can also use a global gitignore file in your user folder. Creating a .gitconfig file where you can specifiy the global ignore with the following :
[core]
excludesfile = ~/.gitignore_global
Than just create the .gitignore_global like this :
/nbproject
/bin
/build.xml
.idea
chess.iml
target/
bin
( This file is for idea and netbeans. you can add eclipse project files here )
You can have .gitignore files per project too. You can commit them to the repository, so on the next machine you do not have to do this again. The nicest way I think is having a dotfiles git repository, which is a git repo of your home directory and the dotfiles in it. I also use it for different windows and linux distros.
That's all. You should keep all of your configuration in a safe place. And source code management can do it. But do not commit private stuff to public a place! ;)
Oh I wanted to mention that, you can also have a .gitignore entry in your .gitignore file. That can be very useful when you do not want to touch a repository but need to add a gitignore to hide some stuff especially from the given repo.
I'm in the specific use case of wanting to methodologically document everything significant I do while setting up my new workstation (running Mac OS X Lion).
I would like to version control, in the same repository, files that are at totally different places on my file system, for instance files in /etc, ~/, /Libraries, etc.
Some thoughts/details on my requirements:
This repo will be for personal use only. I'll use a GUI client to browse my settings history.
I initially wanted to use Git, hosted in one large Github private repository, but as you can't clone subfolders the way you would do it with SVN, I'd have to create symlinks everywhere, which does not seem convenient.
So, would I be better off setting up a local SVN server and just checking in the files I want, when I want to version them?
You can use Mercurial, Git, ..., and then simply ignore all the files you don't want to version. Create the repository in the root and track the rest. Like (for Mercurial):
$ cd /
$ hg init
$ echo ".*" > .hgignore
$ echo '^(?!(etc|Libraries))' > .hgignore
$ hg add
$ hg commit -m "initial checkin"
An alternative is to use more specialized tools such as etckeeper that are made for tracking configuration data.
I've just recently started using Mercurial and would like to keep my projects as independent from IDE as possible.
Therefore, I would like to only include my src, test src, and doc directory in the repository.
I've managed to only book these directories into the repository by ignoring all project related files.
The problem is that when I then clone it onto another system, Netbeans 7 wants to create a new project from these files. It does so by creating the project file inside of the repo instead of on the cloned name, since it cannot create a project on a directory that already exists.
Is there a standard way of booking in these folders and then when cloning them to create a project from them?
What about creating the project in Netbeans first and the cloning the files into it?
To avoid Mercurial complaining about the clone destination not being empty, use init + pull in the project directory instead of clone, this is equivalent:
$ cd myproject
$ hg init
$ hg pull -u http://example.org/myrepo
You could also just clone into a separate directory and then move all files (including the hidden .hg directory) into the Netbeans project. You could even just move the .hg directory, because that’s really all that Mercurial cares about.
Although actually I’m surprised you can’t start a project that is already on the file system. I’m not familiar with Netbeans, but can’t you import an existing project from the file system?
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).
I've been using ComponentSoftware's CS-RCS Basic for many years now to manage my various single-developer projects. It's worked very well for me, but now I want to migrate to a modern revision-control system, and after studying my options I decided on Mercurial.
The problem is that I've always used a central repository for CS-RCS, and I'd now like to use individual Mercurial repositories for individual projects, keeping the history from my RCS repository.
After some in-depth Googling I concluded that the only way to do this is to convert my RCS repository to individual CVS repositories, then convert those to Mercurial. These two sites were probably the most helpful:
Converting a directory from RCS to Mercurial
Convert Extension for Mercurial
In keeping with Jeff Atwood's idea of asking and answering my own question, I'm going to answer this for anyone else stuck in this situation, and in case I have to find it again later. As you'll see, though I did find a solution, it's clunky and has at least one significant problem. If anyone else has any better method I'd certainly like to hear about it.
Here's the method I came up with, warts and all. It's a bit 'cargo culty', since I basically know nothing about CVS and not much (yet) about Mercurial:
I have a Windows XP virtual machine that I can take snapshots of, so I did that and then installed CVSNT and the Windows command-line version of Mercurial (I use TortoiseHg on my main machine). I did this in a VM so I could easily get rid of CVSNT, Mercurial, and anything else I had to create while doing this one-time migration. Yeah, I probably didn't have to do this, but the VM was already available and I've already got enough odd bits of apps left over from install/uninstall cycles over the years. :-)
As far as I could tell, CVSNT was the only program available that could easily set up a CVS server on a Windows machine. It seems that this was free at one time but the owner's current site now asks for money. That's not a bad thing, but I really couldn't justify spending money just to do a one-time conversion. I did eventually track down an older version of CVSNT with a Google search and installed that without problems.
Here are the notes I took while learning how to make this conversion work:
The Long Version
Copy the source-code folder you need from the main computer's drive to the VM's drive. Copy the various ",v" files from the C:\RCS folder structure to this same source-code folder on the VM. Just copy the ,v files from the corresponding folder in C:\RCS.
Open a Command Prompt box on the VM and type the following:
path %PATH%;C:\Program Files\cvsnt
mkdir \cvs-repo [or clean the folder out if it already exists]
cvs -d \cvs-repo init
[A DIR of \cvs-repo should show a CVSROOT folder in there.]
Make a copy of your source code folder in \cvs-repo. \cvs-repo should now just have two folders: CVSROOT and your new folder. Copy in the appropriate ",v" files as well.
mkdir \cvs-checkout [or clean that folder out if it already exists]
cd \cvs-checkout
cvs -d \cvs-repo co name_of_your_source_code_folder
A DIR of "\cvs-checkout\name_of_your_source_code_folder" should show all of your source code files, which are now checked out of CVS.
If you haven't already done so, download Mercurial from https://www.mercurial-scm.org/ and install it. Open a copy of Notepad and drag the file "C:\Program Files\Mercurial\hgrc.d\Mercurial.rc" into it. Under "[extensions]", remove the semicolon at the start of the line ";convert =". Save the file to "C:\Documents and Settings\user_name\Mercurial.ini"
Back at the VM command line:
path %PATH%;C:\Program Files\Mercurial
mkdir \my-repo.hg [or clean that folder out if it already exists]
hg convert --datesort \cvs-checkout\source_code_folder_name \my-repo.hg
cd \my-repo.hg
[A DIR of \my-repo.hg should show a new ".hg" folder.]
hg update
[A DIR should now show the ".hg" folder and all the checked-out files.]
Copy the ".hg" folder from \my-repo to the source code folder on your main computer's hard drive. The destination folder will now show up in TortoiseHg with all of the appropriate change history, but all files marked as Changed (icon overlay of an exclamation mark in a red circle). This is because the new Mercurial repository thinks the files were checked in with Unix line endings (0x0A) instead of Windows (0x0D,0x0A). This seems to happen in the "hg convert" process, and I haven't found any way around it.
The Short Version
Once everything's set up in the VM, here's what to do:
Delete everything in \cvs-repo, \cvs-checkout, and \my-repo.hg.
At the command line, cvs -d \cvs-repo init.
Back on your main machine, copy the source-code folder into your Virtual Machine's shared folder (that's how you do it in VirtualBox; other VM software might let you just drag-and-drop the folder into the VM).
Copy the appropriate ",v" files into the source-code folder in the Virtual Machine shared folder.
Back in the VM, move the source-code folder to \cvs-repo.
cd \cvs-checkout
cvs -d \cvs-repo co name_of_your_source_code_folder
hg convert --datesort \cvs-checkout\name_of_your_source_code_folder \my-repo.hg
cd \my-repo.hg
hg update
Copy the .hg folder from \my-repo to the L: drive on the VM (L is the mapped drive letter of my VM shared folder).
Move that folder from the Virtual Machine transfer folder to the final source-code folder on the host computer.
Handy Batch File
Once I got this working, I set up this batch file on the VM to automate the process as much as possible:
#echo off
rem Converts source code under RCS control to a Mercurial repository.
rem This batch takes one argument: the name of the source-code folder (in quotes if necessary).
rem
rem This is for a VirtualBox VM that already has CVSNT and Mercurial installed, and has a Shared Folder mapped to drive L.
#echo On the host, copy the source-code folder into the Virtual Machine Transfer folder. Copy the appropriate ",v" files into the source-code folder in the Virtual Machine Transfer folder.
pause
#echo on
cd \
rmdir /S/Q \cvs-repo
mkdir \cvs-repo
rmdir /S/Q \cvs-checkout
mkdir \cvs-checkout
rmdir /S/Q \my-repo.hg
mkdir \my-repo.hg
cvs -d \cvs-repo init
xcopy L:\%1 \cvs-repo\%1 /E/I
cd \cvs-checkout
cvs -d \cvs-repo co %1
hg convert --datesort %1 \my-repo.hg
cd \my-repo.hg
hg update
xcopy \my-repo.hg\.hg L:\.hg /E/I
Conclusion
So, this all worked but left me with files that had the wrong line endings. Looking at this question, I see I'm not the only one with this problem. I can live with this, but I'd still like to fix it if anyone knows of a solution.
If Mercurial has fast-import/fast-export support, and if your multi-file repositories do not use branches, you can probably try using my rcs-fast-export tool (available # http://git.oblomov.eu/rcs-fast-export ). Although I've only used it to export from RCS to git so far, I am not aware of any git-specific fast-export commands being used so it might work.