Re: best practices - .settings and version control
Re: best practices - .settings and version control
- Subject: Re: best practices - .settings and version control
- From: TW <email@hidden>
- Date: Mon, 9 Feb 2009 13:57:18 -0800
On Feb 9, 2009, at 1:39 PM, Lachlan Deck wrote:
On 10/02/2009, at 6:33 AM, Chuck Hill wrote:
On Feb 2, 2009, at 7:03 PM, TW wrote:
When working with Eclipse/WOLips and version control what is
considered best practice for the proj-dir/.settings/* files? I've
had my .settings folder under version control and it seems like it
has been problematic for me. I'm just learning about patches in
git and it seems like frequent changes to
org.eclipse.core.resources.prefs really get in the way of creating
useful patches.
I realize most don't use git but I guess I'm wondering how
important it is to have files such as .settings/
org.eclipse.core.resources.prefs under version control.
Guess this one got lost. :-)
In a team environment, I'd say these are vital to maintaining
standards and preventing undesired changes. I don't see why there
would / should be frequent changes.
Well the annoying thing is whenever someone creates a component or
somehow triggers this file getting updated you get a conflict
because wolips is always inserting a timestamp at the top of the
file which differs from someone else's on the team (which is
unnecessary anyway as the file has it's own mod dates) in addition
to specifying the encoding of the component as UTF-8. I don't know
why they all need to be listed as UTF-8 when the parent already is?
Or is there some other setting that needs touching?
That's kind of what I'm seeing. At this point I'm a single developer
(works in so many ways) and I notice that when I switch between
branches where this file may have been touched I get conflicts I don't
need or want. For giggles, I actually deleted the .settings directory
from one version of a project and that had no ill effects on the
project. I can always restore that version but I was interested to see
what would happen. Maybe someone knows of some impending doom from
deleting it?
T
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden