[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Which eclipse files belong in svn, anyway?

From: Puneet Lakhina <puneet.lakhina_at_gmail.com>
Date: Fri, 21 Mar 2008 01:57:00 +0530

On Thu, Mar 20, 2008 at 10:07 PM, Paul Pcoder <paul.pcoder_at_gmail.com> wrote:

> On Thu, Mar 20, 2008 at 8:50 AM, Mark Phippard <markphip_at_gmail.com>
> wrote:
>
> > On Thu, Mar 20, 2008 at 7:23 AM, Hendrik Maryns
> > <qwizv9b02_at_sneakemail.com> wrote:
> >
> > > I have a project in which the .project and .cproject files are in
> > > version control. It turns out this isn't a very good idea. How
> > > can I remove them from version control without deleting them?
> >
> > I generally recommend you do version those files and think it is a
> > good idea, but that is not your question.
>
> This is a question I've been wondering about for a while. This isn't
> exactly a Subclipse question, but we're all Eclipse users, and were
> are all presumably using Subclipse to manage and share our project
> files, so I'll go ahead and ask: Which files *do* belong in eclipse,
> anyway?
>
> I realize the answer will depend on the user's workflow and typical
> team interaction, and I think that my situation is a little simpler
> than most, as I am only trying to share my files with myself between two
> machines at the moment, as far as the java projects I'm currently
> working on go.
>
> I get that I have to export my preferences from eclipse, in order to
> import, for instance, my code formatting preferences into another
> instance of eclipse. I'd rather that eclipse automatically saved all of
> my preferences in a single file, which I could store in SVN, so all I
> had to do was commits and updates, but that's more a complaint about
> eclipse than a question...
>
> My irritation began as I realized that my Debug launch configurations
> were not appearing when I opened my project on my other machine. OK,
> fine, I'll figure out where they are stored and put that into SVN too.
> Problem: they are stored underneath the workspace .metadata folder, in a
> subfolder specific to the debug launcher plugin.
> (org.eclipse.debug.core/.launches)
>
> OK, but does this mean that every time I use a plugin that stores data I
> want to persist across machines, I have to figure out where it stores
> that data, and manage that folder explicitly? I could just put the
> entire workspace in SVN to avoid the whole issue, but holy cow that's
> something like 15 megabytes. And surely that approach would not be
> appropriate in a team environment, and I'm sure I can think of workflows
> were that would be a mess even with just one user...
>
> So, I put it to the group: what strategies do you use to persist
> eclipse projects across different machines, in such a way that minimizes
> time spent re-configuring settings and what-not on each instance of
> eclipse that you use?
>

I am also very interested in this. We mostly work on web apps so we check in
the .project as well as the .classpath into eclipse.
Checking in .classpath becomes necessary as which folders are source
folders, what is the output folder is decided by this file. So this
configuration makes it easy for someone to checkout code and start running
without too much configuration (Except they have to create servers). The
.project is necessary i believe to tell eclipse that its a dynamic web
project and not just a java project.

But then if you have external references, .classpath doesnt make sense to be
checked in.

I think it would be really helpful if the outcome of this thread could be a
general guideline on what to checkin in what sorts of projects.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
> For additional commands, e-mail: users-help_at_subclipse.tigris.org
>
>

-- 
Puneet
http://sahyog.blogspot.com/
Latest Post: javac -g
Received on 2008-03-20 21:27:08 CET

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.