Our company develop several software products, which reuse each others packages (we use Java). Every product represented as separate Eclipse Java project and has it's own versioning repository (we use Mercurial).
When we find a bug in some shared package, we need to transfer changes to all consuming projects, and this is a hell. The key problem is that Eclipse project can be associated only with one versioning repository.
Could someone recommend some way to associate Eclipse Java project whith several versioning repositories which in ideal may be geterogeious (svn, git, mercurial) ?
This should really be addressed with:
git submodules or
mercurial SubRepos
You can modify directly from a submodule/subrepo, push to a "central" repo, and other can fetch the modifications, and then go one directory up (in the main repo referencing all the other submodules) in order to register the new commit of the new submodule/subrepo state.
The "main project" (the main repo which record all the other submodules/subrepos states) is not necessary an Eclipse project (one of the submodules can be the main Eclipse project, with project dependencies on other).
See "true nature of submodules" for more on that process, which remains "not easy", but can still be managed precisely.
Related
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.
Question:
How do you commit a single project (of many) in pydev (eclipse Indigo 3.7.2) using egit?
Problem Specifics:
I have many independent projects that currently all go to the same repository. I work on them all sporadically and need to commit them individually (not all at once) since sometimes only 1 project is ready. Unfortunately, when I right click on a single project folder, select Team, then Commit, git tries to commit all of my projects (not just the one I selected).
Conjectures:
Do I need to have the projects in separate local repositories? If that is the case, what is the best practice for segregating projects that eventually end up in the same bit bucket repository? Or, should I just have multiple bit bucket repositories?
Group,
We use Borland Starteam as our source control system. I develop Java code and use Eclipse as my IDE. I recently started using EGit as my personal source control system and came up with the following workflow to streamline my dev work, which consists of checking out code, adding features, fixing bugs, testing, merging with the parent source in Star team (huge effort if lots of people have made changes in the meanwhile), build, test, and install. I want to use EGit to simplify the compile, merge and test process, while developing and also just before code install after big merges are made. This is what I have come up with.
Create file system folders - 'Master' and 'Work'
Check out fresh source folder structure from Starteam into 'Work'.
Create Eclipse workspace called 'Work' and import Eclipse projects from 'Work' folder add those projects to an EGit repository.
Add features/fix bugs while in 'Work' workspace. Test, etc. Create a patch when ready to install. Now its time to make the big merge, rebuild, test again.
Check out fresh source from Starteam on the day of the install into 'Master' folder in the file system.
Create Eclipse workspace 'Master' from source in 'Master' folder, import Eclipse projects and add those to a newly created EGit repository.
Import patch into 'Master' workspace, perform merge. Fix compile errors, test, etc.
Install.
Is this workflow efficient? Are there more advanced features in EGit that would simply this any further?
Thanks for any guidance.
Ranjit
Unless I'm understanding this wrong, it looks like you are using eclipse workspaces in place of the existing git branch functionality. Egit, if I'm correct, can manage branches all on its own so you don't need to run back and forth switching workspaces. You can create then merge branches and do all the other fun stuff within a single project.
The workflow from here is all git. A good article on maintaining a sane workflow can be found here: http://sandofsky.com/blog/git-workflow.html
I am working on an enormous project ("the project") which is open-source, and I am changing the project but don't have a permission to commit. I'm looking for strategies for maintaining my own branch of the project. Some issues I am contemplating:
How to put my own work in a version control system, given that I'm altering the project's source code, adding new files and so on.
How to keep in sync with the project without having to manually merge my own changes over and over again.
I've never been in this situation - I've always maintained my complete project in some version control system. My plan right now is something like that:
Creating a directory tree in my SVN, similar to the one in the project.
Keeping all the changed files (and only them) in my svn.
Every time I decide to sync with the new baseline of the project, I'll do a checkout, merge my svn tree into the new version, test, then commit my changes to my svn and distribute them along with the latest project baseline.
The problems here are ENDLESS. Way too many manual steps, more and more work over time, and so on. The correct way to go would be, of course, to be a part of the original project, but this seems to be quite irrelevant right now for various reasons and is out of the question.
Ideas?
I'd use git or mercurial for this; simply import the project into git or mercurial, and merge the upstream changes into a branch in your project for easy merging into your trunk.
If the upstream project has a repository of their own, the import is even easier. Both git and mercurial have support for directly importing other version control systems. I did this recently to adapt an existing project that lives in SVN: https://github.com/mjpieters/rod.recipe.rabbitmq
Note that that project has an 'upstream' branch. That particular project has now accepted my proposed changes after reviewing the changes in github.com.
There are a few questions here on SO on the subject:
Fork and synchronize Google Code Subversion repository into GitHub
Tracking upstream svn changes with git-svn and github?
Best way to fork SVN project with Git
It should be trivial to create a similar setup with mercurial.
You can use git to maintain your source control on your local system. In fact Git can be used to maintain just about any directory under version control. There is no need to sync to anything, git maintains all changes locally.
If you need to commit to SVN check out the documentation http://git-scm.com/docs/git-svn
I want to store a project in Mercurial that contains external code (which can be modified by me) coming from Git and SVN repositories. In SVN I would solve this with vendor branches and copy the code around, but I understood that in Mercurial it's better to have different repositories for different projects, and pull between them when needed.
The project layout will be like this:
- externalLibraryA [comes from a SVN repo]
- ...with some extra files from me
- externalLibraryB [comes from a SVN repo]
- ...with some extra files from me
- externalPluginForExternalLibraryB [comes from a Git repo]
In Subversion I would create vendor dir and a trunk dir, copy all external libraries first in vendor, and then in the right place in trunk. (I think) I can do this in Mercurial too, with subrepositories, but is this the best way to do this?
I tried setting up different repositories for the external libraries, but then it seems I can't pull the externalLibraryARepo into the externalLibraryA directory of my main repository? It goes in the main directory, which is not what I want. I can also create a Mercurial mirror repository and include it as a subrepo in my main repository, but then the changes in this subdirectory go to the mirror repository, while I want them to stay in the main repository.
I'd probably just store this in one repository - note that in the link you give they are using their build system in the end to bring together the binary output from the different repos. I'm not clear on their rationale there.
If the underlying problem you're trying to solve is how to update the externals in a clean way, I'd probably use anonymous branching for that.
I.e. add the external lib to your project, and your modifications. Make sure it works. Tag with ExternalA-v1.0. Hack away on your actual project. Now ExternalA, Inc. has a new version of their stuff. Update your repo to ExternalA-v1.0 tag. Import their new version and apply your modifications on top. Commit. Now you have two heads: one with the latest version of your code (that works with ExternalA-v1.0) and one with the latest version of ExternalA (that does not work with your code, maybe). So then you merge and reconcile the two. Tag again, now with ExternalA-v2.0. Repeat as needed.
You can still keep your externals in separate repositories, but I assume that the project that is using those does not need to be up to date with changes there all the time - looks like the whole point of vendor branches is to have some point of isolation between dependee and dependants. Of course, moving the changes from the externalA project to the project that is using that will then be a manual affair (well, a copy, much like in SVN really).
It depends on whether your vendor code is going to be customized by your team or not. Our teams have had a great deal of success maintaining a named "vendor" branch on repositories with our own customizations on branches named by project name. This vendor code is then easily included in a project as a subrepository.
A caveat to this approach: if active development is going on in the subrepository, best keep it to directly editing the subrepository as a separate clone, otherwise it becomes necessary to pay close attention to the top-level repository so you don't inadvertantly bump your .hgsubstate forward to the wrong revision and break your build.
Watch out for merges of the top-level repository (your project) between versions which point to different named branches of your subrepository, as this can result in a merge between the "vendor" and "project" branches in the subrepository as it recurses, which may not be desirable.
Note that this functionality may change in the future as well, as some "warm" discussions have been taking place in recent months on the mercurial-devel mailing lists about the future of subrepository recursion.
edit:
I just saw this discussion in the related links as well, which seems relevant: https://stackoverflow.com/a/3998791/1186771