www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: Best Practices so far?
Date Fri, 02 May 2008 10:12:24 GMT
El vie, 02-05-2008 a las 04:56 -0400, Davanum Srinivas escribió:
> Hash: SHA1
> Cool. Next steps to complete one scenario (helping new contributors contribute)

I just answered partially several of these questions in a separate email

> - - Suppose i am a prospective committer. How do i make a patch available for review?
(what needs to be mentioned in a
> JIRA issue)

See how I did it for SHINDIG-146, for instance, I prepared 3 different
patches, as described in my other email. One with 4X commits in a format
that was easy to read (move detection), another with those changes in
just one diff (for humans), and another for robots (the humans are dead,
I sniffed one, definitely is dead
http://www.youtube.com/watch?v=WGoi1MSGu64 )

git format-patch -M -C --stdout synd-rename-3 --not master >NAME.patch
would get it going, -M is move detection, -C is copy detection, so those
are removed for "robots" (patch)

The "humans" patches could easily be omitted if a gitweb server is
available with the issue code as a branch, as their goal is to use
move/copy detection to simplify reading files renamed with only a few
class or package name references changed.

> - - Switching roles, how does an existing committer, pull the patch and give it a whirl?
(before i check it into Apache 
> SVN).

See the other email: basically git-am
JIRA-PATCH-GENERATED-WITH-git-format-patch will commit it (better in a
branch) where it can be looked into or even merged partially with trunk
before applying.

> - - Finally, how do i get this patch from git to svn? with enough information about the
JIRA issue etc.

I did "git svn dcommit" a number of times, biggest were SHINDIG-146 and
one for the site with a lot of generated html. It works as a normal
commit, but it applies (at least in my setup, not 100% sure about it)
move/copy detection automatically. git does not store deltas, but whole
trees, so there is no way that git knows about files moves or copied,
and the way git-svn propagates the changeset upstream implies move/copy
detection. This could be tuned somehow in git-svn, I guess.
Re: keeping issue references, I just used the name in the commit log, I
guess something better could be done, but I'm not sure we can do
something better than now.

Note I tweaked the gitweb install I did in p.a.o to detect SHINDIG-\d+
and turn it into a link to jira. My perl is rusty but I still was able
to do a oneliner like this one. Not so much as to be able to loop it on
all the live-and-changing JIRA projects.

> thanks,
> dims
> Jukka Zitting wrote:
> | Hi,
> |
> | On Fri, May 2, 2008 at 11:22 AM, Davanum Srinivas <davanum@gmail.com> wrote:
> |> So, what's the learning so far? Example how does one set up a git-svn for a
> |> specific Apache project?
> |
> | I've cloned a few smaller projects like this:
> |
> |     git svn clone -s http://svn.apache.org/repos/asf/incubator/<project>
> |
> | So far I've avoided doing that with TLPs because of the load on the
> | svn server, but now that svn.eu.apache.org is in place I'm running the
> | following:
> |
> |     git svn clone -s http://svn.eu.apache.org/repos/asf/jackrabbit
> |
> | Note that these clones take quite a while (hours) to create, but after
> | that it's quite easy and fast to keep them up to date with latest
> | changes.
> |
> | So far I've used these clones for quick browsing and comparing of
> | version histories, my actual working copies are still normal svn
> | checkouts (mostly due to IDE integration). Thus I haven't yet used
> | things like dcommit on Apache projects.
> |
> | BR,
> |
> | Jukka Zitting
> Version: GnuPG v1.4.5 (Cygwin)
> iD8DBQFIGtcygNg6eWEDv1kRAn/3AJ9ckGQ7X2UzFHt/xKAudcckWDBlpACfVqZ7
> jmPv88B4MrFj8B3U8hXBPPY=
> =uXEK
Santiago Gala

View raw message