Egit: Checking out two different versions - eclipse

What is the best way to checkout two different versions of a project in Eclipse Egit and have them show up in seperate directories?
My situation is as follows. I was working on a project and made some good changes and some bad changes (State A). I want to check out a previous working version of my project (State B) and copy and paste some of the good changes from State A into State B. Every time I try to check anything out it just replaces the files shown in the package explorer.

That's because one Git repository has one working directory, and the working directory reflects all branch changes etc. So if you want two versions, you need two repositories (just clone the one). Since you cannot import two projects with the same name in one Eclipse workspace, you have to rename one project after the checkout and before project importing.
But you could also use the Compare mode. Select the project, choose Compare with -> Branch, Tag or Reference and select the other branch, with which you want to compare. Then you can just add the contents from the other branch to the current files.

What you're asking for is not very git-ish, but here's how you'd do it.
You'd take your existing repository and you'd clone it to a new repo. In that new repo, you'd check out your "to" version (either by branch or tag or commit ID) and in the old one you'd check out the "from" version. Then you'd point Eclipse at the two directories to create projects from them.
Then you've got two projects in Eclipse, each containing a working directory that is the different versions, and you can manually move code from "from" to "to". Once your "to" project is the way you want it, commit that, delete the "from" repo and project, and Bob's your uncle.
The git-ish way of doing this is to use git bisect to find the commit that contained the bad change, and then revert that commit either in whole or in part.

Related

is it possible to commit all selected projects from Eclipse to one github repository

how is it possible to commit all selected projects from Eclipse to one github repository(as imaged below)?
Currently when I commit my new project to github, a new repository will be created.And I'd like to avoid creating massive number of new repositories.
Thank you in advance!
p.s.I found other related topics for this question, but don't know what I should do exactly.
need your help please.
There shall be an Eclipse plugin that'll do your git job but I'll tell you a generic solution in case that plugin is not helpful. Well, all these selected projects are directories basically and if they're residing inside the same directory, let say <dir-1>, then you can add the remote repo path to <dir-1> using git remote add origin <git-path> and then add all your directories i.e. projects which will be part of the git repo. Best case would be to create separate branches for each of these projects and then merge those branches to master when they reach a logical state without any breaking changes. Now, in case, if all these directories are not residing inside <dir-1> then create a symbolic link inside <dir-1> to all those projects (possibly with same names) so that whenever the original directories are updated these directories are also changed respectively. Check more about symbolic links.

How to update SVN source using subclipse

I am using subclipse plugin in Eclipse to use SVN repo. for commit the source changes i use [Right click -> Team -> Commit]
I need to pull the latest changes from SVN repo. i am seeing options for updating the source
Right click -> Team -> Update to Head &
Right click -> Team -> Update to Version
Which one i have to use to update the latest changes in my local repo and what is the difference between them. Please suggest.
The difference is following:
Update to HEAD will do svn update.
In other words it will update your working copy to the last revision from the repository.
Synchronize with Repository is something similar to svn status -u, but even more.
It will open a Synchronize tab (or perspective) that displays overview of your local (outgoing) modifications versus repository (incoming) modifications.
In this tab or perspective, you can review and synchronize (commit / update) individual files, see differences between your working copy files and incoming files from repository, browse commits history, resolve conflicts.
Update to Revision:
The standard Update command has no options and just updates your working copy to the HEAD revision of the repository, which is the most common use case. If you want more control over the update process, you should use TortoiseSVN → Update to Revision... instead. This allows you to update your working copy to a specific revision, not only to the most recent one. Suppose your working copy is at revision 100, but you want it to reflect the state which it had in revision 50 - then simply update to revision 50
Update to Revision can occasionally be useful to see what your project looked like at some earlier point in its history. But in general, updating individual files to an earlier revision is not a good idea as it leaves your working copy in an inconsistent state. If the file you are updating has changed name, you may even find that the file just disappears from your working copy because no file of that name existed in the earlier revision. You should also note that the item will show a normal green overlay, so it is indistinguishable from files which are up-to-date.
In general, I highly recommend you to check out the SVN Handbook. At least first two chapters.

How to use Git properly when you want to create X projects based on one clean project?

