I'm totally new to git and have a question related to the work bench. I do stuffs in java so I would ask in term of java. When you commit files to git repository, do we commit .java, .class files? Or it is ok to put the whole work bench into the local git folder then commit everything?
It's generally not considered a good idea to commit binary files to any version control system if you can recreate them by simply compiling the source code you also committed. This is especially important with a DVCS as every copy of the repository carries around the redundant data. This might not be a big deal if you're working on a fairly small project, but once the project gets bigger it's a nuisance.
The other problem with committing the .class files or any sort of binary is that any sort of build will show your source tree as "dirty" in multiple places unnecessarily as both the class files and the java files will need comitting.
My advice would be to put the build directories in your projects in .gitignore so git knows not to look at them, then add your source files and the Eclipse project files to git.
Related
First, there are no problems with my build path, and there's no problem in the "problems" window regarding this error. What happens is:
I check a project out of SVN
I then build that project
SVN "version" and link gets removed from classes and build directories (and red ! appears)
I can no longer commit project as a whole, as I get this error:
svn: Commit failed (details follow):
svn: Working copy 'C:\Users\<me>\Documents\eclipseSDK\<project>\classes' is missing or not locked
It's NOT missing, it just was "refreshed" during build
I've also tried to delete the dir on the SVN side, but the red arrows still appear and committing throws an error - even though those dirs are no longer part of the checked resources.
Also, basically, any "Team" menu option will no longer work on those two dirs, if I try to Team>Add to Version Control, nothing shows up in the Resources window.
I don't even know if I care about the red exclamation as much as just getting those two dirs out of the SVN process. Like I said, I've deleted on the SVN side even, so they are no longer there.
Are your compiled classes file part of your Subversion repository? If so, GET RID OF THEM FROM SUBVERSION!.
Sorry about the screaming, but files that can be built (like classes and jar files) should not be stored in version control. It just doesn't make sense.
Source control allows you to see the history of changes. You can see who made what changes in the source, but you can't do that in class files or jars. Source control allows you to branch and merge changes. You can't do that with class files. And, they go stale very quickly. No one cares about class files that were built last month.
The biggest issue is sheer size. Binary files don't diff well (and many version control systems don't even try). Let's say you build 15 megabytes worth of class files each time you do a build. That's probably at least 12 megabytes added to your repository each and every time. With in a year, you could be adding, 1 gigabyte to your repository. You can easily end up with the vast majority (and I mean in the 90% range of your source repository being nothing more than compiled code. Compiled code that no one cares about. Compiled code that can't help you understand your development history. Compiled code that clogs up your repository.
Go to your classes directory, and do an revert from the Team menu on that directory. You'll lose all of your changes, but so what? They shouldn't be there. This will set things up, so you can at least commit your changes.
Then, delete that classes directory and all of its contents from Subversion and commit. Eclipse will create the directory when it does a build, and you can make the directory in Ant's build file before you compile the code. You should then set an svn:ignore property on the directory parent to prevent people from checking in the classes directory.
If you need to store jar files for other projects to use, use a release repository. In fact, use a Maven repository like Artifactory or Nexus. You don't have to use Maven. Ant can use Ivy to fetch the files from a Maven repository, or you can simply use URLs to download the files as needed via wget or the <get/> task in Ant.
OK, I deleted [build & classes] from local, and deleted from SVN. Made a minor edit to a file, just to be able to run Commit - which worked fine.
That's good.
Both local & SVN were in sync. build & classes are (and were) part of ANT build file, so ran build again. build & classes reappeared (with ? this time), and added to svn:ignore.
Any file that's not in the repository will show up with a question mark. Those question marks will disappear if you add the svn:ignore property to the parent directory with classes, sync, and build in it.
Made another file change, but now I cannot commit the entire project, as I'm getting more/different errors now (e.g. "out of date").
The out of date means that someone somewhere modified a file that was in the repository and committed it. It's very likely that the change is one of the *.class files that you removed. You will have to do an update before a commit. When you do the update, you will likely see a lot of conflicts where a class file was changed, but you had removed it. Resolve these changes, update, and commit again.
By the way, I have a pre-commit hook that is useful in this situation. First, it can prevent people from adding that classes directory to the repository (and any files under it). Second it can make sure that the svn:ignore is setup correctly.
Using the combination of tools in the title, when I check out a branch, SourceTree/GIT will:
Definitely NOT delete folders from the previously checked-out branch, so if I have BRANCH-ALPHA with FOLDER1 and FOLDER2 and then I check out BRANCH-BETA which has FOLDER2 and FOLDER3 only and no FOLDER1, the resulting structure in FINDER will show that FOLDER1 is still there. Can reproduce this over and over.
Often will not even overwrite files from the previously checked-out branch, so that I'm still seeing BRANCH-ALPHA in Eclipse when I have checked-out BRANCH-BETA.
I close Eclipse before doing the checkout, and then open Eclipse, CLEAN and BUILD everything. It's really a problem with GIT.
The only "solution" is to delete all the folders and all the metadata and then check out the branch. This typically leads to a few hours of trying to "convince" Eclipse to open the project, creating a new workspace, new metadata, etc., and then fixing a lot of things like paths etc.
Any ideas on how to further research the cause and find a solution are very much appreciated.
Git only deletes empty folders when checking out a new commit. You might see apparently empty directories because there are hidden files stored in them. If you try to monitor the behavior by opening them in Finder, you're actually causing the problem since Finder creates hidden files to track the way the folders are displayed.
Does it really bother you that the folders are there? You could add a post-checkout hook that runs git clean -dxf after each checkout; this will remove all the files that are not known by git. Be careful that it will also delete compiled classes, so a new build will be required.
Another possibility is that something is locking files or directories, so git can't remove them while they're still opened/locked by the other program. This would also explain why some files aren't updated to the right version. Does git complain when you switch branches? It should if there's indeed a lock on the files.
When sharing a project as git and trying to make the Eclipse project folder as the git repository, Eclipse says that it is not recommended to do so and that it should be outside the Eclipse workspace.
Why is that?
From Eclipse EGit help pages,
It is probably not a good idea to make a project the root folder of your Repository
The reason is that you will never be able to add another project to this Repository, as the .project file will occupy the root folder; you could still add projects as sub-folders, but this kind of project nesting is known to cause lots of problems all over the place. In order to add another project, you would have to move the project to a sub-folder in the Repository and add the second project as another sub-folder before you could commit this change.
Some more information
It is a good idea to keep your Repository outside of your Eclipse Workspace
There are several reasons for this:
The new Repository will consider the complete folder structure of the Eclipse workspace as (potential) content. This can result in performance issues, for example when calculating the changes before committing (which will scan the complete .metadata folder, for example); more often than not, the workspace will contain dead folders (e.g. deleted projects) which semantically are not relevant for EGit but can not be excluded easily.
The metadata (.git-) folder will be a child of the Eclipse Workspace. It is unclear whether this might cause unwanted folder traversals by Eclipse.
You can easily destroy your Repository by destroying your Eclipse Workspace
While I agree about keeping the repository outside the Eclipse workspace, and I would still make a git repo within an Eclipse project root directory (like in this answer).
Unless your program is composed of lots of little inter-dependent projects, I would limit one git repo to one Eclipse project.
A git repo is about recording the content of a tree structure, and if that tree represents one project, it is easier to manage, tag, branch, merge (as a coherent set of files).
If it represents multiple project, you are not sure anymore about what a tag like "1.0" represents for each of the projects in that Git repo.
Plus, I like to add the .project, .classpath and .settings to the Git repo (as "Does git exclude eclipse project files from a new repo by default?")
In my project I have a directory structure like this :
project
--common
--subproject
--common (junction, not a copy)
The subproject needs some files from common. Therefore I created a 'junction' (in XP using the sysinternals command) to be able to see and make changes in common from within the subproject.
This works like a charm, any changes to both commons are immediately on both common since in fact it points to the same folder.
Then I made a separate project in Eclipse for the subproject folder and its own svn repository.
But when I want to commit the subproject, it wants to commit the 'common' folder as if it were a real folder, but in fact this folder needs to be committed only to its parents repository!
Is there a way of telling svn to make commits to a different repository than its own?
svn:externals is not a good solution since this creates duplicate sources, and makes it even harder to maintain, because it's not automatically kept in sync.
eclipse's file system abstraction features linked folders.
Have you tried using those rather than a junction at the filesystem level? (I don't know how the subversion plugin treats those, but perhaps you are in luck)
I keep my .project and .classpath files in my source repository. I maintain separate eclipse workspaces for each branch off my trunk. I've found the best way to do this is to recursively copy my trunk workspace (cp -r dev/ branch-foo/). This works great. There are a few other details that facilitate sharing templates and key mappings, but that's not important here. The issue with this solution is that I end up with a workspace that, to no surprise, contains all the trunk projects. I then have to remove all these projects from the workspace manually and then import all the projects in the branch. Not a huge deal, but I'm wondering if something better can be done to automate this process.
I don't see any files that get written to as I add/remove project files in my workspace so I'm assuming eclipse manages these relationships in some internal DB or something. Additionally, I looked into any command-line support eclipse offers for doing this, but don't see anything.
Any thoughts would be much appreciated.
One P.S. - I do see some binary files located in ~/workspace/branch/.metadata/.plugins/org.eclipse.core.resources/.projects/project_name/