I'd be fine with 3.2 onward being Git and 3.0/3.1/2.x remaining in SVN (not read-only, as we may do patches, especially on 3.0 and 3.1). 6 GB is pretty impressive. I don't think I want to download that. Would take all night, if not more.
mrg On Thu, Apr 25, 2013 at 8:43 PM, Andrus Adamchik <[email protected]>wrote: > > > I guess I don't understand how having two git repos is useful. How do > commits get from the small one to the 'real' one? > > > > Or are you suggesting that we have the large one purely as an archive > which no-one ever looks at ever again? In which case I don't see the point > since we have svn to do exactly that. > > Yeah, I was talking about a read-only archive. And yes, existing SVN will > cover that. We can probably delete ported branches from SVN HEAD to reduce > confusion (of course they will still be in history). > > > The only (very minor) downside I see is that some tools out there (like > ohloh) will think that our project is "young again". Whether that is good > or bad, or we even care… > > I don't. > > Andrus > > > On Apr 25, 2013, at 8:17 PM, Aristedes Maniatis <[email protected]> wrote: > > > I guess I don't understand how having two git repos is useful. How do > commits get from the small one to the 'real' one? > > > > Or are you suggesting that we have the large one purely as an archive > which no-one ever looks at ever again? In which case I don't see the point > since we have svn to do exactly that. > > > > The only (very minor) downside I see is that some tools out there (like > ohloh) will think that our project is "young again". Whether that is good > or bad, or we even care... > > > > Ari > > > > > > On 26/04/13 10:12am, Andrus Adamchik wrote: > >> So essentially the question is whether we want 2 Git repos (a smaller > active repo and full history archive), or whether we want to keep the > archive in SVN. > >> > >> I am fine with the second approach if that helps with the migration. > Essentially this means limiting trunk to 3.0 commits and branches to 3.0 > and 3.1. If everyone ok with this, I will provide some guidance to David, > with specific rev numbers and branch names. > >> > >> Andrus > >> > >> > >> On Apr 25, 2013, at 6:45 PM, Aristedes Maniatis <[email protected]> > wrote: > >> > >>> On 26/04/13 8:35am, Andrus Adamchik wrote: > >>>> > >>>> On Apr 25, 2013, at 6:26 PM, Ari Maniatis (JIRA) <[email protected]> > wrote: > >>>> > >>>>> > >>>>> [ > https://issues.apache.org/jira/browse/INFRA-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13642306#comment-13642306] > >>>>> > >>>>> Ari Maniatis commented on INFRA-5936: > >>>>> ------------------------------------- > >>>>> > >>>>> If the git repository will end up being 6Gb, could we look at > reducing the size of the problem by eliminating some branches or discarding > history older than a certain age? > >>>> > >>>> I was thinking about that too. My current idea is to just create a > second repo for the current work, forking from a point where we switched to > Maven and dropped all the jar dependencies. And keeping the 6GB one for the > history. > >>> > >>> There is no clean way to do that. In fact the thing which stopped me > from moving from svn to git in my work was that git has no way to clone a > partial repository. > >>> > >>> So we could: > >>> > >>> * discard all branches older than 3.0 > >>> * discard all commits older than when we started work on 3.0 > >>> > >>> That would drastically reduce the size of the repo and the difficulty > of the migration. And really, how often do we look at blame? > >>> > >>> Personally I don't really care either way (I still like svn!), but 6Gb > will prevent a lot of people from contributing some small patch. > >>> > >>> Ari > >>> > >>> > >>> -- > >>> --------------------------> > >>> Aristedes Maniatis > >>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > >>> > >> > > > > -- > > --------------------------> > > Aristedes Maniatis > > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > >
