Hi,
the WMS cascading work is about to start, we'll need a place
where multiple people can share their work.
Options:
- work directly on trunk.
Upsides: it's easy, requires no extra setup/software
Downsides: it might result in breakages of trunk
- create a branch
Upsides: requires no extra setup
Downsides: we're playing against a svn 1.4.6 server
meaning we'd have to be careful about what
we do, possibly by working on the branch
for some time and then manually merging
with trunk with whatever conflicts might arise
- use git, github and git-svn
Upsides: we could have both our private working space and
a shared branch on github to play and share
Downsides: new software, new way of doing stuff
Another issue with github is that I'm not sure how to play
with it.
Like, how do we keep that clone up to date vrt svn? Afaik it's
a manual process.
Also making a full clone of the svn history seems to be quite
painful, I've tried but eventually gave up a few hours later.
Making a "shallow" clone with only the last thousand revisions
out of svn does not look so bad though.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Trunk is open for new development; any idea on the time frame for WMS cascade work? Do we have any need to release from trunk prior to FOSS4G (ie early July deadline).
I do like the idea of trying out GIT on a "shared branch" like this. It would give us a chance to learn.
Aside: Jesse took a long time to make a GIT repository from udig svn; you may want to ask him for details and set expectations accordingly.
Jody
On 29/04/2010, at 12:45 AM, Andrea Aime wrote:
Hi,
the WMS cascading work is about to start, we'll need a place
where multiple people can share their work.
Options:
- work directly on trunk.
Upsides: it's easy, requires no extra setup/software
Downsides: it might result in breakages of trunk
- create a branch
Upsides: requires no extra setup
Downsides: we're playing against a svn 1.4.6 server
meaning we'd have to be careful about what
we do, possibly by working on the branch
for some time and then manually merging
with trunk with whatever conflicts might arise
- use git, github and git-svn
Upsides: we could have both our private working space and
a shared branch on github to play and share
Downsides: new software, new way of doing stuff
Another issue with github is that I'm not sure how to play
with it.
Like, how do we keep that clone up to date vrt svn? Afaik it's
a manual process.
Also making a full clone of the svn history seems to be quite
painful, I've tried but eventually gave up a few hours later.
Making a "shallow" clone with only the last thousand revisions
out of svn does not look so bad though.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I have become quite a proponent of git these days, i use it for all local development and for branch development nothing beats it. The reason being the rebasing. A few more comments inline.
On 4/28/10 8:49 AM, Jody Garnett wrote:
Trunk is open for new development; any idea on the time frame for WMS cascade work? Do we have any need to release from trunk prior to FOSS4G (ie early July deadline).
I do like the idea of trying out GIT on a "shared branch" like this. It would give us a chance to learn.
Aside: Jesse took a long time to make a GIT repository from udig svn; you may want to ask him for details and set expectations accordingly.
Jody
On 29/04/2010, at 12:45 AM, Andrea Aime wrote:
Hi,
the WMS cascading work is about to start, we'll need a place
where multiple people can share their work.
Options:
- work directly on trunk.
Upsides: it's easy, requires no extra setup/software
Downsides: it might result in breakages of trunk
- create a branch
Upsides: requires no extra setup
Downsides: we're playing against a svn 1.4.6 server
meaning we'd have to be careful about what
we do, possibly by working on the branch
for some time and then manually merging
with trunk with whatever conflicts might arise
- use git, github and git-svn
Upsides: we could have both our private working space and
a shared branch on github to play and share
Downsides: new software, new way of doing stuff
Another issue with github is that I'm not sure how to play
with it.
Like, how do we keep that clone up to date vrt svn? Afaik it's
a manual process.
That is what I have been doing with my repository clones of geotools and geoserver on github. And since everyone would probably be keeping there own copies a manual process might not be too cumbersome.
Also making a full clone of the svn history seems to be quite
painful, I've tried but eventually gave up a few hours later.
Making a "shallow" clone with only the last thousand revisions
out of svn does not look so bad though.
Yeah, I only cloned the branch I cared about and it seemed to work ok. Ie just trunk for one repo, and just 2.0.x for another repo.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Something to keep in mind is that git's svn integration can't push "merge commits" (ie, where two git branches join back together, something that should come up a lot in collaborative situation) from git to SVN. You *can* have as many branches off of a SVN source tree as you want, but you will need to untangle your history before pushing it to SVN. Git provides some tools (rebase) to allow you to do this, but it's not very automatic.
Another option (and I think Justin has said he's doing this) would be to generate a patch equivalent to the work done on the branch and commit it using the usual tools; ie, only use git to pull things *from* svn, not to push back to it.
(Disclaimer: While I, too, have been doing some work on a git-svn clone of GeoServer trunk, I haven't gotten around to actually doing any commits back to SVN yet.)
-d
On 04/29/2010 10:41 AM, Justin Deoliveira wrote:
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it. The
reason being the rebasing. A few more comments inline.
On 4/28/10 8:49 AM, Jody Garnett wrote:
Trunk is open for new development; any idea on the time frame for WMS cascade work? Do we have any need to release from trunk prior to FOSS4G (ie early July deadline).
I do like the idea of trying out GIT on a "shared branch" like this. It would give us a chance to learn.
Aside: Jesse took a long time to make a GIT repository from udig svn; you may want to ask him for details and set expectations accordingly.
Jody
On 29/04/2010, at 12:45 AM, Andrea Aime wrote:
Hi,
the WMS cascading work is about to start, we'll need a place
where multiple people can share their work.
Options:
- work directly on trunk.
Upsides: it's easy, requires no extra setup/software
Downsides: it might result in breakages of trunk
- create a branch
Upsides: requires no extra setup
Downsides: we're playing against a svn 1.4.6 server
meaning we'd have to be careful about what
we do, possibly by working on the branch
for some time and then manually merging
with trunk with whatever conflicts might arise
- use git, github and git-svn
Upsides: we could have both our private working space and
a shared branch on github to play and share
Downsides: new software, new way of doing stuff
Another issue with github is that I'm not sure how to play
with it.
Like, how do we keep that clone up to date vrt svn? Afaik it's
a manual process.
That is what I have been doing with my repository clones of geotools and
geoserver on github. And since everyone would probably be keeping there
own copies a manual process might not be too cumbersome.
Also making a full clone of the svn history seems to be quite
painful, I've tried but eventually gave up a few hours later.
Making a "shallow" clone with only the last thousand revisions
out of svn does not look so bad though.
Yeah, I only cloned the branch I cared about and it seemed to work ok.
Ie just trunk for one repo, and just 2.0.x for another repo.
Opinions?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Something to keep in mind is that git's svn integration can't push "merge commits" (ie, where two git branches join back together, something that should come up a lot in collaborative situation) from git to SVN. You *can* have as many branches off of a SVN source tree as you want, but you will need to untangle your history before pushing it to SVN. Git provides some tools (rebase) to allow you to do this, but it's not very automatic.
Another option (and I think Justin has said he's doing this) would be to generate a patch equivalent to the work done on the branch and commit it using the usual tools; ie, only use git to pull things *from* svn, not to push back to it.
(Disclaimer: While I, too, have been doing some work on a git-svn clone of GeoServer trunk, I haven't gotten around to actually doing any commits back to SVN yet.)
I actually made one already, revision 14285, 14286, but I was working
directly out of master, did a "git svn rebase" and then a "git svn dcommit" and it worked.
I just forgot to squash the changes so you see two revision instead of
one.
If you are working on a feature branch instead... I'm not sure what to
do... "git merge --squash" and then "git svn rebase"?
Would that be sufficient?
I saw tutorials around but I haven't fully wrapped my head around them.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Yes, “git merge --squash” does the trick there (although it doesn’t commit to the local repository, so you should follow it up with a normal “git commit”. I wasn’t sure of this so I took a few screenshots of gitk while I was working on my stuff this evening.
My repo had three feature branches, zoom-disentanglement, z-indexing, and codemirror. z-indexing was actually forked from zoom-disentanglement since the work on that branch had involved some useful refactoring. I hadn’t published the changes yet since they had resulted in some test failures.
I switched to the master branch and ran “git svn rebase” to get the latest changes into my repo.
Then I used “git rebase master zoom-disentanglement; git rebase master z-indexing” to rewrite history as if I had done the work on those branches after the lastest from SVN.
Then I ran my test suite, did some debugging, and and fixed that last test failure. I was getting ready to try out “git merge --squash”, so I added an extra “placeholder” branch to hang onto z-indexing, just in case I rewrote the branch in an unexpectedly destructive way.
Switching to master and running “git merge --squash” did exactly what I expected though, so I was able to “git commit; git svn dcommit” without hassle. My ‘placeholder’ branch turned out to be unnecessary since git merge --squash doesn’t modify the branch where the changes are coming from.
I dunno if this will be more helpful than the tutorials you’ve already looked at, but the short answer is yes, “git merge --squash” is the way to go.
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it.
I have seen the git header in your patches.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it.
I have seen the git header in your patches.
I have to second Justin's opinion. I have been working with GIT
for the last 2-3 big patches and I'm quite impressed, development
of a big change gets much more fluid. I also have the impression
it generates less conflicts than SVN when merging other changes
on top (actually, on the back) of the ongoing work.
I still find it overkill for small, 2 hours work patches, but
for anything bigger, warmly recommended as a SVN client replacement.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it.
I have seen the git header in your patches.
I have to second Justin's opinion. I have been working with GIT
for the last 2-3 big patches and I'm quite impressed, development
of a big change gets much more fluid. I also have the impression
it generates less conflicts than SVN when merging other changes
on top (actually, on the back) of the ongoing work.
I still find it overkill for small, 2 hours work patches, but
for anything bigger, warmly recommended as a SVN client replacement.
I am not sure if you have found this yet but check out "git stash". It is priceless if you want to switch back and forth between different changesets on a single branch. A real time saver id you don't want to incur of the overhead of creating a branch to make a change.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
I have become quite a proponent of git these days, i use it for all
local development and for branch development nothing beats it.
I have seen the git header in your patches.
I have to second Justin's opinion. I have been working with GIT
for the last 2-3 big patches and I'm quite impressed, development
of a big change gets much more fluid. I also have the impression
it generates less conflicts than SVN when merging other changes
on top (actually, on the back) of the ongoing work.
I still find it overkill for small, 2 hours work patches, but
for anything bigger, warmly recommended as a SVN client replacement.
I am not sure if you have found this yet but check out "git stash". It is priceless if you want to switch back and forth between different changesets on a single branch. A real time saver id you don't want to incur of the overhead of creating a branch to make a change.
Ah ha, no, I did not find it. Used it this morning though, I had an
unfinished change I did not want to commit on the wms-cascade local
branch, stashed it, went back to master, svn rebased, back to the banch,
rebased it as well, and applied the stash back.
Nice, this way I'm not forced to commit an unfinished work just to
grab changes from svn
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
