cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Discuss: Switching cxf to git
Date Mon, 27 Jan 2014 09:17:45 GMT
I just cloned and checked out some of the tags and branches from 
cxf-test. I think it looks pretty good now.
Should we do an official vote about the switch or can we already 
consider this discussion a consensus?

The other question is when to switch. I am in no hurry to do so. From my 
side after the 3.0.0-m2 sounds like a good date. It there anything I can 
help with? Perhaps coordinate with infra or do you want to do this Dan?


On 24.01.2014 15:35, Daniel Kulp wrote:
> On Jan 24, 2014, at 1:18 AM, Thorsten Höger <> wrote:
>> Some comments after playing around with the test repo:
>> - I can only see branches for 2.5.x, 2.6.x and 2.7.x. but 2.4 and before are missing
> Since we are not maintaining those versions anymore, there is no point in keeping the
branches around.   Really, the 2.5.x should go as well.    If we ever do need to “fix”
anything, we can create branches off the appropriate tag.
> ,
>> - there are no tags for released versions
> That was my fault.   Forgot to add “—tags” to the git push.  Keep forgetting that
the push/pull doesn’t do the tags as well.   :-(
> I just pushed them.  70 release tags.  Wow.    :-)
>> - maybe trunk should be renamed to master (git-style)
> Yea.   When we go “live”, we’d definitely do that.   This is just an experiment
at this point to make sure we can create a new git repo that is a bit better than the pure
svn dump version we’ve been using.
> Dan
>> Am 23.01.2014 19:05, schrieb Daniel Kulp:
>>> On Jan 22, 2014, at 9:30 AM, Daniel Kulp <> 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:
>>> if you want to clone it and take a look at the various branches and tags and
>>> 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
>>> 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.   :-)

Christian Schneider

Open Source Architect

View raw message