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 <[email protected]
<mailto:[email protected]>> 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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
>
>
