cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Discuss: Switching cxf to git
Date Thu, 23 Jan 2014 18:05:54 GMT

On Jan 22, 2014, at 9:30 AM, Daniel Kulp <dkulp@apache.org> wrote:

> 
> 
> 2) I’d LIKE to rebuild the git repo and possibly remove all the /incubator revisions
and tags.  Kind of “start” at the graduation.  Maybe a bit before at the 2.0-incubator
release.   Or at least all the “lib” dirs out of them.   That would chop about 100MB out
of the .git directory making it a LOT smaller.   The original codebase kept .jar files in
the repo which sucks with git.   I’m really not sure how much of the history and tags from
2005/2006 is at all important anymore so this is likely not a big deal.   Plus, the history
is still in SVN if we really need it.

I played with this a little bit last night.   If I use the commit where we did the “maven
release:prepare” for 2.1 (first major release out of the incubator) as the base for a graft
point and removed the 2.0.x tags and branches (they’ll still exist in SVN if we ever need
them) and the “celtix” tag from prior to doing the changes from celtix -> CXF, and
then do a:

git filter-branch --prune-empty --tag-name-filter cat -- --all

(takes a couple hours to run)

to clean up the branches and remove all the “empty commits” which are created when the
svn properties are updated for the merges and such, the “.git” dir drops from about 150MB
down to 51MB.  Also, the “git log 2.7.x-fixes” looks better without all the “blocked
XYX” commits and such.     If created a test repo at my github account:

https://github.com/dkulp/cxf-test

if you want to clone it and take a look at the various branches and tags and such.   

If we decide to move to git (which I don’t see any objections so far), I would propose that
we use that process as the starting point for the official git repo instead of taking the
full svn dump version we have right now on the mirror.   It’s a bit smaller and cleaner.

The downside is for the files that have existed since 2.1, a “git blame” and log and such
will only go back to 2.1.   Blame will list me as the person for any lines that have existed
since 2.1 (since I did the “release:prepare” for 2.1 and all the commits prior to that
are squashed up into there).    We could go back a little further than 2.1 if we feel it’s
overly important.  Or, we could even move up to 2.2 or later if we feel it’s not at all
important.   :-)


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message