I am experimenting the use Git to manage development environment for one of my client project which is on CVS (and can't move out). Since the environment is quite complicated and has multiple steps to setup, I am hoping version controlling would help. So far it is actually very helpful to do it. However, all the project CVS setting (like the CVS module and branch) are not tracked by git via EGit plugins. so when we recreate the environment we have to reshare the projects that is really inconvenient.
I dig down on the issue and found that EGit does not track CVS folders in those project so the CVS information is lost.
Is there a way to tell EGit to track those folders?
Thanks all.
Related
I am working with Git/SourceTree/Eclipse. I am cloning a GIT repo outside of my Eclipse workspace. SourceTree is now pointing to this location.
There is no .project file in GIT. So in Eclipse I create a new dynamic web project and import my GIT repo (including the .git folder) into it. The project builds just fine.
Now this means that any changes I make in Eclipse won't be reflected in SourceTree because the GIT repo is essentially in 2 places. So I'd have to make another repo in SourceTree just to point to my Eclipse workspace.
I cloned the GIT repo outside my workspace because I heard that's best practice. But surely there's got to be a simpler way.
What is that simpler way?
Thanks for any helpful tips.
Since you imported the folder with the .git-folder into your workspace-folder, you could just use that directory for your development now. You no longer need the original clone.
However, I'm guessing cloning inside the workspace-directory is considered bad practice because it can slow down your Eclipse-project (see Is it better to keep Git repository inside or outside of Eclipse workspace?).
Probably cloning with EGit could make your life easier because it can point to a .git-folder outside your workspace-folder. (http://wiki.eclipse.org/EGit/User_Guide#Cloning_Remote_Repositories)
I have been using Eclipse IDE with egit and pdt for a couple of years. I have a local git repo outside my workspace and a remote private repo, largely for bckup - I am the only active developer. In addition to my projects (several sub-projects) I have imported a Joomla installation so that I can debug my projects in their working environment. So far so good.
Recently, I needed to start work on a big upgrade. So I created a new workspace and a new local git repo cloned from the remote repo. I imported a different Joomla installation and created a separate branch for the new code.
I am using one workspace to push to the remote master and the other workspace to push to the remote branch. I can 'see' both branches in both workspaces and I get myself confused because they are not usually in sync. And I get very confused when it comes to merging something from the master into the side branch. So far I have muddled along but I can't help feeling this is wrong and bound to lead to disaster.
It would be fair to say I don't know nearly enough about Eclipse or Git to figure out how I should have set this project up in the first place. And I don't know the exact steps I followed to set up the structure I have right now.
Can someone offer advice on a practical repo and workspace structure for working on branches that require different testing environments?
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 would like to use two svn repositories. One is to synchronize with my production environment and the other is to synchronize with another developer. Is it possible using Subversive in Eclipse?
EDIT: Sorry! I meant SVN, not CVS
I think what you means is "For one given project, I would like to be able to synchronise on one side with the official repo and at the same time, use the synchronisation and merging facilities to stay i sync with another CVS repository".
Best of my knowledge, this is not possible from the same project. Neither with CVS nor with subversion nor with any other SCM. This is a little bit because all SCM plugins are actually plugged into the Team Management plugins of eclipse and has actually a lot to do with the fact that the relation between a dev environment and a repository is quite exclusive.
What you have to do if you want to synchronize on an exceptional basis is :
Disconnect from one repo (say CVS) (team disconnect). Do not delete the .cvs folders.
Reconnect to a second repo (say SVN - either subversive or subclipse <= my preferred one)
Synch with SVN
disconnect from SVN
reconnect with CVS (team => share).
This is too risky to be done on a regular basis.
Therefore there are other strategies
Use a "shadow project" in your workspace synchronised through a regular synchronisation tool. The master project being connected to the CVS repo and the shadow to VN.
Use git + SVN. git as your local repo backed by SVN. The other developer can use a similar approach.
All in all there are no simple "out of the box" solution. All these solutions require a significant amount of commitment to work flawlessly. But SCM has always been like this, I guess.
Subversive adds Subversion
integration for Eclipse (subversion
is a version control system similar
to CVS). It does not handle CVS
repositories!!!
To use CVS repositories with eclipse
you should use the appropriate CVS
Plugin for eclipse.
You may even use both eclipse plugins (subversive and the cvs plugin). They will work with Eclipse like a charm (but keep in mind that subversive only handles subversion repositories).
Yes its possible to use Subversive in Eclipse. I am using Subversion and CVS both through Eclipse and Tortoise. Subversion is much faster and seems to handle binary files better. The one thing to get your head around is that revision numbering is totally different between subversion and cvs. May be this can help you.
Hope this helps.