Should we remove the .che folder from Git when we use Web IDE Full-Stack?
The rule of thumb is to never include IDE-specific files into a Git repository. There are several articles and blogs on this and I would point you to this one: IDE Project Files In Version Control - Yes or No? Of Course, Not!
The main drawbacks of having IDE specific files checked-in are the following:
Each IDE would add its own files. E.g. if some of your developers would decide to use VSCode, then you would also have a .vscode folder in there.
The file structure may be different depending on the IDE version (if you use the SAP Web IDE Cloud, this should not be an issue, but it might be if one developer is using the local WebIDE).
The files change very frequently and lead to merge conflicts. E.g. if you do a deploy and also one of your colleagues does a deploy, then you will have a conflict when you want to merge your branch with his (assuming that you work on parallel branches).
The files may contain environment-specific settings. E.g. the name of the project folder, which may actually be different for each developer.
The only clear advantage is that setting up the project after a clone operation might be faster marginally (i.e. the developer which is doing the clone might have to do some settings locally on his copy).
Related
I am sure this is a RTFM thing, but after a few days of research I still cannot determine the correct (or best) workflow for this.
I have an Eclipse Workspace with a number of Java Projects in it and a number of C++/Arduino projects.
I want to start using GitHub as an online repository (easily reachable from outside my private LAN dev environment) for my projects
I was thinking I would like a separate C++/Arduino and Java GitHub repos. More could come for Python, PowerShell, etc. (But I will happily entertain other recommendations for repo structures).
Outside of the actual mechanics of using Egit, I cannot figure out the most appropriate workflow/folder structure for accomplishing this. Should I create local Git repos and push to GitHub as a remote? Should I use GitHub's web interface to import the entire Eclipse Workspace? Should I work directly with the Eclipse Workspace or have separate Git folders?
I guess the crux of my problem is that after reading a few related posts on this site I get conflicting advice about creating a local repo from the Eclipse workspace vs. a separate local repo. I think I need to understand this distinction first before I ultimately determine the best overall workflow.
I apologize for the broad nature of this question, but I hope that the community can help me narrow the workflow process design (or the question itself).
Two things up front:
Never put your entire workspace in source control; projects: yes, workspace: no. The .metadata folder contains data specific to that location and your machine, and that's ignoring any potential security risks with making it public.
eGit works with your git clones' own metadata, so if you're more comfortable doing certain things from the command line, go for it. I know I am, but I still appreciate the UI and decorations that eGit provides. Just make sure any automatic refresh/update preferences on the Workspace or Git preference pages are turned on.
You probably want the repository to contain multiple projects, rather than having a separate repository for each one. That way histories and changes that belong together are together. Nest the layout however you like, but remember that you're not constrained to a single repository for everything, either.
I don't know that there's a best practice for this, especially with projects that already exist, but projects should themselves be relocatable. My recommendation, after backing it all up:
Make the Github projects, clone their repos locally. I do it this way, from the command line, to save me any headaches with the history, remotes, and refs. I don't think you can modify the repository metadata in this method, though.
Move the workspace projects into the local clone. You can delete them from the workspace (be sure not to delete the underlying files), physically move the directories while outside of Eclipse, and then import them as projects back in from the Git Repositories View--unless they're Maven projects, in which case it's better to use M2E's import wizard.
Stage, commit, and push the projects up to the remote origin. For Java projects, don't forget to set the JRE System Library in the Java Build Path to use an Execution Environment. It's a simple bit of indirection that makes them more portable across machines.
The reason for such requirement is We are using a Proprietary product which only supports a specific structure in Eclipse Project within a custom Eclipse perspective also provided by the plugin.
Now To have meaningful segregation of files for readability, Our team wants specific folders to consist certain files.
Those folders to be checked in only ( not the Eclipse Project created by proprietary plugin)
Now say my Eclipse project folder is :
Proj
|__Folder1
|__file1
|__file2
|__Folder2
|__file3
And I want to store:
git
|__Different_Folder_Name_Folder1
| |__file2
|
|__Different_Folder_Name_Folder2
|__Different_file_name_file1
|__Different_file_name_file3
Questions:
Should I store the wished structure in Local Repo or GIT server Repo?
Based on previous answer, how to
a. create and maintain these separate structure? and
b. keep sync between these separate structures?(clone/pull/fetch/commit/push)
Note: I'm almost novice at GIT. So spare me from down vote on this query.
I am also not asking how to switch between dev / prod in same folder.
If this approach is wrong then suggestions are welcome too
It's impossible.
Even if one solution is existing for your wish, it isn't best practice.
I want to build my portfolio on GitHub. I have a few Java projects and I used Eclipse to build them. How should I share them on GitHub?
Should I share only the src folder? That way, however, I would end up losing some dependencies (databases or img folder etc.).
Is it good practice to share the Eclipse workspace on GitHub? If I use third party libraries these will be included too though.
Sharing only the bin folder would be mostly pointless. Basically, if you want to share your projects in Github, the expectation is that you are also sharing your source code as well. Sharing only the src folder would still be mainly pointless, both for the missing resources you already mentioned and also for missing project metadata (e.g. required Java version, project name, etc.) that gets stored there. Without this metadata it might be still possible to compile your projects, but having the project metadata included allows others to simply check it out into an Eclipse instance, and it should compile and run without any extra configuration required.
Sharing a workspace is a bad idea, as your workspace .metadata folder contains your preference settings, file system references (sometimes referring to absolute paths on your computer), and sometimes even passwords. I would not recommend doing it.
To be more constructive, I would suggest to do the following:
Categorize your projects, and create a separate repository for each different project. This helps to show you are building several things that can be used separately. Of course, if some projects belong together, share them inside a common repository.
When you create a repository, generate a gitignore file related your project type (e.g. Java project) - see screenshot below. This sets up the repository in a way that you are not uploading class files, etc. that is unnecessary in a source code repository.
Share your projects one-by-one into this repository. Eclipse has the EGit project that supports this aspect (most likely it is already installed if you have a not too old Eclipse instance.
[Update: See comments]
So lets say I have a structure like this:
/trunk/src
/trunk/platform/linux/[eclipse project]
/trunk/platform/windows/[eclipse project]
I want both project to be able to see /trunk/src, open its files and use the automatic error highlighting on those files. I've tried creating Linked Resources to the directory. This works great with nasty limitations. It never updates unless you re-import and you can't create/delete files. I tried storing a symbolic link in the git repo which apparently as of git 1.6.1 no longer works. I tried anyway and upon cloning the symbolic link comes our broken.
This is really just for ease of access to the main codebase for a multi platform project. The solution need not be elegant but it is important. So I figure I can instruct each dev to just make their own sym link to the main codebase as part of dev environment setup. Tried and these symbolic links created with ln -s do not seem to appear in Eclipse nor can they be imported.
Finally I figured I could create a General Project in /trunk/ within Eclipse. Seems Eclipse is "smart" enough to warn me that this is not possible because it detects other projects deeper in.
Any help appreciated.
First, a comment:
'/trunk/xxx/yyy' is a SVN approach, where all branches/tags are "emulated" as directory.
You don't need them with Git. Two branches (one 'linux', one 'windows') are enough; then you can clone your repo twice, once in a 'windows' directory, one in a 'linux' directory.
Regarding a possible solution:
If the only difference between the linux and the windows platform, regarding eclipse, are the .project and .classpath files, I would actually recommend having only one repo (for your sources), with aforementioned two branches, each one including the sources and the eclipse files (tailored for each platform).
That way, the solution is much easier to maintain: one repo, one structure. Two branches.
I am looking at putting a code base that runs several website into version control. There are several instance of this code base running websites on different virtual servers.
The problem I'm grappling with is that each of these separate instances of more or less the same code have sub-directories with site-specific functions. But it seems that version control systems want to control the entire directory hierarchy.
For instance, each instance has the directory
/www/smarty/libs/plugins/
Where you'll find site-specific functions for smarty. When we are ready to put it into version control, the folder /www would be the root.
So one option is to have all the site-specific functions going out to all sites. I don't see a problem in and of itself, but it seems somehow architecturally 'wrong'. There would be a bunch of files that only belong to one deployment.
Another option is to have a separate repository for each site's specific files within the code base. But that sounds like it could quickly become a nightmare when trying to get new sites deployed properly.
What's the best way to do this? The version control system we're looking at is subversion.
Generally, source control systems should be used to control source. They are not at their best completely controlling file hierarchies, permissions, and other related things. These are best left to deployment configuration.
How about having each of the projects and directories you need represented once in the version control system. Then, in a separate directory (perhaps called /build/), have the various configuration layouts. You might have an ant file that builds each site, or maven. Or you can use tools like Capistrano or Fabric to have more control over each deployment.
The tools are made to be flexible (generally), so here are some suggestions:
Most VCS' allow you to ignore files and directories through some mechanism (e.g. Mercurial .hg ignore file), so you should be able to target what you want/should control versus what shouldn't be.
Separate the files/directories into common resource project and site-specific projects and then use a build system to integrate them to create a deployable package. The build system can be as simple as a shell script or a more sophisticated framework. If its a really simple integration, the VCS may have some basic features for merging bases (e.g. Mercurial subrespositories).
With subversion, you could have a bunch of repositories:
www be in a general repository
plugins each be in a site-specific repository
Then have nested working copies:
svn co http://www_repo www
cd www/smarty/libs
svn co http://foo_plugins_repo plugins
Tip: add plugins to svn:ignore property of www/smarty/libs
svn propset svn:ignore "plugins" www/smarty/libs
You could certainly do that with git too (through .gitignore), and probably with other version control systems but I don't know them.
(Alternatively you could skip the nested working copy part (which can freak some people out) and check out stuff side by side, but use a symlink in lieu of smarty/libs/plugins, while ignore still pertains)
You're missing a "build" step, which whould take the source in source control and create the deployment bundles for the different sites. Only one source package is needed, different build configurations create the different deployment packages. Don't try to directly put the deplyoment set into source control, it is not the source!
I believe the best thing to do would be to create a top level directory in your repository for each site (Site-01, Site-02, etc) and inside those directories put the source tree. Then you can checkout the projects separately. I think it's acceptable and somewhat standard to use the same repository for all the projects your company is involved with.
My terminology might be off kilter, but the fundamental idea is sound, I believe.