I'm just starting with Git so I have no idea what I'm supposed to do :
I have one clean project, a very basic one with just what is needed for every project (maven dependencies, etc). This project is in a repo I created in GitHub, and now I'm wondering :
If I want to use this clean project as a base for all future development, how am I supposed to proceed ? Do I have to create a new repo manually for every future project and then somehow push my clean project on it ? Can I "duplicate" a repo ? Or am I supposed to work on only one repo and create a new branch for each derived project ? i'm quite lost on "how to use Git properly".
More importantly, how can I achieve this with EGit ? I won't always be able to install something on the computer so I would rather use Git in my eclipse (if possible). But so far I didn't find a way to enter Git commands using EGit (and I guess EGit doesn't have a specific button for what I want to do so... ?).
Thanks a lot ! (and sorry for my english if there are any mistakes)
Can I "duplicate" a repo ?
Yes, it is called a fork: you duplicate on GitHub your own template repo, and then clone that duplicate locally.
See this Gist for forking your own project (since the "Fork" button is only available to fork project from other users).
Use a msysgit installation for the commands, before importing your local clone in your Eclipse with Egit.
That allows you to maintain two upstream relationships:
one called origin referring to your fork (your duplicated template project in which you will develop)
one called upstream (or "template", or ...), referring to your template project, in order for you to update it you make locally an evolution that should benefit all projects of yours.

Subclipse SVN first commit ignore certain directories

Decided to take the jump from CVS to SVN.
I setup a new repository in subclipse for my project. When I go to 'Finish' the setup it wants to do an initial commit and presents me with a flat list of files to select the files for version controlling.
The problem is I have thousands of generated binary files I dont want to commit.
So I click on cancel because it would take me all day to go through and unselect all the unwanted files. Annoyingly when I click on a parent category for the files I want to ignore it is not recursive!
So I click cancel then go to the eclipse directory structure for the project and manually set svn:ignore on all directories I want to ignore. Then I try and do a commit again and all the files are once again presented - ignore seems to have done nothing.
Can anybody point out what I might be doing wrong?
For the first commit, I recommend writing a small script to delete (of course you'll have a backup) all the files that are not meant to be committed.
Afterwards, if you find you accidentally committed a file, you can
svn delete file
Upon the first checkout, copy back (or better yet, regenerate) all the binary files. This will trigger svn to notice that your local repository is out-of-sync with the remote repository.
cd <Root of local repository>
svn status
You will see lots of "to be added" items. Go to the parent directory and add in svn:ignore properties for each of the generated items.
cd build
svn propedit svn:ignore .
which will open an editor (if it doesn't, you need to set the environmental variable SVN_EDITOR to a suitable editor). Then you can add in entries that svn will know are not tracked.
(in the ignore property editor)
target
build
image*
*.o
(and so on)
Save the file, and it will be staged for the next commit. Subsequent runs of svn status will no longer show these files as "needing to be added", but they will show the directory as "needing to be committed (it's a revision on the directory)"
Quick Aside
So I'm not entirely certain exactly which functionality of Subclipse you were using in order to create a repo and share a project to it, I'm assuming you created like a file based repo through the eclipse SVN repo view and tried to share and then commit to it. It looks like your problem got solved but I did want to add an answer on here because I ran across this post looking for the answer to this same problem of handling initial commits even just in general with SVN and wanted to offer help to anyone else looking for the help.
Intro
To start off I would recommend not working through an IDE extension like this just for the initial commit as they can miss a lot of the options for handling opening a repo in SVN. I personally really like the command line form of SVN to work with but TortoiseSVN is a good option for a GUI.
Whether you create a local file-based repo or are connecting to an SVN server and you want better control over your first commit in an previously unversioned project here is what I've found as the best general workflow for doing so.
Create the remote folder to save to.
On command line this will be:
$> svn mkdir your-url-scheme://your-site-address.domain/path/to/repo/example-directory
Or on TortoiseSVN open your repo for browsing, right click, and select "create new folder"
This will give you a location in the SVN repo to checkout from for our next step.
Checkout in to the already started project
Make sure to use the empty, newly created folder in your repo to checkout with. SVN does not actually require a folder being checked out to to be empty, which is an important part of what makes it actually very flexible and able to subsume parts of your directory into it fairly easily if used correctly.
Now you will checkout this empty folder into the root folder of your already started project. This will add your project to the working copy of this folder without any commit being made yet. The command is:
$> svn co your-url-scheme://your-site-address.domain/path/to/repo/example-directory /your/projects/root/
"co" standing for checkout. In Tortoise svn you can right click on or in the empty repo folder and select "checkout..." and then select the project root.
Set ignores and commit
Finally, you can easily set your ignores on certain files before adding any other files to the tree using the command:
$> svn propset svn:ignore file-or-directory-to-ignore
And to add all non-ignored directories and files:
$> svn add * --force
The force is technically unnecessary in this case but ensures full recursion. You can also now do all of this in your file explorer if using TortoiseSVN or you can even use your IDE extensions to do this at this point(make sure to ignore all files you need to before mass-adding files for commit), all that's left is to make sure to commit the newly added files to the repo and you're up and running with source control :)
Added this method here simply because this method allows you to avoid any unnecessary copying of those stinky binaries that no one wants to lug around with them.

Using Coldfusion Builder and the Mercurial Eclipse plugin, how can you check in changes - including those in linked folders

We have a Hg repository set up for the root of our webserver. There are a number of projects which have their own directories and there is a common C directory for components.
In CFBuilder, I have a project set up for each of them and I'm using linked folders to make it easier to access the components.
CFBuilder and the plugin correctly show that both are under version control, and update properly when changes are made -- but when select that I want to commit from the Project > Team > Commit, none of the changes from the C directory are shown in the changes which will be committed.
Is it possible to have it work this way, or is there a preferred way to work with linked folders?
You need to set up a separate project for the Components, and do your commits from there. Changes made in your linked folders should be reflected in the C project, but if the C project is part of a different repository (which it would seem is the case, given your linked folders), you'll need to commit from that project.