| Team question - what to check-in in SCM system [message #333866] |
Sun, 11 January 2009 07:32  |
Eclipse User |
|
|
|
Originally posted by: jontwest.homemail.com
Hello,
I'm not sure if platform is the correct group for Team related questsions,
but I think so.
If I'm wrong please tell me which group is correct.
As a part of an ongoing assigment I will start using Eclipse with a source
repository
(Subversion). I have done some testing and I guess it is best if not all
files are
actually placed under source control (all compiler generated files are
ignored already)
The Eclipse projects that I will place under source control are both Java
Projects
and Plug-in projects.
My assumption is that I should not add the .classpath file and not the
directory .setting
(we do not allow settings on project level - all project ineherits from
workspace settings)
I'm I correct in my assumptions and are there any more files to exclude?
regards,
JW
|
|
|
| Re: Team question - what to check-in in SCM system [message #333874 is a reply to message #333866] |
Sun, 11 January 2009 15:54  |
| Eclipse User |
|
|
|
Originally posted by: coolsnoopy.gmx.net
Jonathan West wrote:
> Hello,
>
> I'm not sure if platform is the correct group for Team related questsions,
> but I think so.
> If I'm wrong please tell me which group is correct.
>
> As a part of an ongoing assigment I will start using Eclipse with a source
> repository
> (Subversion). I have done some testing and I guess it is best if not all
> files are
> actually placed under source control (all compiler generated files are
> ignored already)
>
> The Eclipse projects that I will place under source control are both Java
> Projects
> and Plug-in projects.
>
> My assumption is that I should not add the .classpath file and not the
> directory .setting
> (we do not allow settings on project level - all project ineherits from
> workspace settings)
>
> I'm I correct in my assumptions and are there any more files to exclude?
>
>
> regards,
>
> JW
>
Hi Jonathan,
no, not correct:
..classpath is a must to be included in the SCM. It belongs to the
project and has to be version controlled too. And why should one guess
the classpath? It's important.
Don't forget to include the .project-File also.
Concerning the .settings I'v got no experience: if it only exist if you
have project-specific-settings and vice-versa than you should include
it, because no problem than. And thinking that you will never-ever allow
that... it may change earlier than you expect.
So I would include it, too.
So as a rule of thumb:
split sources and classes in 2 different project-folders (as you have
already done I hope, e.g. src and bin) and ommit the class / bin-folder.
This way the project in the SCM contains everything that is necessary
for the step "Eclipse-Project-Import existing Project" if you make a get
/ checkout of the SCM.
Regards, Norbert
|
|
|
| Re: Team question - what to check-in in SCM system [message #333880 is a reply to message #333866] |
Mon, 12 January 2009 09:03 |
| Eclipse User |
|
|
|
Originally posted by: eclipse-news.rizzoweb.com
On 1/11/2009 7:32 AM, Jonathan West wrote:
> Hello,
>
> I'm not sure if platform is the correct group for Team related questsions,
> but I think so.
> If I'm wrong please tell me which group is correct.
>
> As a part of an ongoing assigment I will start using Eclipse with a source
> repository
> (Subversion). I have done some testing and I guess it is best if not all
> files are
> actually placed under source control (all compiler generated files are
> ignored already)
>
> The Eclipse projects that I will place under source control are both Java
> Projects
> and Plug-in projects.
>
> My assumption is that I should not add the .classpath file and not the
> directory .setting
> (we do not allow settings on project level - all project ineherits from
> workspace settings)
>
> I'm I correct in my assumptions and are there any more files to exclude?
As Norbert already said, you definitely want to include the .classpath
and .project files - those define the project for Eclipse and without
them each workspace that checks out the project will have to define the
project again. You also generally want to check in ALL files that are
not derived (Eclipse will automatically exclude derived files for you if
you're using CVS, so I'd expect it to do the same for SVN).
As for the .settings, the reason it is stored in the project is actually
to support sharing it via source control. If the settings are specified
on a per-project basis, then whenever someone checks out that project he
will automatically get those settings applied. Otherwise you have to
hope and enforce that every developer make his workspace settings
exactly the same as everyone else. What about developers that maintain
multiple workspaces - that becomes a pain. There is no way to enforce
that, either. Project-specific settings were designed to solve the
problem by allowing them to live with the project and be checked in.
Hope this helps,
Eric
|
|
|
Powered by
FUDForum. Page generated in 0.03479 seconds
Home