I used -s, but in combination with -r 35000 or so (only export revisions
after...). It's a little overkill for me since I rarely actually modify
anything in GeoTools, but I had to read the man page for GeoServer anyway...
Full command is:
git svn clone https://codehaus.org/geotools/ --stdlayout -r 35000
Having all the branches in one git repo is also nice because I can use
cherry-pick or rebase to port changes between branches. If you don't like
git's merge process then there's less of an argument for doing it this way.
--
David Winslow
OpenGeo - http://opengeo.org/
On Wed, Sep 1, 2010 at 8:22 AM, Justin Deoliveira <[email protected]>wrote:
> I definitely don't use "-s" because that forces init to consider a standard
> branch layout and will import all tags/branches which takes forever.
>
>
> On Tue, Aug 31, 2010 at 9:48 AM, Jody Garnett <[email protected]>wrote:
>
>> When you guys init do you use -s ?
>>
>> I also found on on mac that "git-svn" is actually "git svn"
>>
>> Jody
>>
>> On 31/08/2010, at 11:29 PM, Justin Deoliveira wrote:
>>
>> > This is how i manage my git repo as well. I have cloned fhe stable
>> branch as well for the purposes of client specific work and it works well
>> too.
>> >
>> >
>> >
>> > On Aug 31, 2010, at 2:55 AM, Andrea Aime <[email protected]> wrote:
>> >
>> >> Ben Caradoc-Davies ha scritto:
>> >>> Andrea and Justin,
>> >>> do you use a single "git svn init" command for the whole geotools repo
>> or do you use "git svn init" once for each branch? What pattern do you find
>> works best for geotools trunk development and branch maintenance?
>> >>
>> >> What I did so far was to checkout only trunk, and then create a slew
>> >> of feature branches every time I'm working/experimenting on something.
>> >> Once I'm satisfied I merge back with "master" and commit to the svn
>> repo.
>> >>
>> >> The stable branch I still manage with svn, mostly doing "svn merge ..."
>> >> from trunk.
>> >> Honestly I did not try out many alternatives as backporting to the
>> >> stable branch has become increasingly difficult due to the growing
>> >> difference between the two code bases (at least in the areas I normally
>> >> deal with), so I don't do that very often lately.
>> >>
>> >> Cheers
>> >> Andrea
>> >>
>> >> --
>> >> Andrea Aime
>> >> OpenGeo - http://opengeo.org
>> >> Expert service straight from the developers.
>> >
>> >
>> ------------------------------------------------------------------------------
>> > This SF.net Dev2Dev email is sponsored by:
>> >
>> > Show off your parallel programming skills.
>> > Enter the Intel(R) Threading Challenge 2010.
>> > http://p.sf.net/sfu/intel-thread-sfd
>> > _______________________________________________
>> > Geotools-devel mailing list
>> > [email protected]
>> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
