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?
Related
I have multiple eclipse projects that are tightly related. I want to add them in a mercurial repo (repos).
Option1:
Repo per project - too many repos and then I loose my ability to group projects because all projects are repos.
Option2:
Multiple projects in one repo as folders.
First, eclipse's plugin cannot add many project into one repo (this tutorial fails for me, there aren't many tutorials on the subject, I guess I can do this from the command line).
Also I cannot pull/push per project. I have to perform this operation per repo. I miss SVN in this regard.
Option3:
mercurial forest - no longer actively supported.
Option4:
Subrepository - feature of last resort.
What is the best practice?
It looks like a simple case like this doesn't have a straightforward answer. Is mercurial actively developed?
Second question first: Mercurial is actively developed. Here's the source update log.
Option 2 is your best bet. Like the guide you linked to shows, the repository folder (with the .hg folder inside of it...'n-projects-ws-repo' in this example) means that this folder--and every file and folder in this folder structure--is part of the repository. The diagram they show is two subfolders called org.ekkescorner.one and org.ekkescorner.two. These are two projects under the repo called 'n-projects-ws-repo'.
I have two different projects, but some feature are same for both project. Both projects are commit to server as Master. I want to make configuration so that i can pull the selected changes of project 1 to project 2 but I want to keep remote of both projects different.
Note: I am new to git and I am using Eclipse.
You can make patchs of the changes you want.
But, Why do you need to keep two git projects? You can keep one git project with two branchs.
I'm new to Jazz/RTC, IBM's source control/project management/uber-bug tracker. Our projects have used CVS/SVN/Git for years so I am very familiar with scm concepts and practices (branches, merging, tagging, fetch, merge ,push, etc). Alas, at this point some of RTC's concepts have not sunk in.
"Loading a repository workspace" as far as I know copies the "repository workspace" down to the local filesystem.
Questions:
What exactly does it mean to "load a repository workspace"?
When would you unload a repository workspace? (Why is it so network intensive?)
If dealing with mutliple branches would you have multiple repository workspaces? would you load and unload them into local filesystem when "switching branches"?
What is the relationship between the eclipse workspace and the "loaded repository workspace" and "sandbox"?
As a bonus: could someone point towards a 'RTC for cvs/svn/git users' article?
thanks
What exactly does it mean to "load a repository workspace"?
It is a bit like a git checkout: you are creating a local working tree in which you will be able to modidify your files.
RTC offers actually 2 workspaces: one on the server side, and one that you load wherever you want on the local workstation.
This is with the latter that you ask RTC to detect the files you will change, from where you will do a checking: that operation will register a change set in your repo workspace (stored on the server)
Compared to Git, this allows for private checking (as in git), but saved on the server side (so if your workstation breaks, you can recover your checked-in work by loading it again in a new local workspace)
When would you unload a repository workspace? (Why is it so network intensive?)
You don't really have to. If you want to reload everything i guess, but you actually can load a repo workspace as many time as you want.
RTC doesn't keep track of those sandboxes. But each local workspace knows which repo workspace it refers to (it is in the .jazz5 folder)
If dealing with multiple branches would you have multiple repository workspaces?
No: repo workspaces are linked to a stream which in turn can represent a branch in term of history.
You would have multiple streams.
You can choose to have multiple repo workspace on a same stream if you want to try different approach for the same development effort, but usually one repo workspace is enough.
would you load and unload them into local filesystem when "switching branches"?
No. You also can have different sandboxes (local workspaces) loaded (and switch between Eclipse workspaces)
What is the relationship between the eclipse workspace and the "loaded repository workspace" and "sandbox"?
It happens that the RTC client is based on the Eclipse GUI, which offers "Eclipse workspaces" since more than 10 years (way before RTC).
You simply import a project loaded from a local workspace into an "Eclipse workspace", for Eclipse to be aware of it.
Erigami mentions in the comments:
"Comparing concepts between Subversion and Rational Team Concert"
"What do load, unload, accept, and deliver mean?"
I am looking for a way to work with different GIT branches and have the Eclipse workspace in sync. with the directory structure of the GIT branches. In this case the branches will differ as projects have moved around from subdirectoris. To illustrate:
master
plugins
plugin1
plugin2
feature1
topic_organize
plugins
plugin1
plugin2
features
feature1
I think the current Egit solution is not workable. What it does it close projects which are not in the new branch. (When I switch branches in the cmd line, is even more horrific, Egit actually recreates the missing projects! in this case, when I switch to branch "topic_organize", the project feature1 in plugins will be recreated by EGit, my repo is automatically not clean which I sincerely despise, when switching to a branch).
What it doesn't do (and should do) is to start with a clean workspace, and import all the projects and organize them in working sets and on top load the appropriate target platform.
The consequence of not doing what is should is, that I have to 1) manually import missing projects,
2) remove projects created by EGit which are in my repo, but not imported in the workspace. 3) Create working sets if these differ between branches. (In my case the working sets, are equal to the sub-dirs in the repository). 4) Clean my GIT repo.
As a best-practise towards a full solution is to create a team project set. The working steps would be.
Import your projects from GIT and add them to working sets corresponding to the directories in the GIT repo.
Export a Team Project set to a special project. (Make sure the location of this project never moves in GIT).
Commit this "team" project, so your GIT branch is clean.
Clean your workspace. (I mean start with a clean workspace by removing all working sets and projects).
Switch branch on the command line (You won't be able to switch with a clean workspace).
Select file import, import Team Project Set (.psf) file. (Assuming you did step 1,2,3 for the other branch as well).
tada your workspace is back with working sets and all projects open.
Change your target platform if needed.
NOW MY QUESTION :P
Do I miss something? Is this there a way to clean the workspace in one go? Now I have to remove the working sets first, then the projects by selecting them one by one! (Perhaps I should switch the workspace as well?).
Considering the way Eclipse work, it has only one version of a project available in an Eclipse workspace at any time (because the id of a project is its... name)
When one needs to "switch branch", I always prefer having:!
multiple clones of the repo (one per branch, I rarely need more than 2)
multiple Eclipse workspaces
Switching branch means switching workspace and updating the branch you are in, in that workspace.
As the OP user2736833 comments below (using git remote):
git clone repo br_dir
cd br_dir
git checkout br
cd repo
git remote add -t br_dir br_repo ../br_dir
Then:
git fetch br_repo
git checkout br
git merge br_repo/br
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.