RTC/Jazz : what does "load a repository workspace" mean? - eclipse

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?"

Related

Is it possible to share a project without commiting?

I'd like to use "Share Project..." in Eclipse without actually commiting to SVN. Unfortunately, I am not able to find an option for doing this.
Instead, I want the relevant files only be added to SVN.
My goal is, that SVN should track all the files I move into the project using the package explorer.
Share Project needs to accomplish two things:
It sets up some internal linkage in Eclipse that connects your project with the SVN Team Provider so that SVN menu actions are exposed and so that activities you perform are routed to the SVN provider to "handle".
It has to establish your project as SVN "working copy" so that the SVN API that needs to be called on behalf of your actions can do what it needs to do.
So the key here is that if you already have a SVN working copy then Share Project will recognize this and be able to do option 1 without needing to do anything else. But otherwise, it has to establish a working copy which requires it to do svn checkout from your repository. If it has to create the working copy then it makes the assumption it needs to create the project in the repos and then check that out on top of your local project. So the one commit it will do is a svn mkdir for a folder in the repos.
If you do not want to do that, then do something to establish a working copy locally before you get started, such as checking out some existing location in your repository. As others have noted, you may want to be using branches and switch if you are refactoring something that already exists.
When you commit data to the SVN repository, you publish this new data or make changes to existing data (i.e. you make your changes available to others). Therefore, you need to commit your changes if you want others to see it in your SVN repository and collaborate.
As far as I recall, "Share Project" command in Eclipse is designed to import your non-versioned project to the SVN repository (i.e. make a first-time import) -- it converts your local data into a working copy and commits it.
I do not understand what exactly you mean by "share but not commit" (you may want to elaborate). However, you can always select which files to add and commit or import into the repository, but I guess that you will need to use standalone SVN client outside of Eclipse.

GitHub + Eclipse Workflows

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.

Eclipse - sharing project directory with multiple users

We are trying to set up Eclipse so that two users can share the same project directory on our server. Is this possible? Every time we try, it creates a new folder and project.
Thanks!
Chris
No, this isn't possible. Eclipse only supports a single user accessing a workspace (not just a project) at a time.
Use a source control system such as Git or SVN to share code. Eclipse supports many such systems and has extensive sharing support in the 'Team' menus.
The best way to do this would be to use source control.
Sharing the actual workspace or the files with different eclipse instance is a recipe for trouble.
An easy way to do this would be to install git on your machine and also on his machine. Eclipse actually already has git in it ready to go so you probably dont need to install anything.
The one with the files locally will create a repo locally on his computer and commit the files to it.
Next you want to init a new empty repository on a shared folder and push your local chances to this as you would to github for example.
Your partner can then git clone from this repository to his machine and work locally.
Each of you will develop on your own copy and commit your changes locally. You will share your changes by pushing your commits in that central repo and pulling from it to get changes from your partner.
You could also just open an account on GitHub, GitLab or BitBucket (there are many others too) and use that instead of a shared folder. big advantage with these services is that they will be available from anywhere.

pydev egit commit individual project

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?

Is it possible to use EGit without having to Share Project?

For now, I only have a local .git subdirectory under my Eclipse workspace and I don't feel the need to push it to shared repository.
I would like to also use EGit, but its user guide provides only a Share Project way to do that.
Can I re-use my local .git without having to push/publish/share it?
"Share project" in this context doesn't mean, that you have to share your project to a remote repository. It only means, that this Eclipse project is connected to a (local) Git repository. And yes, in this case you have to share your project, so that Eclipse detects the Git repository.
I think, "Share project" originates from a time, where there were only centralized VCS, and in that case, your project really was shared with a central server. Now with decentralized VCS, another term may be better suited.