Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Separating IDE workspaces from code repositories

September 24, 2013
Romain Pelisse
Related topics:
Developer Tools
Related products:
Developer Tools

Share:

    As I've been using Git, SVN (with git-svn) and Hg for quite a long time now, I've adapted my way to handle the local repositories created with those tools. Especially, I quickly found out that it is quite crucial to separate those repositories from your IDE workspaces. Some explanation of why and how are in this entry.

    (Photo credit by motjetom)

    Eclipse workspaces

    To understand why I wished to write about this, one has to know that many developers - especially Java developers, are 'Eclipse folks'. This means that they use Eclipse not only to code Java but also as a SVN/CVS client, and almost anything software development related.

    I used to be a bit like that, and then when I started using DVCS tools such as Git, I did the same. I used Git integration within Eclipse to checkout a project history. However, I quickly understood - like anybody who used Eclipse for more than 5s - that using one workspace was simply a mess. To help you understand the differences between centralized version control systems and DVCS, this blog post at Atlassian is pretty great.

    As my job as consultant often leads me to jump from project to project, a new method needed to be found. So, I set up a convenient bunch of 'workspaces' such as 'examples' - where I stored code for some "HelloWorld" project, 'jboss' - to store projects checked out from the JBoss community, and a 'contrib' workspace - with my works on several Open Source projects, and of course, one workspace by project and/or customer.

    In the meantime, I also started to use DVCS, both Mercurial (aka hg) and Git, and then also Git as a SVN client. At first, I simply added the resulting clones to those workspaces, as it seemed pretty logical. In the long run, it turns out to be rather messy. For instance, I could not have in the same workspace an Open Source project code base, from the 'contrib' workspaces, and the code base of the current customer-related project.

    It is then that I realized that a cloned repository could have quite a distinct life cycle as an Eclipse 'workspace', and that I therefore needed to decouple one from the other.

    Cleaning the mess

    Separating repositories from workspaces

    With this idea, I set up a ${HOME}/Repositories on my laptop, where I start moving all local copies of code repositories. Of course, I reused here again the same organization of before with 'contrib', 'perso', 'redhat', and so on... The only difference is that my customer's code base is living under another directory layout, where all my customer-related files go.

    After this reorganization, I started systematically using Eclipse's feature that allows you to specify a folder outside the workspace:

    (Photo credit by Romain Pelisse)

    With this setup, I can easily import the required project and into several workspaces if I need to. If I end up modifying the same code base, for two different projects, I can just use the regular branch feature of my DVCS du jour, and I don't need to duplicate the code history.

    Why not just locally clone the repository ?

    One could definitely argue that point. Why not just clone the code base into a new repository? It's pretty easy to do and quite fast. And given how large hard drives are nowadays, who cares? Even if you do care about disk space, Git is smart enough to use hard links for the repository files, which means that each new clone is not going to duplicate the history, but only the working directory and maybe some branch data.

    But the fact remains that you don't want any duplicate code bases on your laptop. You'll get in trouble and confuse yourself for sure. You will look for some code changes in the wrong repository or you'll just wonder which one is the "right one", end up being "lost in time and space."

    An old lesson...

    Another positive side effect of this strategy is that I can get rid of my workspaces very easily. There is nothing, but the IDE stuff in it! So if a new version of Eclipse breaks one of my workspaces, or if the version of Eclipse my customer is using is not compatible with it, no big deal! I just delete it, and re-import the project from my repositories folder.

    Here, we have actually learned again the value of a very old best practice in software engineering: It's always good to separate data and configuration from code. And even with your IDE and local development environment, it's a valuable practice!

    Suffixes for repositories

    I've also adopted a convention something like five years ago (and to be honest, that I borrowed from my friend and former coworker Goneri Le Bouder): add a suffix to any repository with an extension matching the tool used to create it (e.g. my-proj.git)

    Nowadays, where git appears to be winning the DVCS competition, one could argue it would make no sense to have such a convention, as the default would simply be git. Here again, the fact is that many, many companies still use SVN, and some even CVS, and there are a few products running on alternative tools such as Mercurial and Bazaar.

    $ ls -1
    pmd.git # this is a git clone of pmd
    hgbook-fr.hg # a clone of the hgbook
    arjuna.svn # a svn checkout of the JBoss arjuna project
    arjuna.git+svn # a full copy of the project using git

    This convention is rather simple to implement, and allows you to quickly see where you stand.  The suffixes are also handy for scripting in general - for instance to not back those repositories up.

    And if you don't like to see the .git extension in your IDE, you can always use a symlink to the file :).

    Final words

    What I have briefly described here is not going to change your life, but it did make mine easier :) . While I'm pretty sure there are many developers out there who would just do all this right away, I'm pretty sure some, like me at the beginning, will appreciate the "heads up". And that's why I took the time to share it here.

    Last updated: February 23, 2024

    Recent Posts

    • Alternatives to creating bootc images from scratch

    • How to update OpenStack Services on OpenShift

    • How to integrate vLLM inference into your macOS and iOS apps

    • How Insights events enhance system life cycle management

    • Meet the Red Hat Node.js team at PowerUP 2025

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Products

    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue