I have the following directory structure:
CommonUtilities, DataStructure1 and DataStructure2 contain source files used by one or more projects.
I would like to publish one or more projects as open source using Mercurial and BitBucket. But I don't know how to manage the source files used by one or more projects.
I am new to source control and to software development in general, so I would like to know the best practices in this kind of situation.
Should I:
Include the common source files in more repositories as needed?
(that is hg add them to two or more repositories)
Include the common files in some other way than hg add?
Do something completely different?
Option 3: Do something completely different.
You can use the subrepository feature: keep the common files in a different repo, then reference them from your repository.
You are trying to solve the issue by wrong tool. The best way to manage such situation is a dependency management tool (look at Maven, Ivy or Gradle).
Related
This may be a stupid and easy question but I don't know. I'm working (with other people too) on java projects (java maven projects) with Eclipse and SVN.
When I commit my changes, do I just need to commit the *.java files I changed or the whole java Maven project ?
Thank you
In general, it is a good idea to ask your team for common rules or best practice. So if they want you to only change *.java files, you are better off to contribute only changes that respect this requirement.
In most SW-teams or companies, however, a project is not only made from plain source code. Many projects are composed of .properties files, XML-based configuration, e.g. Maven's project and module definitions found in pom.xml files, or even things like SQL-snippets that is shared for development purposes. From time to time, a developer needs to conduct changes to these non-*.java files. So it might get "blocking" if you would't share these adjustments with your team via a common repository, i.e. here: git or svn.
In essence, ask your team what they expect from you as a contributor OR let your team discuss and make a decision on how you want to organise the project and the code repository on a file level.
Edit: Beware of hidden directories with local configuration information, i.e. the IDE-environment such as properties of the local workspace. These are clearly developer specific things.
Hope it helps.
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 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/
I have one Eclipse Workspace containing two projects.
- The first is my actual library.
- The second is example code for using the library.
When I push this code to GitHub, I don't want two separate projects, I want the example code to go into an "example" folder of the second library.
How and where would I do this? From Eclipse, GIT, or GitHub?
Or is there a better way of including sample code in GitHub projects? (the example code doesn't actually need any version control)
What if I decide to add more than one sample project?
You can apply source-control to projects in one wokspace, project by project is that pointng to different nodes
Please see Tutorials Git with Eclipse (EGit) and Git, Github and Egit Eclipse integration
Hopes that helps
After more experience with Git and GitHub over my belt, now days I usually place any example code in a separate orphaned branch.
This has several benefits over placing examples into a sub-folder. Primarily, any changes or additions to the examples (Which obviously aren't critical to the library) won't give unnecessary notices of the library code being "changed", or even "ahead" of code in any forks. Also, this setup works well with Eclipse, since both projects will then have their own separate local repositories.
It's also a good idea (and I often forget) to point out this "example" branch in the README.
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.