From: Jody G. <jod...@gm...> - 2012-05-25 02:17:41
|
Been trying this out with google summer of code students - in addition to being a front end it is a much easier way to install everything for windows (it keeps the command line tools up to date etc…). Reading: - https://github.com/blog/1127-github-for-windows - http://arstechnica.com/information-technology/2012/05/hands-on-github-for-windows-takes-the-pain-out-of-using-git/ Link: - http://windows.github.com/ Mac version from last year: - http://mac.github.com/ I think most of our core team is happy with git these days; how about we schedule the migration after GeoTools 8.0 is released? -- Jody Garnett |
From: Ben Caradoc-D. <Ben...@cs...> - 2012-05-25 03:57:00
|
On 25/05/12 10:17, Jody Garnett wrote: > I think most of our core team is happy with git these days; how about we schedule the migration after GeoTools 8.0 is released? +1. At this point I must admit to being somewhat of a git n00b. While I have been using git for local branches, almost all of my remote repositories have been subversion, accessed with git-svn. I have been sheltered therefore by the GeoTools project subversion config from addressing things like git line ending issues. What local settings should GeoTools developers use to ensure correct behaviour on all platforms? Do I need to: $ git config --global core.autocrlf true This might rely on the content of the repository. Sample discussions: http://help.github.com/line-endings/ http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git Do we need to manipulate the subversion repository as it is migrated to git to ensure there are no text files containing CRLF line endings? Are there any other subversion properties whose absence will be missed when we migrate to git? Any other advice from git frequent fliers? (Justin and Gabriel?) Kind regards, -- Ben Caradoc-Davies <Ben...@cs...> Software Engineer CSIRO Earth Science and Resource Engineering Australian Resources Research Centre |
From: Michael B. <mic...@gm...> - 2012-05-25 04:55:22
|
On 25 May 2012 13:56, Ben Caradoc-Davies <Ben...@cs...> wrote: > Are there any other subversion properties whose absence will be missed > when we migrate to git? > We lose the svn source and URL keywords. The source keyword is used by the GeoTools javadoc plugin to add the module information at the top of the javadoc page for each class. I believe I said that I would rework the javadoc plugin to use the location of files in the source tree directly. I don't believe I've done this yet. Michael |
From: Justin D. <jde...@op...> - 2012-05-25 12:48:41
|
Funny you bring this up Ben. We use git for some internal projects and have developers on windows that recently ran into this issue and it was a real pita. Although it was fine up until a developer has to actually be able to commit just one file with crlf endings, a windows .cmd file that seemed to require it. Here is what i have learned. core.autocrlf = true or core.autocrlf = input seems to generally be pretty safe core.safecrlf = true is useful for folks on windows and will let them know if they are about to commit line ending changes. Some useful posts about this. http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git http://stackoverflow.com/questions/4181870/git-on-windows-what-do-the-crlf-settings-mean On Thu, May 24, 2012 at 9:56 PM, Ben Caradoc-Davies < Ben...@cs...> wrote: > On 25/05/12 10:17, Jody Garnett wrote: > >> I think most of our core team is happy with git these days; how about we >> schedule the migration after GeoTools 8.0 is released? >> > > +1. > > At this point I must admit to being somewhat of a git n00b. While I have > been using git for local branches, almost all of my remote repositories > have been subversion, accessed with git-svn. I have been sheltered > therefore by the GeoTools project subversion config from addressing things > like git line ending issues. > > What local settings should GeoTools developers use to ensure correct > behaviour on all platforms? Do I need to: > > $ git config --global core.autocrlf true > > This might rely on the content of the repository. > > Sample discussions: > http://help.github.com/line-**endings/<http://help.github.com/line-endings/> > http://stackoverflow.com/**questions/2825428/why-should-** > i-use-core-autocrlf-true-in-**git<http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git> > > Do we need to manipulate the subversion repository as it is migrated to > git to ensure there are no text files containing CRLF line endings? > > Are there any other subversion properties whose absence will be missed > when we migrate to git? > > Any other advice from git frequent fliers? (Justin and Gabriel?) > > Kind regards, > > -- > Ben Caradoc-Davies <Ben...@cs...> > Software Engineer > CSIRO Earth Science and Resource Engineering > Australian Resources Research Centre > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
From: Justin D. <jde...@op...> - 2012-05-25 12:53:03
|
Oh and yes I am a +1 on switching over to git. Things i think we want/need before a full switch. * a quick primer for people with sample commands for common tasks * a list of git does and donts, ie don't rebase on a public branch, etc... * line endings figured out re Bens comment * a way to get git revision info from the build... we currently have an svn plugin that does this but no git equivalent, there is a plugin but it turned out to be pretty flaky so we ditched it * decide on hosting, are we ok with github? Can't think of much else right now. On Fri, May 25, 2012 at 6:48 AM, Justin Deoliveira <jde...@op...>wrote: > Funny you bring this up Ben. We use git for some internal projects and > have developers on windows that recently ran into this issue and it was a > real pita. Although it was fine up until a developer has to actually be > able to commit just one file with crlf endings, a windows .cmd file that > seemed to require it. Here is what i have learned. > > core.autocrlf = true or core.autocrlf = input seems to generally be pretty > safe > core.safecrlf = true is useful for folks on windows and will let them know > if they are about to commit line ending changes. > > Some useful posts about this. > > > http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git > > http://stackoverflow.com/questions/4181870/git-on-windows-what-do-the-crlf-settings-mean > > On Thu, May 24, 2012 at 9:56 PM, Ben Caradoc-Davies < > Ben...@cs...> wrote: > >> On 25/05/12 10:17, Jody Garnett wrote: >> >>> I think most of our core team is happy with git these days; how about we >>> schedule the migration after GeoTools 8.0 is released? >>> >> >> +1. >> >> At this point I must admit to being somewhat of a git n00b. While I have >> been using git for local branches, almost all of my remote repositories >> have been subversion, accessed with git-svn. I have been sheltered >> therefore by the GeoTools project subversion config from addressing things >> like git line ending issues. >> >> What local settings should GeoTools developers use to ensure correct >> behaviour on all platforms? Do I need to: >> >> $ git config --global core.autocrlf true >> >> This might rely on the content of the repository. >> >> Sample discussions: >> http://help.github.com/line-**endings/<http://help.github.com/line-endings/> >> http://stackoverflow.com/**questions/2825428/why-should-** >> i-use-core-autocrlf-true-in-**git<http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git> >> >> Do we need to manipulate the subversion repository as it is migrated to >> git to ensure there are no text files containing CRLF line endings? >> >> Are there any other subversion properties whose absence will be missed >> when we migrate to git? >> >> Any other advice from git frequent fliers? (Justin and Gabriel?) >> >> Kind regards, >> >> -- >> Ben Caradoc-Davies <Ben...@cs...> >> Software Engineer >> CSIRO Earth Science and Resource Engineering >> Australian Resources Research Centre >> > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
From: Jody G. <jod...@gm...> - 2012-05-28 01:37:04
|
Thanks for the checklist Justin: I have made the change proposal (something for us to consider after GeoTools 8 is released). - http://docs.codehaus.org/display/GEOTOOLS/Transition+to+GitHub - https://jira.codehaus.org/browse/GEOT-4156 While I have included your checklist; and outlined some tasks for migration; we need a few more eyes on the problem so we know what work is involved. Aside: Confluence 4 has moved away from textile; and is a bit crazy to use. I expect our remaining wiki use will suffer quick bit rot as a result. -- Jody Garnett On Friday, 25 May 2012 at 10:52 PM, Justin Deoliveira wrote: > Oh and yes I am a +1 on switching over to git. Things i think we want/need before a full switch. > > * a quick primer for people with sample commands for common tasks > * a list of git does and donts, ie don't rebase on a public branch, etc... > * line endings figured out re Bens comment > * a way to get git revision info from the build... we currently have an svn plugin that does this but no git equivalent, there is a plugin but it turned out to be pretty flaky so we ditched it > * decide on hosting, are we ok with github? > > Can't think of much else right now. > > On Fri, May 25, 2012 at 6:48 AM, Justin Deoliveira <jde...@op... (mailto:jde...@op...)> wrote: > > Funny you bring this up Ben. We use git for some internal projects and have developers on windows that recently ran into this issue and it was a real pita. Although it was fine up until a developer has to actually be able to commit just one file with crlf endings, a windows .cmd file that seemed to require it. Here is what i have learned. > > > > core.autocrlf = true or core.autocrlf = input seems to generally be pretty safe > > core.safecrlf = true is useful for folks on windows and will let them know if they are about to commit line ending changes. > > > > Some useful posts about this. > > > > http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git > > http://stackoverflow.com/questions/4181870/git-on-windows-what-do-the-crlf-settings-mean > > > > On Thu, May 24, 2012 at 9:56 PM, Ben Caradoc-Davies <Ben...@cs... (mailto:Ben...@cs...)> wrote: > > > On 25/05/12 10:17, Jody Garnett wrote: > > > > I think most of our core team is happy with git these days; how about we schedule the migration after GeoTools 8.0 is released? > > > > > > +1. > > > > > > At this point I must admit to being somewhat of a git n00b. While I have been using git for local branches, almost all of my remote repositories have been subversion, accessed with git-svn. I have been sheltered therefore by the GeoTools project subversion config from addressing things like git line ending issues. > > > > > > What local settings should GeoTools developers use to ensure correct behaviour on all platforms? Do I need to: > > > > > > $ git config --global core.autocrlf true > > > > > > This might rely on the content of the repository. > > > > > > Sample discussions: > > > http://help.github.com/line-endings/ > > > http://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git > > > > > > Do we need to manipulate the subversion repository as it is migrated to git to ensure there are no text files containing CRLF line endings? > > > > > > Are there any other subversion properties whose absence will be missed when we migrate to git? > > > > > > Any other advice from git frequent fliers? (Justin and Gabriel?) > > > > > > Kind regards, > > > > > > -- > > > Ben Caradoc-Davies <Ben...@cs... (mailto:Ben...@cs...)> > > > Software Engineer > > > CSIRO Earth Science and Resource Engineering > > > Australian Resources Research Centre > > > > > > > > -- > > Justin Deoliveira > > OpenGeo - http://opengeo.org > > Enterprise support for open source geospatial. > > > > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > |