Re: [DISCUSS] move jUDDI from SVN to Git?

[Kurt T Stam <ku...@gmail.com>]

Hi guys,

IT has set up a *Git mirror* for us: http://git.apache.org/, which will 
be mirrored on GitHub. SVN is still the SCM of record; there mirrors are 
READ ONLY, but they allow the following workflow:

(as described on http://www.apache.org/dev/git.html)


  Proposed workflow

This is a proposed workflow for using Git with an Apache codebase. This 
workflow is mainly targeted to contributors who don't already have 
commit access to a project.

Once you have cloned or pulled the latest changes to your local Git 
repository of an Apache codebase, you can start working on it. Whenever 
you make some changes to the codebase, it's good to have a related issue 
filed in the issue tracker of the project and to use a similarly named 
branch in your Git repository. For example, to create a branch for an 
issue with the key TIKA-123.

|git branch TIKA-123 origin/trunk|

With per-issue branches you can easily switch back and forth between 
different issues without worrying about unwanted side-effects from 
unfinished changes to other issues. Whenever you want to work on the 
TIKA-123 example issue, simply checkout that branch and start making 
your changes.

|git checkout TIKA-123|

It's a good idea to commit your changes whenever you have finished one 
logical part of the issue. For example when refactoring, make a new 
commit for each refactoring step you take.

|git commit|

Once you're ready to share your changes with the rest of the project 
team, you can use the git format-patch command to produce a nice set of 
patches to attach to the relevant issue.

|git format-patch origin/trunk|

The sooner you share your work the better. You can repeat the steps of 
this workflow as often as you like, producing more patches to be 
attached to the issue tracker. Once some of your patches are accepted 
and committed to svn, you can rebase your work against the latest trunk. 
Alternatively, if you're asked to make some changes, you can go back to 
the original Git commit and modify it until the project team accepts 
your changes.


Cheers,

--Kurt

On 3/6/13 7:58 AM, Anil Saldhana wrote:
> git seems to attract contributions from volunteers (at least github) 
> on a slightly higher rate than svn.
>
>
> On Mar 5, 2013, at 9:53 PM, Jesse Sightler <jesse.sightler@gmail.com 
> <ma...@gmail.com>> wrote:
>
>> The whole offline advantage of git is largely irrelevant, IMO. The 
>> big win is the improved workflow. It is far easier to make large 
>> patches via the git/github model and submit via pull-requests than 
>> via patches attached to a bug entry. I've done this quite a few times 
>> over the past year, and github really is a huge win here, IMO.
>>
>>
>>
>> On Tue, Mar 5, 2013 at 7:09 PM, Alex O'Ree <spyhunter99@gmail.com 
>> <ma...@gmail.com>> wrote:
>>
>>     I personally prefer svn. I don't "git" it. What are the requirement
>>     for version control besides...well, version control in the context of
>>     jUDDI? Git is handy for getting the complete version history offline,
>>     but that point is pretty moot considering half of the internet is
>>     downloaded during the maven build process. It's a bit faster for
>>     certain actions and its useful for localized version control. SVN's
>>     advantage is that it is integrated with just about everything out
>>     there for software development. Just my two cents. I'll use whatever
>>     the rest of you all want
>>
>>     On Tue, Mar 5, 2013 at 5:52 PM, Jesse Sightler
>>     <jesse.sightler@gmail.com <ma...@gmail.com>> wrote:
>>     > I hope this happens... I think it would be very good for the
>>     project.
>>     >
>>     >
>>     > On Tue, Mar 5, 2013 at 5:32 PM, Kurt T Stam
>>     <kurt.stam@gmail.com <ma...@gmail.com>> wrote:
>>     >>
>>     >> Hi guys,
>>     >>
>>     >> What do you think about moving our repo from svn to git? Once
>>     it's on
>>     >> git.apache.org <http://git.apache.org> we can mirror it on
>>     github, and it will make it much easier
>>     >> for people to contribute code, even if they are not (yet)
>>     committers on the
>>     >> project.
>>     >>
>>     >> --Kurt
>>     >
>>     >
>>
>>