Maybe I have hallucinations, but I'm pretty sure of what I'm saying (I am new to GIT): I have some java code on my local drive, never versioned (to any versioning system, neither GIT nor SVN or whatever). I've created a repository on bitbucket, then I imported the source code from local drive. I did some testing, following a tutorial. Everything worked fine since I've noticed that, in the history folder (I am using the Eclipse plugin) I could diff two older versions of a file (and have the correct diff displayed), but these changes were made BEFORE I even created the git repository (local and remote).
I cancompare two versions saved yesterday:
I![YESTERDAY][1]
I can compare two more recent versions (today):
![TODAY][2]
-- I cannot post images, not enough reputation :( --
Notice that I installed GIT (and created the bitbucket repository) TODAY!
It's Eclipse tracking the history. I have a toy Java project open in Eclipse—which has not been commited to any source control—and I am able to diff against previous versions I saved yesterday.
To see for yourself:
Create a new Java project
Create a new class file
Make several changes, saving each time
Compare with > Local history...
Related
Hello everybody I have this "big" and frustrating problem,
I have forked a project from git and as usual it is available in my account in GitHub. I then set up a project in eclipse selecting from an existing URI. All is ok, if I work with my own version of the project.
What I want to do is, because the project is changing and growing day by day, to have an updated copy from the original project and, every time I want to download any change I would like that the download is from the original project.
At the moment the only way (with EXTREMELY big problems) I found is using "Team > Fetch from Upstream" the changing the link to the repos using the "config" button. Obviously this lead to conflicts and annoying problems. I am sure that this is not the correct way to handle a forked repos and I need help.
I am using windows 7 and eclipse with egit, if I press Windows-R and then cmd it don't recognize the command "git" so I can't use console commands.
Any help?
With windows 7, you can install git to your machine and use console command as normal. (Link to download)
See this link to configure git to sync your fork with the original repo.
Hope this can help.
My question may seem vague as I don't know much about git, but I'll try to be as clear as possible.
I have a repository on Github which I imported on Eclipse. As one could expect it, when I pulled on the command line the Eclipse project was refreshed (automatically, or manually, but it was clearly the same files) and when I modified the sources on Eclipse, it affected the git status.
I've had a huge build problem with Eclipse which led me to delete the project (not on the disk) and recreate it with Import existing projects into workspace. However, I noticed that the git status was unchanged when I edited the sources on Eclipse, so I pushed the changes on Eclipse, since it is imported as a git project. I thought it was ok, but I just discovered it was not the case. Here are two versions on the same file :
The version I want to priviledge :
https://github.com/jxw1102/Projet-merou/blob/ffe65c33c57b5d547fe7b79c7345d0788629e882/ModelChecker/src/cfg/Model.scala
The older version : https://github.com/jxw1102/Projet-merou/blob/master/ModelChecker/src/cfg/Model.scala
Also see their respective history : https://github.com/jxw1102/Projet-merou/commits/ffe65c33c57b5d547fe7b79c7345d0788629e882/ModelChecker/src/cfg/Model.scala
and https://github.com/jxw1102/Projet-merou/commits/master/ModelChecker/src/cfg/Model.scala
Now I can date the issue and fix it quite easily, but could someone explain me how it is possible (where exactly the code has been pushed, if not to master), and how to change the Eclipse project so that it pushes on master ?
I was trying to add bitbucket to my [existing] project on eclipse so I can commit it and have a GIT to work on, but I screwed up. In my GIT Repository Exploring there were 2 cloned project (the same) so I smartly deleted it to import again. The problem is, in my computer, the local folder with the project got deleted. I need to get my files back (as it was before trying to GIT it). Is there anyway I can do it? I'm desperate, since I've backed up 2 weeks ago and I have modified it a lot !
If Eclipse still has the project you can right click on the project and select Restore from Local History.... Eclipse will show you the files it has saved in its file history cache.
My service provider changed URLs on SVN repository. We were unable to reconnect from Eclipse SVN plug-in.
Based on their suggestion, tried Share Project, which allowed us to redirect to new URL, but ended up screwing
up repository files.
Still have intact local copies with SVN state on a client machine.
Is there a way to build a new SVN repository and load in local working copy WITH SCN HISTORY intact.
When we did this with Eclipse plug-in Team prompts, it ending up recreating projects but lost the
original SVN change history, which we would like to preserve.
Thanks
If I understand your question correctly, the short answer is "no".
An SVN checkout does not donwload the complete history to your workstation. It just downloads the current state. When you make changes, it remembers what it downloaded so that it can compare what it downloaded to what you have now. So you could reconstruct "last revision" and "updates since last revision". That's about it.
Eclipse keeps track of edits, but I don't think it's going to remember edits across checkouts, because that's going to look like a new file. It has a finite buffer anyway.
If you were so fortunate that you have a directory where you checked out revision 1, and then you kept that and checked out revision 2 to another directory, etc, you could reconstruct the history. But few people do that because it would normally be pointless because the history is in SVN.
You can't get history from Working Copy, because WC is always only slice of repository
If SP inly changed URL and you can and know how to work with pure CLI SVN and WC as directory in FS - you can
switch or relocate working copy
or
checkout from new URL new project
I've just started using subversion, and have read the official documentation (svn book), cheat sheet and a couple of guides. I know how to install subversion (in linux), create a repository (svnadmin create), and import my Eclipse project into the repository (SVN import), view the repository files (using svn list).
But I am unable to understand some of the other terminologies. For example, after importing my Eclipse project into the newly created repository I have made changes to my Eclipse project (more than 1 file). Now, how should I update the repository with this added files/changes made to my Eclipse project?
The svn update command brings the changes from the repository into your working copy - which is the opposite of what I want i.e. bring the changes I made in my Eclipse project into the previously imported project in repository. If I am correct, you update the repository more often (as you keep extending your project implementation) than your current project (with update).
Also, I do not understand when would you use svn merge. The svn book states it applies the differences between 2 sources to a working copy. Is there a scenario which would explain this?
Finally, can I have more than 1 project checked into the repository? Or is it better to create a new repository for each project?
The term you are looking for is "commit".
Subversion does not exclusively lock a file for editing (though there is a command to do this if you really, really want to). So it is possible that you will need to merge two different users' sets of edits on a file, or even edits from two different working copies in two different locations on your machine.
Multiple projects is fine. Best approach IMHO is repository/project/trunk etc rather than repository/trunk/project.
Three things about SVN you should know:
Trunk - The main version of your code
Tags - 'Tagged' Versions of your code (i.e. v1.2.5-release)
Branches - Forks of the code for divergent development paths. We typically fork new branches to work on different versions, so if the current version is 1.2.4, you'd branch for 1.3's development. So if emergency changes to 1.2 need to be made (i.e. 1.2.5) you can work on it without worrying about what you broke by refactoring / feature adding in your 1.3 branch. The merge operation is designed so you can merge 1.3's branch back into trunk when you're ready to release 1.3, or a similar operation. You can also merge individual files (if two or more developers edited the same file at the same time and now you need to 'merge' the changes into the same file.
Each project in your repository should have 3 folders in it:
/trunk
/branches
/tags
These house the three points above. You don't have to have these folders, but you should. Other more mature VCS like Mericual/Git have the concepts of tags and branches baked into the system. In SVN these are more of a convention/reccomendation.
Terminology
Working Copy - The copy on your hard-drive, that contains all your edits, etc...
Add - Registers a file for tracking in version control
Update - Updates the working copy with changes from the server repository
Commit - Updates the server repository with changes from the working copy
Switch - Replaces the working copy with another folder within the server repository
Diff - Does a differential analysis of two files / versions of a file to see the changes between them.
Merge - Attempts to apply the changes from one or more files into another, highlighting conflicts.
Patch - A set of differences that can be used to update a file.
You commit changes to the repository
Merge is useful when you need to maintain two branches of a repository. For examples v1.x with most recent security fixes and the alpha version 2. That allows you to make the fixes in the 1.x code, whith the resulting binary for existing customers, and you can merge the changes into version 2 so fixing the bugs that weren't already caught.
I suggest you look around for 'typical svn workflows'. They will give you the big picture of the 'most common tasks'.
What you want to do is 'commit' the changes made to your files to the repository.
You need to merge in case of a conflict (when 2 or more people are working on a project and commit to the same repo. conflicts might arise).
Check the available articles on SVN kai remember to read about the sample/typical workflows or working scenarios with SVN.
Fully agree with David, but as far as question 3 is concerned, personally, I would distinguish between use cases:
Production: One project per repository. And do get warm with the mentioned tag/trunk/branch concept, it really helps a lot
Testing: I have one single repository where I have put virtually all my experimental codes (approx. 10 languages with x codes per language). Reason is: One experimental code takes me 1-2 minutes, creating a repository on a remote host, using ssh-security sometimes takes longer ;-)
Cheers
EL