On Sun, Mar 17, 2013 at 8:37 PM, Alex Harui <aha...@adobe.com> wrote:
> So does this mean we picked a SCM technology that does not scale? N-years > down the road won't all of our other repos have tons of branches and enough > objects to add up to 240MB? What happens when new folks want to get the > code? > If you checkout the entire whiteboard in SVN today, the same problem applies. If we have access to create unlimited number of top level git repos, we wont have this problem. Unfortunately, we dont, so we have to live with this. Its not a problem with the SCM, but the way Apache Infra chose to implement it. We can chose to have our whiteboards on GitHub instead. Then everyone has the ability to create unlimited number of repos and unlimited branching. I am not sure if this would be acceptable with Apache policy. > > No Git user in the world has a project that large? We must be missing > something. Otherwise, all those who were proponents of Git and better > start > explaining how it scales for them. > > Not sure what this question is related to. There are no size limitations to git. > BTW, an SVN checkout of the Flex SDK used to take me 2.5 hours or more > sometimes because SVN is a dog and would time out a lot. But not having a > truly sparse checkout seems like a real problem. > > Is GitHub hosted on a CDN or mirrored somehow? Will this problem go away > once we get the GitHub mirrors of our Git repos up and running? > > I dont know how official GitHub mirrors are. And as I said we need to check if we can have whiteboards on github instead. Notice how no other Apache project has whiteboards in git. Perhaps the mentors can give us some direction here? Thanks, Om > > On 3/17/13 8:22 PM, "Om" <bigosma...@gmail.com> wrote: > > > On Mar 17, 2013 6:44 PM, "Frédéric THOMAS" <webdoubl...@hotmail.com> > wrote: > >>> > >>> That's problem is solved by applying this policy naming > >> > >> > >> Because in the withboard projects we don't use jira (at least the > moment) > > "bug/jira-#2342" doesn't work, "whiteboard/fthomas" is the same than > > "fthomas". > >> It goes beyond that, the pattern should be > > <UserNameProjectNameBranchName>, but it's still to risky to go by > > convention IMO. > >> > >> -Fred > > > > No one organizes it this way today in the whiteboard on SVN. You are > over > > complicating things :-) > > > > Whiteboards are like scratch pads where committers do work temporarily > > before moving them into appropriate repos. > > > > I believe branches for committers with sub folders for their individual > > projects should suffice. > > > > Thanks, > > Om > > > >> > >> -----Message d'origine----- From: Jose Barragan > >> Sent: Monday, March 18, 2013 2:33 AM > >> > >> To: dev@flex.apache.org > >> Subject: Re: Committers - preparing for Git > >> > >> That's problem is solved by applying this policy naming: > >> > >> master > >> develop > >> whiteboard/fthomas > >> whiteboard/cdutz > >> whiteboard/mclean > >> feature/add-maven-descriptor > >> feature/add-installer-fp-download > >> feature/add-fp-download > >> bug/jira-#2342 > >> > >> ... > >> using nominal branches, which are structured to manage virtual folders > >> > >> > >> -- > >> Jose Barragan > >> Chief Software Architect > >> Codeoscopic Madrid > >> C/. Infanta Mercedes, 92. > >> Planta 5. 505. > >> 28020 Madrid. > >> Tel.: +34 912 94 80 80 > >> > >> On Mar 18, 2013, at 2:21 AM, Frédéric THOMAS <webdoubl...@hotmail.com> > > wrote: > >> > >>>> can really get quickly messy, I wouldn't take this risk. > >>> > >>> > >>> Again, if folks have several projects and those projects several > > branches as it common using GIT, without strict maming convention, the > list > > of the branches which can grow a lot will mess the people to retreive > even > > their own branch, imagine : > >>> > >>> fthomas > >>> cdutz > >>> mclean > >>> feature_add_maven_descriptor > >>> feature_add_installer_fp_download > >>> feature_add_fp_download > >>> > >>> Can you say for sure from those branches, which ones goes with which > > user/project ? > >>> > >>>> Why is this a better option? > >>> > >>> > >>> each one got its own space and can do whatever he wants. > >>> > >>>> I could live with leaving the whiteboard in SVN. > >>> > >>> > >>> Me too. > >>> > >>> -Fred > >>> > >>> -----Message d'origine----- From: Om > >>> Sent: Monday, March 18, 2013 2:06 AM > >>> To: dev@flex.apache.org > >>> Subject: Re: Committers - preparing for Git > >>> > >>> On Mar 17, 2013 5:56 PM, "Frédéric THOMAS" <webdoubl...@hotmail.com> > > wrote: > >>>> > >>>> > >>>> Hi, > >>>> > >>>> I agree with you Justin, each persons branch is a bad pratice, the > repo > >>> > >>> can really get quickly messy, I wouldn't take this risk. > >>> > >>> Describe 'messy', please. I am not sure what the concern is. > >>> > >>>> Maybe one repo by person is not feasible, how do we know without > asking > > ? > >>> > >>> > >>> Why is this a better option? > >>> > >>>> If it's not feasible, I would stay in SVN too and if I really want to > >>> > >>> work with GIT, I would use git-svn clone, it takes a bit of time to > setup > >>> but once done, it works like a charm. > >>>> > >>>> > >>> > >>> I could live with leaving the whiteboard in SVN. > >>> > >>> This is probably why no other project has whiteboards in git. > >>> > >>> Thanks, > >>> Om > >>> > >>>> > >>>> -Fred > >>>> > >>>> -----Message d'origine----- From: Justin Mclean > >>>> Sent: Monday, March 18, 2013 1:12 AM > >>>> > >>>> To: dev@flex.apache.org > >>>> Subject: Re: Committers - preparing for Git > >>>> > >>>> Hi, > >>>> > >>>>> I vote for creating a branch for each committer under whiteboard. > > Anyone > >>>>> else want to chime in? > >>>> > >>>> > >>>> By branch I assume you mean repo not sure if everyone having their own > >>> > >>> branch make sense as each persons branch would contain different files > > etc > >>> etc. > >>>> > >>>> > >>>> But currently using git for the white board area is basically unusable > >>> > >>> (unless you have high speed access) , so we either keep it in SVN or > > create > >>> repo for each committer however I'm not sure Infra would go for that > > second > >>> option. > >>>> > >>>> > >>>> Justin > >>> > >>> > >> > > -- > Alex Harui > Flex SDK Team > Adobe Systems, Inc. > http://blogs.adobe.com/aharui > >
