renaming repository folder - version-control

When I rename my repository folder in Nautilus, Bazaar can't open it any longer. In All Commands, there is a renames command, but it's not what I want. Bazaar claims to have the best renaming, so in the other VCSs, is everything unrenameable? What's going on? How do I rename my repository folder?

Based on more info from https://answers.launchpad.net/bzr-explorer/+question/116976 you have colocated workspace and you want to rename it. Because colocated workspace uses trick with lightweight checkouts and the latter using absolute path to point on the real branch inside colocated workspace, you have to execute bzr colo-fixup command after rename of colocated workspace.

Use Bazaar's rename option.

Related

Why does eGit create an extra directory in the remote repo when I do the first commit/push?

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.

Recovering a file in SVN

I deleted some files of a folder in SVN from eclipse. Now I want those files back to my folder. I can see the of the folder by clicking right click show history . how to get those files back into my workspace? Then I will commit to svn again
Thanks,
Raj
No idea how to do that in Eclipse but with plain Subversion that'd be
svn checkout
and
svn cat
commands: the former
allows you to check out the contents of all or specific
files and the specific revision (usually BASE),
and the latter
outputs the contents of the specified file
at the specified revition (again, usually BASE).
If you didn't delete it form remote folder you can simply recover it.
Synchronize the local workspace with remote repository and override the file that you deleted. It will override the local changes of the your file.

Eclipse Projects And Git

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.

what happens when I copy a checked out code folder under CVS?

I am working with a CVS repository found on a remote server.
I check out the code to a local directory code_local
Then I copy code_local, into code_local_2
Do I have now two independent local copies of the repository? Can I change files, commit, update etc. on each directory independently, is if it was done form two different computers?
(this may depend on the way CVS stores information about a local copy)
Yes I do know it's not a straight forward use of CVS, just asking if it will work
Do I have now two independent local copies of the repository?
Yes you have two independent LOCAL copies.
Can I change files, commit, update etc. on each directory
independently?
No, both copies point to the same file on the same repository. so they are independent as long as you haven't committed them. when committed the last commit operation will overwrite the previous one.
in fact there is a CVS folder beside every folder of your code that keep repository information of files inside that folder. so when you copy a project or a package, the CVS folder will be copied along with, so the same repository entries will be referenced, no matter how many copies have you made.
Even if you past the copied folder to another package hierarchy, whenever you commit the files it will replace the original files in repository where it first created.
If you want to have independent copies you have to copy and place your source code (.java) files only and commit it through Eclipse for example, in this case the CVS plug-in doesn't find any existing CVS folder beside the new folder and generates a new one in the local and new entries in the repository.

Get eclipse CVS to forget about removed directory

I'm looking for a way to convince Eclipse that a directory has indeed been removed from the CVS repository, permanently?
With regular command line CVS I would just edit CVS/Entries in the directory's former parent. With Eclipse, I've tried removing the directory from the Project Explorer view, removing the appropriate line in CVS/Entries, recreating the directory in PE so that it might be removed on update or synchronization, synchronize without recreating the directory, and probably other things that I've since forgotten, and nothing worked.
The directory has been entirely removed from the CVS repository, so I'm not talking about just pruning empty directories here. The error I am seeing is:
The server reported an error while performing the "cvs update" command.
Project: cvs update: cannot open directory /usr/local/cvsroot/one/two/three/removed_directory: No such file or directory
My project contains all of the contents from /usr/local/cvsroot/one/two. I do not get this error when I navigate to "three" and update from there. I only get it when I update from the project root.
One (quite imperfect) solution for this problem is, beside to check-out the project again, to remove CVS information stored by Eclipse.
Go in the right-menu under the project > Team > Disconnect, and check the radiobutton "Also delete the CVS meta information from the file system". Now your project is unshared and has no more CVS information into it. Then you just have to do Team > Share project, select the previous repository location, and you're done (CVS will detect by itself that the project is up-to-date and won't update nor commit anything, of course).
A folder that has been deleted in the cvs repository by hand won't then be proposed anymore by CVS under Eclipse to be commited.
Beware that on a big project with many files, depending on the speed of your network, the re-share may take some time.
Sometimes it may indeed be easier to delete the project and pull it off again from CVS.
I fought this same thing for several hours a couple of separate times. I just gave in and re-checked out the project. That seemed to work like a charm
Handling of directories in CVS is not perfect. This and many other reasons caused in creating more complete SCM tool subversion.
CVS can create directory, but can not remove it. From CVS point of view, to remove directory you need to remove (cvs rm) all files in directory. But directory is still present in CVS and there's no way to remove it. Hovewer, CVS propose a "hack" to hide such "deleted"/empty directories by executing "cvs up -P" (see here).
So, for CVS command line, I wouldn't mess with parent directory CVS/Entries file, but rather use "cvs up -P" described above.
The directory will be listed in the CVS/Entries file under the parent directory. Remove the entry in the Entres file and the directory. Eclipse should recognize the directory has been removed.
Refactoring directories in CVS is problematic. Due to the way CVS handles history one of the following usually applies:
The history of files moved to new locations appears to disappear. (It is located in the history of the old location.)
The history of files is retained, but files appear moved when checking out versions prior to the move. (Files were moved in the repository, rather than in a sandbox.)
Removing or moving directories in the repository generally creates problems for clients. It helps to retain directories and only move or remove files. Normal processing moves deleted files to an Attic sub-directory.
In the Eclipse CVS synchronization perspective, did you try the 'Override and update' option?
If the files/folders are already deleted on the repository, from the Eclipse project perspective, "replace with"->"latest from HEAD" on the folder containing deleted elements